A WordPress install is a bunch of directories and files, but two of them are particular: the file wp-config.php and the directory wp-content/ are personal and don't get overwritten when you upgrade your blog. In WordPress 2.6, they get so personal that you can even move them out of the WordPress root. This must bring a major change to your coding habits.
Plugin coders sometimes need their script to guess the location of their own directory (for example to require() files), or to include wp-config.php to make a file live alone in a WordPressized environment.
Guessing the path of wp-content
WordPress 2.6 allows advanced users to specify the location (physical and URL) of this directory with a constant define, so the directory might not be where it used to be.
What you used to do:
- $plugin_path = ABSPATH . '/wp-content/plugins/' . plugin_basename(dirname(__FILE__));
- $plugin_url = get_option('siteurl') . '/wp-content/plugins/' . plugin_basename(dirname(__FILE__));
What you will have to do, now that this directory can hide anywhere:
- // Pre-2.6 compatibility
- if ( !defined('WP_CONTENT_URL') )
- define( 'WP_CONTENT_URL', get_option('siteurl') . '/wp-content');
- if ( !defined('WP_CONTENT_DIR') )
- define( 'WP_CONTENT_DIR', ABSPATH . 'wp-content' );
- // Guess the location
- $plugin_path = WP_CONTENT_DIR.'/plugins/'.plugin_basename(dirname(__FILE__));
- $plugin_url = WP_CONTENT_URL.'/plugins/'.plugin_basename(dirname(__FILE__));
In WordPress 2.6, constants WP_CONTENT_DIR and WP_CONTENT_URL are either user defined or set in wp-settings.php
Including wp-config.php
In WordPress 2.6 you can either leave wp-config.php in the blog root directory, or move it to the parent folder (which makes sense if this takes this critical file off of the webserver's document root)
What you used to do:
- require_once('../../../wp-config.php');
What you must do now:
- $root = dirname(dirname(dirname(dirname(__FILE__))));
- if (file_exists($root.'/wp-load.php')) {
- // WP 2.6
- require_once($root.'/wp-load.php');
- } else {
- // Before 2.6
- require_once($root.'/wp-config.php');
- }
Basically in WordPress 2.6 the file responsible for loading the environment is, in first instance, wp-load.php in place of the good old wp-config.php.
However, as pointed out by GamerZ in the comments, this still may not work. Why? Because not only the config file may not be there anymore, but the relative path to it may have changed since wp-content might have been moved too.
At this point though, there is no way I can think of to guess the locations of both wp-config and wp-content. To be 100% foolproof, such a "standalone" file needing to include wp-config should be editable so that advanced users moving their wp-content directory could manually edit a location path (the $root variable in the previous example)
Summary
Coders, revisit your old plugins to make sure they won't eventually break on WordPress 2.6 :)
Shorter URL
Want to share or tweet this post? Please use this short URL: http://ozh.in/ip
BillH » You're totally missing the point. It's not about guessing the path of a current file. It's about other files guessing its path. Or about the file guessing the path of the rest of WordPress.
WP 2.6 promises to be a significant step up and thanks to your pointers, everything should go smoothly, plug-in-wise!
[…] about WordPress. I wanted to bring to everyone's attention a post by Planet Ozh about what WordPress plugin authors need to know about WordPress 2.6. The post covers changes to both the wp-content directory and the […]
[…] pour les développeurs de plugins WordPress (dont moi d'ailleurs), je vous invite à lire cet article (en anglais) de OZH qui liste les changements à effectuer sur certains plugins afin de les rendre compatibles avec […]
[…] What Plugin Coders Must Know About WordPress 2.6 – If you're a WordPress plugin author, then you should probably read this article. With WordPress 2.6 allowing you to change the location of your content directory and config file, there are some important things you may need to know. […]
[…] What Plugin Coders Must Know About WordPress 2.6 by Ozh of PlanetOzh. […]
[…] What Plugin Coders Must Know About WordPress 2.6 About the Author […]
For file that are loaded externally (like when you are doing Ajax call from your plugin) you can POST the ABSPATH as one of the parameters.
This should only be an issue if your plugin is being called independent of WordPress, and then trying to include WP. Rather than going through hoops to try to locate WP, just load through it using custom URLs or query strings, and then you don't have to worry about includes at all.
Matt: The problem may be when you are trying to load a JavaScript within your plugin, but need to reference some WP variables in it.
Usual way I was doing it naming the js file as js.php and the using php to fill in the variables. Now how do I know where is my js.php file located in regards to WP root if wp-content wanders around?
Weird — in WP 2.6 beta 2, plugin_basename(dirname(__FILE__)) gives me the full server path to my plugins directory.
So… I can get this to work, but not with the code you use….
Um… Nevermind. My bad…
(Stoopid symbolic links….)
@Vladimir Prelovac
I would not recommend you using .php to parse as JS file as there is quite significant overhead even though it might be easier.
I would recommend you declaring a JS variable on your page and then include the .JS file after you declare the variable and then you can use it.
[…] has been nice enough to begin enumerating gotcha's associated with the upcoming WordPress 2.6 release, based upon the current beta 2 version of the […]
[…] man sich diesen Artikel so durchliest (What Plugin Coders Must Know About WordPress 2.6), wird es demnächst nicht so einfach werden wie bisher, Plugins zu […]
[…] ???What Plugin Coders Must Know About WordPress 2.6 […]
I didn't check in 2.6 but it was already possible to move the plugins directory out of the wp-content directory, using :
define('PLUGINDIR', '../plugins'); // no leading slash, no trailing slash
With this snippet in wp-config.php, it was easy to move it outside of wp-content.
Does this constant is still up to date in 2.6?
Well it's nice to see that wp-content will be finally changeable… It will be easier to maintain a WordPress install with SVN externals.
[…] What Plugin Coders Must Know About WordPress 2.6 « planetOzh […]
[…] What Plugin Coders Must Know About WordPress 2.6, ?????? WordPress ?????, ??????, ?????????? WordPress 2.6 ?????????????. […]
[…] Ozh has a new post up by the name of What Plugin Coders Must Know About WordPress 2.6. Ozh put out a similar post back when 2.5 was in development, and I found it very useful. This time […]
Regarding finding wp-config.php: You could write a script that looks for it in ABSPATH, and if it doesn't exist, look one directory up from that.
Straight(ish) from wp-load.php… this works:
if ( file_exists( ABSPATH . 'wp-config.php') ) {
require_once( ABSPATH . 'wp-config.php' );
} else {
require_once( dirname(ABSPATH) . '/wp-config.php' );
}
WordPress 2.6 RC1 disponible…
Le développeurs de WordPress sont décidément très actifs. Depuis la Bêta 1, sortie le 26 juin, nous avons vu passer la Bêta 2 puis la Bêta 3. Hier est apparue la Release Candidate 1. Cela veut dire deux choses: d'abord que les contours fon…
[…] Ozh's tutorial explains the details, but the short story is that we'll soon get WP_CONTENT_URL and WP_CONTENT_DIR constants. And this is more than just convenience, 2.6 allows site admins to put those directories anywhere they want, so the constants will be the only reliable way of finding that info. Related:Site Back Online, Further Downtime ExpectedVideo Game Controller Family TreeWordPress Survey ToolsMySQL DocumentationHappy Birthday WordPress […]
[…] with the availability of Release Candidate 1, so if you're a plugin writer you might need to see some changes on how plugins behave in the new […]
[…] Ozh – What Plugin Coders Must Know About WordPress 2.6 […]
[…] authors should read over PlanetOzh's quick tutorial on how to make your WordPress plugins WordPress 2.6 compliant and upgrade their plugins. This shouldn't take too long at all. I have already updated and […]
[…] ??? ?? ????? ?? ??????? ??? ???? ????? ??? ??????, ????? ??????????? ??????? ?? WordPress. ? ?????? 2.6 ? ???????????? ????? ?? ????? wp-config.php ? ????? wp-content ?????? ?? ????, ?????? ?? ???????? ???????? ???????? ? ?? ???? ??????????. […]
Thanx, this is very useful post.
Codex page: http://codex.wordpress.org/Version_2.6 describes all the new constants developers can use.
Main problem remains use of WP stuff in CSS file. My theme needs to change CSS settings when user changes something in control panel. CSS file must be able to load WP saved options and use them to generate CSS elements. Only way to do this is to include wp_config and use get_option. Now we must find way to pass main WP location to a CSS file, so the CSS in a theme can load wp_config.
I will post here if I find some good way to do it. Any suggestion is welcome.
[…] mit WordPress Plugins zu tun hat, sollte sich den Artikel von planetozh dazu anschauen. Außerdem bin ich gespannt auf das iPhone App mit dem man wohl WordPress […]
[…] What Plugin Coders Must Know About WordPress 2.6 « planetOzh A WordPress install is a bunch of directories and files, but two of them are particular: the file wp-config.php and the directory wp-content/ are personal and don't get overwritten when you upgrade your blog. In WordPress 2.6, they get so personal that yo (tags: wordpress plugins plugin php 2.6 coding programming howto code) […]
I also recently updated my wordpress to 2.6, so this article has also helped me to better understand this newer version of wordpress.
Hi Ozh,
I will just say your code come to my rescue as god.
I was looking for a way out from few days.
Thank you very much… :-)
[…] There is one very small issue with most of my plugins. WordPress 2.6 may break the Check Version function in the Options page. This does not affect the core functionality of the plugin and is only likely to occur if you have moved the wp-content folder from its default location. […]
[…] bei planetOzh Tags: Pfad, Plugin, WordPress, wp-config, […]
[…] detects the appropriate location of core WordPress files and URLs using the technique outlined in this post by […]
[…] this has changed and Ozh show up the new way in his article. In his discussion with GamerZ he added the note to the article : However, as pointed out by GamerZ […]
[…] the internals of TinyMCE, but beware of the wp-config.php include that is deprecated on WP 2.6 (wp-config.php can be moved) So, basically: very cool idea, I hope the plugin improves in the […]
[…] ha escrit una entrada en la que explica les coses que els desenvolupadors de plugins han de saber sobre WordPress 2.6; en aquesta entrada mostra el codi que s'hauria de introduïr-se en els […]
[…] WordPress 2.6 allows advanced users to specify the location (physical and URL) of the wp-content directory with a constant define, so the directory might not be where it used to be. I have changed the code of Lazyest Gallery in the way Ozh suggested in his post What Plugin Coders Must Know About WordPress 2.6 […]
Shouldn't you also check if WP_PLUGIN_DIR & WP_PLUGIN_URL are already defined? Since they too could be at a different location? Here you assume it's "plugins"?
wesley » actually yes, you're right. I just didn't want to look like I encourage doing this :P
Also, doesn't __FILE__ include all you need to know? If you remove the .php file at the end
wesley » dirname(__FILE__) is fine to guess where physically the plugin is. But you cannot guess a URL from it and it's not aware of where the rest of WP is.
You're right, sorry :)
Btw, i sent you an email via your contact page.
For finding and loading either wp-load.php or wp-config.php, what about something like this:
[…] Added fix for any calls made to the 'wp-config.php' file in orgSeries (see here for my reference) […]
" … For finding and loading either wp-load.php or wp-config.php, what about something like this … " Eric
This part of the code:
$rootPath = str_replace('/'.$rootArray[$i], '', $rootPath);will mess things up if we have two directories in the hierarchy that has the same name, for instance:
/opt/lampp/htdocs/blog/wp-content/plugins/myplugin/blog/data
two directories are named 'blog' might give unexpected results.
@SEOAdsenseThemes – You are very correct! I just found that out today.
Here is the updated code that is independent of the directory names. Not sure why I didn't do it this way in the first place…
Anyway, this seems to solve all conflict with directory names.
Eric