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.)
Related
For a project I'm working on I am trying to accomplish to match the whmcs client area to my wordpress site.
So far I've made a lot of progress but I'm stuck right now. I want to include the header of my wordpress site in whmcs.
I tried to implement the static code of my header in the header.tpl file of whmcs. It kind of works but the css conflicts with the main theme of whmcs.
The second thing I tried was to include it with php
<?php include(path/to/header.php'); ?>
Since the header.php is located in the main www directory and whmc is on a subdomain, I was advised to try this:
include($_SERVER['DOCUMENT_ROOT'].'/header.php');
Neither of those two methods worked.
The next thing I did was a new approach. I tried implementing the whmcs layout in wordpress with a plugin called advanced Iframe. It does work but it doesn't always behave as it should and I think it is an better idea to keep whmcs completely on its own subdomain (client.domain.com)
I am no coding genius, so I'm stuck at this point. Are there any workarounds for this?
Assuming the file you're wanting to include the header in is in the same directory as header.php, then you can use
<?php include(__DIR__.'/header.php'); ?>
I have found my mistake.
Since whmcs themes are .tpl, php can't be included directly and is not recommended. What I did was create a new folder in the theme directory with all the assets and a header.tpl file.
Then I included the header.tpl like this.
{include file="$template/header/header.tpl"}
The only downside is that I have to edit the menu manually when changes are made to the WordPress site
I am using a wordpress theme which I have modified a bit, based on the "Revera" Wordpress theme.
I have used it on other sites and it has worded fine. However, I have always installed it in the root of the domain. This time I have installed it on http://www.gas-sense.co.uk/blog
It isn't generating the usual homepage layout ( see http://www.georgeedwards.co )
Just wondering if the themes are typically setup to trigger the homepage layout? and if that is defined in a particular section of the php ?
The root folder is not a problem, you probably didn't set up the site url correctly, read the docs bellow
https://codex.wordpress.org/Changing_The_Site_URL
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 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.
I'm trying to do something very basic: edit a small part of the category product pager template. I copied pager.phtml from .../base/default/template/page/html/ into my own theme's template/page/html folder and changed what I needed changed in the new file. Unfortunately, nothing is changed on the frontend.
I've tried enabling "Template Path Hints" and it definitely shows my custom template being loaded. When I blank out my theme's pager.phtml, all the content stays (as if its still loading the default template). When I edit the default template, still nothing changes! Ah ha! It must be cached...
But I've got the caches disabled (its a development site) and tried refreshing them all anyway. Nothing changes. I've edited many a template on this site and they've all worked as expected, its only pager.phtml that is giving me trouble.
If anyone could point me in the right direction or even toss a few more debugging ideas my way, that would be great. Thanks in advance.
Tripple check the paths. Seriously, something about working with Magento makes people (myself included) miss things that are one level below the obvious.
Once you've done that, jump to
app/code/core/Mage/Core/Block/Template.php
Find the lines that include the template file
$includeFilePath = realpath($this->_viewDir . DS . $fileName);
if (strpos($includeFilePath, realpath($this->_viewDir)) === 0 || $this->_getAllowSymlinks()) {
include $includeFilePath;
} else {
Mage::log('Not valid template file:'.$fileName, Zend_Log::CRIT, null, null, true);
}
and add debugging code to figure out why your phtml isn't being included.
If your caches are off, and you editing the base/default package/theme has no effect, it sounds like you are editing the wrong file ...
By chance is it a 1.3 template on a 1.4 build - as the pager set-up changed between the two versions and would lead to peculiar issues like you are describing.
Have you tested overriding another .phtml file to see if it actually works (ie. if you have set it up correctly).
Finally, caching being the last resort, have you got APC/Eaccelerator installed with the mtime/stat parameter set to false? As this would ignore the file modified time and serve up data directly from its internal cache. An Apache/PHP restart would prove this.
Verify by running
php -i | grep mtime
php -i | grep stat
Or by creating a test phpinfo(); file
Check your design settings in System->Config->General->Design->Package (example: default)
System->Config->General->Design->Themes->Default (set your theme directory name).
Also try:
Reindexing (the template may be changed, but the old index may be loaded)
clean /var/cache folder itself.
Is the site using litespeed or any other caching utility? May have to clean those caches as well.