I'm trying to reverse-engineer a plugin : http://wordpress.org/extend/plugins/wordpress-social-login/
In a part of it, there's this line:
(I'm having a hard time understanding the first one, the rest are simply there for reference if they have something to do it.)
require_once( dirname( dirname( dirname( dirname( __FILE__ )))) . '/wp-load.php' );
define( 'WORDPRESS_SOCIAL_LOGIN_PLUGIN_URL', plugins_url() . '/' . basename( dirname( __FILE__ ) ) );
define( 'WORDPRESS_SOCIAL_LOGIN_HYBRIDAUTH_ENDPOINT_URL', WORDPRESS_SOCIAL_LOGIN_PLUGIN_URL . '/hybridauth/' );
My question is... what exactly is in this wp-load.php file that it needs to be required by the code? By looking at it, all I understand is that it loads crucial core wordpress files for the site to be running correctly (functions.php, wp-settings.php, wp-config.php etc...)
Doesn't the fact that the plugin runs already means wp-load.php is loaded?
Also it's a complete waste of resources since it includes so many files that may include other files as well and it's like an endless loop of required files, each within another, which are being loaded twice.. (or even more if other plugins use this kind of method too)
So what exactly does it do?
P.S; All I found by Google-ing is HOW to include it correctly (since paths are change-able) - but that's not my problem/question.
My question is... what exactly is in this wp-load.php file that it needs to be required by the code?
All of the core WordPress functionality. This includes the theme files, all the files of active plugins, etc. BUT loading WordPress in this way doesn't parse the requested URL and doesn't run the WordPress query(by initializing the WP object, nor the WP_Query objects).
By looking at it, all I understand is that it loads crucial core wordpress files for the site to be running correctly (functions.php, wp-settings.php, wp-config.php etc...)
Yes, you've understood correctly.
Doesn't the fact that the plugin runs already means wp-load.php is loaded?
If the plugin code was invoked by WordPress(for instance in order to display an admin page, or it was included by the initially loaded plugin file) - then yes, it means that wp-load.php has already been loaded.
Sometimes though, plugins direct requests to single files(for instance http://example.com/wp-content/plugins/my-plugin/sample.php), instead of to some WordPress-powered page(for instance http://example.com/?my_plugin_action=sample or http://example.com/wp-admin/admin-ajax.php).
See how the first URL references a specific file in the my-plugin plugin directory and the second one goes to the home page of the site with a specific query argument added, or the third example, where the referenced file is admin-ajax.php in the wp-admin directory - this is a special file, which makes it easy for plugins to make AJAX request(this file also loads the WordPress core and fires some action hooks).
In the case of the first reference, if the plugin wants to use some WordPress functionality(for referencing the database, manipulating posts, etc), it needs to load the WordPress core files by including wp-load.php.
Also it's a complete waste of resources since it includes so many files that may include other files as well and it's like an endless loop of required files, each within another, which are being loaded twice.. (or even more if other plugins use this kind of method too)
Note the _once part in require_once(... - this tells PHP to include the file only if it hasn't been included already. Therefore no conflicts will occur, and not too much memory will be used by PHP. Although - if you are in a context where WordPress has already been started, you shouldn't call the require function.
So, basically the plugin author expects some requests to be made to the plugin file in which you found this code. Since the author wants to use WordPress functionality in this file, he invokes the wp-load.php file in order to load the core functions.
I assume, that this is done in order to reduce load on the server, although with a couple of hooks that run on the plugins_loaded action hook and a custom $_GET parameter added to the home url, the result should still be pretty close.
I personally prefer the second option, but like I said, including wp-load.php will prevent WordPress from running some complex stuff(URL parsing and database query/ies).
If there is still something, that you don't quite understand about that - post a comment here and I'll try to explain further.
wp-load.php is responsible of bootstrapping the WordPress environment which make the plugin able to use the native WordPress Core function.
Now as for
Doesn't the fact that the plugin runs already means wp-load.php is loaded?
Not at all!
If you access a plugin file directly it doesn't mean that you have the whole WordPress environment and you are not able to use the native core functions unless you include wp-load.php.
This will include wp-load.php if not already loaded if the file is located anywhere, regardless of level, within the wp-content directory.
if(!defined(ABSPATH)){
$pagePath = explode('/wp-content/', dirname(__FILE__));
include_once(str_replace('wp-content/' , '', $pagePath[0] . '/wp-load.php'));
}
From what I read they usually include wp-load in the plugins when database usage is needed, but this is a bad choice as it raises a lot of problems.
You can see some relevant articles in here:
http://ottodestruct.com/blog/2010/dont-include-wp-load-please/ ( if this link is ever deleted, See that page here )
wp-load.php is one way to load WP from external scripts, allowing the use of WP functions among other features.
But, as you say, that should not be necessary as it is a plugin. Nevertheless, you don't explain where did you find the code in your question, because wp-load.php is indeed needed for front-end pages or scripts located in a directory different from the style sheet directory, for example, even when they are part of a plugin.
Plugin pages in the admin area don't have to reload WP because it is already loaded, but front-end pages do have to load it.
In short, there are several reasons to include wp-load.php to have access to WP functions and variables.
Probably a double check.
require_once() means that if it has already been loaded, then it will not load again.
Related
Is it possible to rename or redirect the plugins/child[] directories to change plugin names for Google or source code view?
Wordpress obviously relies on wp-content and it's children to run, but I'm curious if it's possible to rename the children of plugins using .htaccess or another means.
I've experimented with variations this:
`Redirect 301 /path/to-old-url http://www.yourdomain.com/path/to-new-url`
...but that comes back to an actual redirect header response which I can't have.
I'm hoping it can be done and still have Wordpress function and update themes and plugins normally, but I'm not that savvy using .htaccess and I've blanked my site several times trying different things.
Any pointers or help would be really appreciated. :)
EDIT: What I'm trying to do is change the visible plugin/child directory name only. Not change the directory Wordpress accesses for plugins/name - having the revised plugin/name visible is not a problem.
OK, add this in wp-config.php, and it should do what you need, replacing 'apps' with the directory you want to serve from, and moving the plugins to the same directory on the server.
define( 'WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/apps' );
define( 'WP_PLUGIN_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/apps' );
(Initial responses before fully understanding the question.)
Not really.
You could use this WP Hide & Security to hide the plugin path /wp-content/plugins/ and rewrite that to something else, e.g., /apps/ ...but the NAMES of the plugins would still be visible.
The only way I could think of not showing the plugin names would be to directly include them in your theme via php includes, and strip out all the css/js that the plugin adds and incorporate that into your theme.
However, that likely would break the plugin, and even if you could get it working correctly, there would be now way to update said plugin in the future....(and of course that would make your site terribly hard to support so it's not recommended at all.)
Friends,
I know this question asked before but i cannot find them . I want to move all plugin in to must use directory.
In wordpress blog also have answer but i can't understand them .
Any one suggest link to use must use plugin for all plugin
The mu-plugins directory will not read plugins in a subfolder, so all plugins must be individual files (as per "plugin-name.php" file).
This main plugin file is what will include additional files that exist in a subdirectory. Any plugin files in a subfolder will be ignored unless included in the primary plugin file.
I have installed a security solution in my Joomla website,and it's suggest that to put the configuration.php file above the Public_html Folder,how could it be possible?
how to tell the CMS to recognize the new location?
is the solution would be valid in all versions of the Joomla CMS? ,if it's not,so please
write:
1st:Joomla 2.5 Solution.
2nd:Joomla 3 Solution.
you would need to modify the defines.php file located in the includes folder.
Specifically this line:
define('JPATH_CONFIGURATION', JPATH_ROOT);
And change JPATH_ROOT to the correct path.
But the problem with this is that you are modifying a core file so if an update changes the defines.php file it will overwrite your changes and will break your setup. You will need to reedit the file.
Also the JPATH_CONFIGURATION constant may be used for other things within the CMS that are not specifically trying to get the configuration.php file so make sure to check that it will not adversely affect other parts of the cms before doing this in production.
Alternatively you can change the frameworks.php file (also in the includes folder) directly to change from where the configuration is loaded from
ob_start();
require_once JPATH_CONFIGURATION . '/configuration.php';
ob_end_clean();
Just change the require_once line to the correct path.
Again since this is a core file it could be changed by an update. But this may also affect other parts if the config file is loaded manually in components or other parts of the cms.
Simply answer is don't do it. This would mean you would have to do what #Patrick has suggest which is correct and will work, however it means editing a core Joomla file. This is not a good idea as in your case, if you ever update Joomla, you will have to perform this change every time and it you forget (which is likely), your site will stop working completely.
I would strongly suggest you find a different "security solution" which does not involve having to modify any core Joomla files.
If you could define what you mean by "security solution", then maybe an alternative could be provided for you
I didn't dig for 'since when this has been implemented', But it can be done without changing the core.
Joomla looks for a defines.php in the root and if its present, imports it. And then if it finds a constant named _JDEFINES defined, it doesn't load the original file, effectively overriding it completely.
So, If you wish to override the defines its pretty easy and all you have to do is copy the contents of the defines.php file from under the webroot/includes/ path and paste it inside the one we created in the webroot. And you can change the following constant as per your taste.
define('JPATH_CONFIGURATION', JPATH_ROOT."/my/supersecret/directory");
Now there is one more thing left to be done and then we are good to go :)
You have to prepend the following lines to the top of our override file (the defines.php in the webroot).
define('JPATH_BASE', __DIR__);
define('_JDEFINES', 1);
This constant conveys to the framework that the defines have been overridden and to use the new file accordingly (Last time I checked, this flag/constant is checked at around 10 different places all over the framework eg. here, so its important)
Also I have seen this feature available with Joomla v2.5.0 and v3.8.8 as per your requirements in the question.
Edit: Remember you have to repeat the same procedure for administrator folder too if you want admin panel to work, and remember that administrator has its own /includes/defines.php
I'm coding a form in Drupal 7, and I want to 'include' a php file that adds my DB connection variables to my code.
I've tested my code in several ways, and I'm sure that the 'include' makes me get a WSOD when I run Cron in my site.
I've Googled about this and I tried:
include("/sites/all/libraries/php/connection.inc");
include("./sites/all/libraries/php/connection.inc");
include"./sites/all/libraries/php/connection.inc";
I also tried the above with '.php' extension.
And my last try:
define('__ROOT__', dirname(dirname(__FILE__)));
include(__ROOT__.'/sites/all/libraries/php/connection.inc');
Sometimes I get a WSOD when trying to run Cron, and sometimes my page styles get broken when I submit a form.
What is the correct way to include a PHP file manually in Drupal? Note that I don't want to use the 'Drupal way' to do this or to use the webform module. I want to code it manually with PHP.
The libraries directory should only be used to store files shipped as a library through the libraries module (see here https://drupal.org/project/libraries).
For both examples lets assume library.inc is our file and relative_path_to is the relative path based on the module directory to our library.inc file.
To just include a file you can use:
require(drupal_get_path('module', 'module_name') . '/relative_path_to/library.inc');
And to do it the Drupal way (https://api.drupal.org/api/drupal/includes!module.inc/function/module_load_include/7):
module_load_include('inc', 'module_name', '/relative_path_to/library');
Cheers,
j
Try this ways
1) require 'includes/iso.inc';
2) include_once 'includes/iso.inc';
3) include ('includes/iso.inc');
OR Drupal Ways
include_once DRUPAL_ROOT . '/includes/iso.inc';
In my opinion these are correct Drupal (7) ways to include code:
module_load_include(); function - Drupal API documentation - to include any PHP files from within your or other modules where needed,
files[] = ... in your_module.info file to autoload include classes and interfaces within your own module - Writing .info file documentation.
Libraries module provides it's own way to include external PHP files from the libraries.
The second answer is the correct "Drupal way". The one that was accepted as the answer has many potential pitfalls if locations of things change. Using drupal_get_path is the best way. This is also especially true if you are trying to include a file that may not be fully bootstrapped during a module update hook.
I've recently implemented the following code to autoload classes in my php code:
function my_autoloader($class) {
include 'classes/class_' . $class . '.php';
}
spl_autoload_register('my_autoloader');
The code is contained in file that gets included at the top of all files that need to generate a web page. So then I set about removing the require_once calls from my code. Here's an example:
require_once('classes/class_web_page.php');
As you'll probably gather from the above, the various pages on my site (it's an online community so there's a forum, gallery, etc) all use the web_page class to generate page headings, menus, etc. The various pieces of code create a web_page object, set various parameters to determine what menu options etc are needed, give the page some content, and generate the html.
All seemed well until I made a change to the class_web_page.php file. The change was immediately apparent on most of the site... except for the home page.
I refreshed my browser, switched if off an on again :-) tried calling http://www.terragenesis.co.uk/index.php rather than just http://www.terragenesis.co.uk/, and even stopped and restarted apache on the server. Despite all this the changes didn't show on the home page. In the end I put the require_once line back into index.php... and presto hey: the changes I'd made in class_web_page.php appeared on the home page.
So it looks to me like the autoloader was loading a cached copy of class_web_page.php and nothing, not even restarting Apache, was going to persuade it to get the new version. Why it should do this for the home page and not the other pages... I have no idea.
Has anybody else experienced this? Have I done something wrong with the autoloader code? How can I fix it... or am I going to have to put all the require_once statements back in place? :-(
My server has PHP version 5.1.6
I found the answer to this... and as usual with "bugs" that elude me for days, it turns out that I did something incredibly stupid:
It turns out that at some point in the past I accidentally uploaded a copy of class_web_page.php into the site home directory rather than the classes subdirectory. So it existed twice.
So, it would appear that despite my autoloader telling php to look in the classes subdirectory, it will look first in the same directory as the main script (index.php in the case of my site's home page). All of the other site page scripts are in subdirectories (forum, gallery, etc) so they were "correctly" using the /classes/class_web_page.php
I've now deleted the copy of class_web_page.php that was living in the home directory... and everything works as it should.
Are you sure that this file is actually loaded (or a cached version of it)?