Its not just to get a slash in it is to make a keyword rich url that is human readable funnily enough js hasnt presented an iss as for the most part they are called absolutely. However its a simple addon to make the chamge. In coming up with my url scheme I watched a good 2 hours of videos by matt cutts and other google produced videos.
It may not be best because of mybb usage of relatives but that to me is more indicative of a change needed in mybb than a deterrent to using best practice url schemes agreed on by industry standards.
Id rather work to fix paths to absolute rather than go with a url scheme that is not preferable
It's your decision, but you don't know what you're talking about (you don't realize how poor support for directory structures really is). With your "workaround", broken URLs are pretty much guaranteed.
Your addon is based on output_page, only a fraction of content passes through that (e.g. quick reply, quick edit should not, and that's what I meant by JavaScript). Please use <base>, it solves problems you don't know you're having. You should match ://, not http, otherwise what happens to ftp:// or file:// links, or links that are relative but happen to start with http? For redirects please see also
https://github.com/frostschutz/Google-SEO/issues/43
I'm sorry it isn't supported better, it wasn't changed for MyBB 1.6 and probably won't be for 1.8, you'd have to change code everywhere, including plugins.
And I still say it's better to not even add the forum into the URL. It makes URLs look repetitive and takes focus away from what's really important, and for most forums that's the subject only.
When you click at "View Today's Posts", do you look at a) the subject or b) the forum the thread is in? Fact is that for most threads the choice of which forum it is in was more or less random. For example the "Better icons" thread, it's clear from the subject alone what it is about, so it's the only info you need. If you had to guess which forum it was in, the guess would be theme development, but it's actually in general support. So what's the use of putting "general support" into the URL? None whatsoever. It's just noise that takes focus away from what's important.
For case in point I am coming up with this issue with my tipping comp plugin
Custom urls are
Http://mysite.com/tipping-competition/co...-name.html
So for instance the you may have
Http://mysite/tipping-competition/manly-...ounds.htnl
The plugin uses misc.php to run and exits after each action is finished. Quick reply is never called and all relatives that need to be altered are generally in $ header so it works in thos contect.
As for base well it comes with its own major set of gotchas including ie issues as well as anchor issues. So I can see it having just as many ossues.
I played with the url with dashes instead of slashes but human readably it was terrible. To a larhe extent my user base is not tech savvy and the overwhelming feedback was they preferred tje above url scheme
Oh for my site manly sea eagles are a major keyword which I rank highly for and is massively relevant to my content
Links should not be too long - 78 characters max (Nielsen).
Adding directory to url is ideal when title is short - e.g. product name or model.
Alternative:
Google can use and present breadcrumbs in search results.
There is a rich snippets format for that:
http://support.google.com/webmasters/bin...wer=185417
The debate about urls and schemes is really a sidenote to the entore question here and I believe subjective. I have a pr5 site using my scheme and pr3 site using the alternatives mentioned by others here.
What I really want to know and what thia thread is about is the memory and load impact of using pre output and running one or several preg replaces on it?
> ... memory and load impact of using pre output and running one or several preg replaces on it?
Plugin checks posts for names/codes and makes tooltips... there are preg_match and preg_replace statements...
I compared load with plugin deactivated vs. activated.
When there are no matches - the difference is only in memory usage when plugin is activated
With 550 matches i get:
When plugin is deactivated:
Generated in 0.0684500 seconds (47.07% PHP / 52.93% MySQL)
Global Parsing Time: 0.0283270 / Memory Usage: 3.25 MB
Server Load: 0.06
When it's activated:
Generated in 0.2495711 seconds (74.01% PHP / 25.99% MySQL)
Global Parsing Time: 0.0611370 / Memory Usage: 3.75 MB
Server Load: 0.05
Thats not too bad what id like to see is that with say 100 users online my site always has minimum 100 to 200 online. The real test is scaling that. I have a server for these purposes in the office. I will eun some teeting on ot witj simulated load in the week.