Hi all,
I needed to overcome the issue of mybb using relative paths in some links. I have a custom directory based URL scheme for my plugin which means going to a page like
http://mysite/plugin/keyword/id/keyword
and having a PM notice on there, would mean the PM notice would link to
http://mysite/plugin/keyword/id/private.php
which is obviously invalid. I was thinking of searching for these with mod_rewrite, but this means any relative link I would need to identify and then account for in mod_rewrite, which obviously isn't going to suit everyones setup.
So I came up with the following fix, but want to make sure it's not going to be too heavy handed
$plugins->add_hook('pre_output_page', 'mytipper_rel_to_abs');
function mytipper_rel_to_abs(&$page) {
global $mybb;
$page = preg_replace("#(<\s*a\s+[^>]*href\s*=\s*[\"'])(?!http)([^\"'>]+)([\"'>]+)#", '$1'.$mybb->settings["bburl"].'/$2$3', $page);
return $page;
}
Simply searches the page output before it is sent out for any relative links and puts the bburl in front of them making them absolute paths.
If it is too heavy handed I can restrict it to only happening within my plugin pages, though I actually think its a worthwhile feature to have.
Thoughts on this and memory/cpu usage?
I might just turn this into a simple plugin for everyone to download as I can see it having uses for all.
Dan
In all MyBB pages that include init.php (which is included by global.php) have a defined constant MYBB_ROOT which points to the root directory of the forum.
I think that should simplify things.
Not sure that would help with pre-coded by myBB themes that have Rel links
I.e. on the PM notice the link is coded into the theme and coded as
<a href="private.php">new Pm</a>
That means that if you are in a virtual directory based on mod_rewrite that will look in the VD for private.php
My solution above sorts that out. You could do the same thing with MYBB_ROOT however that then reveals full paths in the link which isn't needed
Yeah I am too tired. When I reread your post I realized that I was way off. My bad.
(2013-06-07, 04:14 AM)Wildcard Wrote: [ -> ]Yeah I am too tired. When I reread your post I realized that I was way off. My bad.
Ha hey no problems, points for even trying mate. Any answer is always appreciated.
I am going to adapt this to also do relative linked images as well. Will make life so much easier for custom URL schemes particular with the $theme[themedir] being relative
Testing it doesn't seem to kill memory too much however it is on my beta board which only has a few hits from my testers.
I will be releasing this plugin on my site hoepfully next week if testing goes well from this weekends sports. If all goes well I will know the impact of this part of the script on a busy site and can adjust it accordingly.
If I am happy from there then I will release it
Hi Dannymh,
I don't think there could be a big problem with preg_replace, you can test it, make it execute 1000 times and watch performance - Admins can see numbers for PHP & MySQL ("Generated in 0.1881330 seconds (28.16% PHP / 71.84% MySQL)...")
Maybe base tag can be used in your case.
The <base> tag specifies the base URL/target for all relative URLs in a document.
There can be at maximum one <base> element in a document, and it must be inside the <head> element.
Hi,
Its more that it parses the entire HTML of the page. So if it is doing this before every load, well things could theoretically get rather heavy, though testing doesn't yet seem to show that as it just runs on the entire output once, and in most mybb pages there should only be about 4 relative image links and 2 relative href links.
I did think of <base> and used this for my site. The issue here is that the workaround is not really elegant, and it requires a change to templates for all themes. If for instance I have the mobile theme and normal theme on my site I need to make that change twice and so on.
The difference with my workaround is it requires no change from the admin and should work for everyone.
preg_replace in and of itself should not be the memory issue, it's more that I parse the entire page through the pre_output_page plugin hook.
I am not seeing any issues so far, but will test "in the wild" more soon.
As I am cautious about this I am going to restrict this hook to only be called when in my own plugin pages so it wont be continuously called
Wouldn't this work?:
MYBB_ROOT."private.php"
Sorry if you've tried it, haven't read the other replies.
Ah, I see. It's about the hard coded links in templates, hmm. I had to manually edit them too in many of my custom pages.
(2013-06-07, 05:49 AM)crazy4cs Wrote: [ -> ]Wouldn't this work?:
MYBB_ROOT."private.php"
Sorry if you've tried it, haven't read the other replies.
Ah, I see. It's about the hard coded links in templates, hmm. I had to manually edit them too in many of my custom pages.
Yup about hard coded links. This will work and so far testing shows it has no major drain on resources, hopefully it proves to be a decent solution. I am adding images as I say which will solve a few more issues
Ive just knocked this together as a plugin with bot <a href and <img src being searched for and fixed.
Should be out soon as it is approved by mods. Its not a world beating modification, but I know there are a few people that run into the relative path issue and this should fix it across the board without you needing to modify every single theme. I think it is somewhat more elegant than using <BASE> as well, which comes with its own set of issues
Your "workaround" is exactly the reason why I advise against using such URL styles with MyBB. Your code won't do the right thing in several cases. You'll still need <base> anyway because JavaScript, or modify JavaScript. Redirects need to be modified too. All this hassle just to get a / into the URL. Not worth the trouble.