I'm working on my localhost and on a system where all administrator URL's which contain a &, & is changed to & and that in turn breaks the system.
What setting is doing this? What do I need to disable? My localhost is PHP 5.3. I have to mention that other Joomla system's are working perfectly fine and the & in the url are not converted to &.
There is no setting that can do this in Joomla 2.5 (as far as I know).
The only think capable of doing such a thing would have to be a system plugin that will re-encode the URLs.
So my first idea would be to check all the System plugins that may be URL related (like SEF things, or redirect plugins or some routing plug in and so on).
If that fails try to disable all System plugins and see if that fixes the issue.
Another way to test is to get a new fresh Joomla install and add one by one the components that you have on the broken install.
PS: Turns out it was a custom system plugin. (see comments)
Related
I've recently upgraded a site to the latest release of Drupal 7. The site has a view that retrieves a url with query string parameters from the database and then uses the Drupal rewrite functionality to add a class to the link like so:
<a class="purple-button pull-right" href="[field_database_link-url]" target="_blank">View</a>
The issue is, since the upgrade the rewrite now removes the query string parameters. If I modify the view to display a simple link the parameters are there and it works fine. However, the rewrite applies styling to present a button rather than a simple link. I can't find any settings to resolve the issue so I suspect the upgrade overwrote a modification to the Drupal core made by the original developer of the site. Any idea how I can address this issue?
It turns out that there was a bug in the latest release that in /modules/contrib/link/link.module that was causing the query strings to be stripped from the url in the token. I replaced the code in this file with the code from the pre-upgrade version and it began behaving as expected again. This, of course, is not a resolution to the issue, but at least the source of the problem has been identified. For more info: https://www.drupal.org/node/2367069
I later found that there is a patch for this issue in the dev version (7.x-1.x-dev) of this module available here: https://www.drupal.org/project/link. Download this module and replace it in your install and you should be all set.
I followed this (first comment),
magento - category name and image in static block? to create a simple widget to display the category image and title from a static block on a CMS page. It works fine on my local MAMP version of Magento Enterprise 1.13.0.2. It's not working however on the stage / test environment Magento 1.13.1.0. (ubuntu).
It doesn't error, it's as though it's ignoring the template file (info.phtml). When I reverted to the default theme I realised I had to copy the template files to the default enterprise folder to get it to work but it did (local version). I have made sure that the template folders are in each of the themes, base, enterprise (default), MyTheme (default (which is enterprise default) & (MyTheme / MyThemeVariant)).
The only setting / configuration that appears to be different between the local and the stage is that pretty url's aren't working on the local. I have looked into the htaccess and it still isn't resolved. On both versions the native Category link Widget isn't working but i'm not sure if that is relevant.
I have disabled any extensions turned the cache off and cleared the index. Still nothing.
I have been looking for the answer, retracing my steps, altering and changing back any setting(s) I think may be relevant for 3 days now so i'm well stuck. Anything anyone can offer to try I will give it a go.
So in Magento Enterprise there is also a full page cache that you can access via the Magento Admin here : System->Configuration->System->advanced->External full page cache settings.
On the page System->Cache management, as well as disabling all the caches you should flush the Magento Cache and the Cache Storage.
You might have a 'cache' called Redis or APC, but I don't think that affects .phtml output. and if you can access the Widget in the back end I don;t think those items are the problem.
Your webserver might have a full page cache such as Varnish but I don't know how to use it or turn it on or off.
Theoretically your webserver headers might be saying 'this page doesn't update so internet providers can store local copies in their caches' - but I would be astonished if that was the case (inspect your header and inspect the Cache-control Expires and Last-modifed headers if you want to eliminate this possibility).
Your browser might have it's own little cache (which you can clear from your browser settings).
If it isn't a cache problem, in my experience .phtml files get skipped if they have PHP errors in them but you have it working on your local dev server. Could it be a file permission issue? Could it be a setting in the widget on your server that is not handled by your widgets .phtml? As alast resort, try changing your widget .phtml to a really simple file like <?php echo('test PHP output'); ?> and see if that renders - try putting the widget on different pages (ie new pages that won't be cached anywhere) and see if that get's everything through.
Could you have a namespace conflict with another module? Eg an XML file is changing your widget block XML name that sets the .phtml template? Does your widget.xml file declare <supported_blocks>...</supported_blocks> which might be excluding the block into which you are trying to render the widget?
What else? You mentioned this widget displays category information: Are you referring to a category that exists on your staging server? It will probably have a different category ID than your dev server and / or check the category is visible in the website and store.
Okay, I think I am out of ideas now.
The problem was that "Block" php file's first letter was lowercase. I changed it from info.php to Info.php and now everything works as expected.
This has been the single most frustrating investigation yet into Magento. The only thing I hope is that it saves someone a whole load of pain.
I have a site with a really old version of Joomla, upgrade it or not is not my decision, so I have to work with this version (1.5.15).
The problem is on the site, the home page it's ok, loads all css and js, but when I access to another menu item I get: 404 Component not found, but the component exists, and also the url to access to resoruces (css, img, js, etc) is not correct, for example this is the url www.mypage.com, the url of resources is like /plugins/system/rokbox/themes/light/rokbox-style.css, when I access to another menu item the url is like www.mypage.com/index.php/resource_location.
What can I do? Why is this happening?
There are several options to consider:
Someone made a mistake: and changed the SEF configuration, maybe they just disabled SEF or routing or changed the .htaccess;
Someone attacked your site: pretty easy with your Joomla version.
In either case if you lack documentation or information you need to explore the differences, just load a working backup on a folder i.e. working_backup on the same server and run a diff:
diff -qrwbBE working_backup public_html
This will give you a list of different files, if there are none, go check the plugin configuration maybe a plugin was disabled such as SEF, else open them and see what changed.
If you do not have a working backup, download Joomla 1.5.15 from the Joomla version history site and run the same command, you will get a longer list including any 3rd party extensions; but it's reasonable that the issue lies with core Joomla or a SEF extension, it will be easy to pick it up.
Remember to clear the cache: the error may no longer be there but be cached, and the site might lack permissions to update the cache.
I'm looking at a site under development (at my wife's work). It's being built with Joomla 2.5.x, and it's using a Kunena template for the forum.
Each page on the site uses a single URL with PHP variables, e.g. www.sitename.com/index?option=com_content&view=article&id=96&Itemid=101.
However, on the demo site, the suffix is always .html even though the content is CMS/database-generated.
What I want to know is:
Why does the site at my wife's work use .php?...?
Where in the backend administration portal (to which I have access) are the settings for each view (presumably using a MVC framework)? Or are they only available by editing the PHP files directly?
Thanks.
Addendum
I found this documentation which helps explain #1. Still would like an answer to #2.
First, you should never edit a Joomla file directly. If there is ever somethign you can't do via a setting, override the file. Any changes you make in core files, besides potentially breaking things, will get overwritten on an update.
In terms of settings in general every view has an options button and you set default settings for the component there. There are then in general individual settings in items and menu items that override the defaults.
Kunena has more complex configuration and thus has its own complete UI.
Joomla has a setting for using either the raw url (which your site is using) or "Search engine friendly" (SEF) urls. The demo site not only uses SEF urls but also adds an html suffix to the end. The html really means nothing to the system and is just there. You could turn that off and the system would operate the same just without '.html'. (Locations would look like folders instead of files, I guess.)
If you access your administration system (www.sitename.com/administrator, most likely), you can go to Site->Global Configuration. Make sure you are on the "Site" tab and you should see SEO settings on the right side. These settings will change the urls between the demo's version and your own.
To use the mod_rewrite bit, you may have to convert an htaccess.txt file to .htaccess on the server: http://docs.joomla.org/How_do_you_convert_an_htaccess.txt_file_into_a_.htaccess_file%3F
To add a bit more, the demo site's url is ultimately converted back into the url that you see on your wife's work's site. The system operates based on option, view, id, and Itemid variables. The SEO settings convert this into search engine friendly phrases which I think help both search engines and people!
I had to move my site to another host and now the codeigniter installation is failing. I've fixed a few problems, but some of my modules break when I try to save changes. The end up going to the following url
admin/index.php/admin/index.php
is that right?
Your paths are relative. Put before an / or write using base_url()
It turned out that the person who had origionally implemented the system had used a differnt bit of code to get the base script for each module, so I had to go through and change each module.
For the admin module it turned out it was to do with changes in how the two differnt versions of php dealt with paths.