problems with wp in sub-folder
-
Hi! My wp folder structure is like the following:
index.php —content/ —plugins/ —themes/ —core/ —wp-admin/ —wp-includes/this causes an error with your plugin:
<b>Fatal error</b>: require(): Failed opening required '/site/wp-includes/ms-functions.php' in 'site/content/plugins/shariff/backend/index.php' on line 50Any ideas to solve this dynamically?
P.s.: First, of course enjoy your holidays 🙂
-
There was a commit at Github bei “hirasso” that will fix this problem. Code looks well but I have not tested it. However we this functionality will be part of the next release.
There was a commit at Github bei “hirasso”
actually, hirasso is me on github 😉
hopefully my fix works for others as well. Tested it at least with my environment.
Changed my name here to match my github profile. No more confusion.
Hi hirasso,
thank you for the commit. As far as I can tell right now, it works fine. There is just a slight thing that I don’t like about it: It costs performance for basically nothing. The backend is called every time somebody visits your page and for every group of buttons on that page (e.g. on the blog overview page). And every time it searches for the wp-load.php – even though it never changes. That is quite a costly action for not much of a gain. My suggestion would probably be to create another constant that you can define in the wp-config.php to determine where the wp-load.php is, in case it has been moved. Like we already do it, if somebody wants to use a different cache directory. If someone changes the standard folder structure of WordPress, that person probably won’t have a problem to add a line to the wp-config.php, I guess.
I could even add a note to the status section, in case the wp-load.php is in a different place as expected, that tells the people what they have to do.
What do you think?
Cheers,
JPHi JP,
your solution with the constant actually sounds like a better idea indeed! Another good solution could be to apply a filter to the wp-load location. That way users could control it from their themes functions.php file.
The problem with filters is that WP is not loaded at that point, so there is no way of determined the path (except for searching) prior to loading at least the wp-load.php. But anyways, I’ll add the constant solution with a nice note in the status section with the next release. That should take care of the issue and has no impact on the performance. I’ll let you know as soon as it is implemented for you to test it.
JP
ah, of course, I actually first tried it with a filter! I’m so used to wp being present that I keep forgetting that 😉
Excited to see the next release soon, thanks so much for your effort! 🙂
Hey,
only two month later and we finally have a new version approaching… Anyways, the new constant solution is part of it. So you might already want to prepare for it by setting the new constant in your wp-config.php.
define('SHARIFF_WP_ROOT_PATH', '/path/to/wordpress/');After the update it should then work right away out of the box.
JP
Hey JP,
just in time! we yesterday released the website that uses your plugin.
Will check if it works and report back.
Hey hirasso,
well, sometimes you really don’t see what is in front of you. The constant works, but of course not in the wp-config.php, because if we cannot find WordPress, we cannot find the wp-config.php as well. Doh! So I created an own config-file for our plugin in the plugin directory called shariff-config.php where you can set the constant. So after the update you need to edit this file once to include your path and then everything should be fine.
3UU is checking the code on Saturday (always a good thing to have someone else review your code) and will then release the new version.
JP
Version 3.1 with the new backend is online now. This has not the final solution because the config file has to get an update with every new version. However if this way works for you I have an idea how we can fix the problem and make a permanent solution.
Well actually, since we implemented hirassos search solution to set the constant it should work right out of the box.
@hirasso let us know, if it works.
Hi there, it still isn’t working. I also can’t find my contributed code inside the
backend/index.phpfile. Running the latest version.EDIT: Now I found my code, but somehow it returns NULL on my install. *puzzled* will report back
So… I think I found the fix (don’t really understand the code though, but it works now on my server).
Replace line 64 in backend/index.php with$iterator = new RecursiveIteratorIterator( $dir );Aua, you are right. Not sure why I did not see it at the review 🙁 However in function
rsearch($folder, $pattern) {I do not see why
$dir = new RecursiveDirectoryIterator($folder); $iterator = new RecursiveIteratorIterator($dir); $files = new RegexIterator($iterator, $pattern, RegexIterator::GET_MATCH);is needed. Would
$iterator = new RecursiveIteratorIterator($folder)not work too?
The topic ‘problems with wp in sub-folder’ is closed to new replies.