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.
Related
We have an old TYPO3 site (v4.7) and we moved the site to another domain.
now all the pages give the error: 404 Not Found
when I tried to get the page using URLs containing page id like /index.php?id=2, it works
how can I fix the site to works using real spoken URL /page-name
thanks
First of all you should change the domain record (in the backend, at the root of the domain in "List" view).
Maybe the domain is hard-coded in your realurl-config which is usually at /typo3conf/realurl* (realurl-extension configuration in the extension manager). If you selected "auto-configuration" in realurl's extension configuration and nobody made the mistake to make changes to the file directly, you can delete it and let it regenerate.
Maybe TypoScript settings like config.baseURL or config.absRefPrefix have a say here, too. I suggest to check in the template analyzer (backend: "Template" -> select your domain's root -> template analyzer -> view complete listing) if there is something with the old domain.
Of course, realurl needs to be activated (TypoScript config.tx_realurl_enable = 1) but if you did not change it, that should not have changed.
Then of course clear all caches (preferably via the function in the Install Tool).
If you still have problems, deleting /typo3temp (and recreating it via the InstallTool) might help. And check if there's something useful in the logs, of course (where, depends on ['SYS']['systemLog'] and ['SYS']['systemLogLevel'], probably typo3temp/*.log or your PHP error log).
Good luck with that ole' T3 ;)
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.)
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 have a Joomla 2.5 site were I can no longer access the administrator panel. That only redirects me to /installation/index.php which (as it should) gives a 404. I think this happened after an upgrade.
I tried to clear browser cache as suggested here: Joomla 1.0, administrator link redirect to "installation/index.php", how to prevent this redirection?
But that didn't work.
A long time ago, back in the 1.x days, there were some security advices on the Joomla site which among other things suggested to move configuration.php outside the public_html directory which I followed. I can't find them now, but I tried to copy the configuration.php file to Joomla root directory as well as keeping it at the directory which is defined in defines.php (define('JPATH_CONFIGURATION').
Any ideas?
My extensions
bash-3.2$ find plugins/ -type d
plugins/
plugins/authentication
plugins/authentication/gmail
plugins/authentication/joomla
plugins/authentication/ldap
plugins/captcha
plugins/captcha/recaptcha
plugins/content
plugins/content/emailcloak
plugins/content/finder
plugins/content/geshi
plugins/content/geshi/geshi
plugins/content/geshi/geshi/geshi
plugins/content/joomla
plugins/content/loadmodule
plugins/content/pagebreak
plugins/content/pagenavigation
plugins/content/vote
plugins/editors-xtd
plugins/editors-xtd/article
plugins/editors-xtd/image
plugins/editors-xtd/pagebreak
plugins/editors-xtd/readmore
plugins/editors
plugins/editors/codemirror
plugins/editors/none
plugins/editors/tinymce
plugins/extension
plugins/extension/joomla
plugins/finder
plugins/finder/categories
plugins/finder/contacts
plugins/finder/content
plugins/finder/newsfeeds
plugins/finder/weblinks
plugins/quickicon
plugins/quickicon/extensionupdate
plugins/quickicon/joomlaupdate
plugins/search
plugins/search/categories
plugins/search/contacts
plugins/search/content
plugins/search/newsfeeds
plugins/search/weblinks
plugins/system
plugins/system/cache
plugins/system/debug
plugins/system/highlight
plugins/system/languagecode
plugins/system/languagecode/language
plugins/system/languagecode/language/en-GB
plugins/system/languagefilter
plugins/system/log
plugins/system/logout
plugins/system/p3p
plugins/system/redirect
plugins/system/remember
plugins/system/sef
plugins/user
plugins/user/contactcreator
plugins/user/joomla
plugins/user/profile
plugins/user/profile/fields
plugins/user/profile/profiles
Try this, if wont work move to another point.
1. Change this
if (file_exists(JPATH_INSTALLATION.'/index.php')) {
header('Location: '.substr($_SERVER['REQUEST_URI'], 0, strpos($_SERVER['REQUEST_URI'], 'index.php')).'installation/index.php');
To this:
if (file_exists(JPATH_INSTALLATION.'/index.php')) {
header('Location: '.substr($_SERVER['REQUEST_URI'], 0, strpos($_SERVER['REQUEST_URI'], 'index.php')).JPATH_INSTALLATION.'/index.php');
Its line 25-26 in administrator/includes/framework.php
2. Remove line 23-32 in this file - it checks for installation folder and size of configuration file, if you dont have installation folder and configuration file is ok, you can remove this
3. set variables $sef and $sef_rewrite to zero in configuration.php
Diagnosing The Situation
Perhaps you should start with diagnosing the plugins? By removing them all and adding in one by one to see what one causes an issue. As you recently updated, a plugin perhaps is causing this issue as it is outdated and is creating conflictions between the software and the extension.
The issue may be based around that the configuration cannot be found, so Joomla presumes you have not installed the software.
Have you done all of these?
Removed installation folder
Checked if .htaccess isn't causing the issue
Attempt a downgrade and upgrade?
I think plugins would not cause redirecting to installation folder. Most likely the system thinks it's not installed yet, which would most likely be caused due to a missing configuration.php file in a location where Joomla expects it to be.
You can try to add something like this to the end of defines.php:
var_dump(file_exists(JPATH_CONFIGURATION.DS.'configuration.php'));
If it outputs true - that means config file exists and the problem is not in it.
Then I would rename .htaccess to htaccess.txt to make sure it has no effect.
If that doesn't work you could also lookup index.php file in public_html folder and make sure no changes have been made to it.
I'm pretty sure config file is not in its location and this should resolve your issue. Hit me back if it doesn't and I will help you further.
Try this things
Delete the joomla installation file directory: c:/host/project path/your site/installation
Check your server and restart it
Be ensure the required services are available on the server
Try installing the new Joomla package http://www.joomla.org/download.html
Thanks
IMHO you need to delete the /installation folder after an installation. Otherwise if it finds this folder and you get redirected there.
For security reasons Joomla does not allow you to be redirected to your site front-end or back-end before you delete the installation folder after the installation is complete.Please make sure the joomla /installation folder is deleted, and if yes, restart your server if possible.
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)?