I am working on a Magento store and if I change anything related to shipping in the back-end it gives me an internal server error (500 Error). This only happens when trying to save the shipping configuration settings--I just changed the tax settings with no problem. I have tried everything from resetting the permissions to editing the .htaccess file.
Screen shots:
I get this:
It is allowing me to change any other setting though..
If anyone knows why this might be happening please let me know.
From the additional information you posted in the comments section, it appears that your server does not have the PHP bindings for mcrypt installed.
Your webhost will either need to install mcrypt, or you'll need to find another host that does.
The requirements for running Magento are listed on the website: http://www.magentocommerce.com/system-requirements
Related
I am trying to upgrade Joomla from 2.5 to 3 but update button is not showing on administrator panel. It is showing “Joomla! is up-to-date”. How will I get update button. Following errors came when I try to troubleshoot.
I am not able to get response from update.joomla.org. Is it due to proxy applied on my connection. If yes then could you please let me know the step to overcome this issue.
When I get in touch to our technical support team then they provide me proxy URL with port number. Without any credential. And they told me that I have to surpass this URL after using the proxy URL. But I am not sure how I can use this proxy to get response. Please suggest and let me know the solution. Thank you!!
Errors :
Update: :Collection: Could not open http:///update.joomla.org/core/sts/list_sts.xml ;
Update: :Collection: Could not open http:///update.joomla.org/core/jed/list.xml
Within the administrator area navigate to the 'Joomla! Updater' component (under Components) - when there click on the 'Options' button in the top right of the screen. When the pop-up appears, change the 'Update server' to 'Short Term Support' and click the 'Save & Close' button within the pop-up. Once closed, the updater component should go off and check for the latest version on the 'Short Term Support' branch. The text that said 'Joomla is up to date' should be replaced with the option to install the 3.5.1 version.
Make sure you take a backup before updating. Your template and other extensions may not be compatible with the 3.5.x branch so it's best to either make sure that they are compatible or find an alternative solution.
For others that might have been scouring the internet to solve this problem, I had the same thing happening to me on a very old site that needed to be upgraded. I had an early 2.5 site which I managed to update to 2.5.28, but could not get any further due to these errors.
Most posts on this that you'll find will refer to the https version of the error, but in my case I had the same problem is the OP, where the file that could not be opened was on the http URL.
Trying to directly load the http site seemed to work, until I noticed that my browser was automatically redirecting to the https site. I don't know if that was the browser, or a server redirect causing this, but it let me to another solution to this problem, which is that these resources obviously are no longer hosted on an insecure site.
Open up the administrator/components/com_joomlaupdate/models/default.php file and around lines 37-47, modify the listed URLs from http to https. Then rerun the purge/udpate check cycle and you should now get the update found.
In addition to this, other sites that are listed as not being found on http links can be updated by modifying records in the #__update_sites table. YMMV with these, as most of them are going to be 3rd party sites that may/may not have changed hosting. In my case, most of them had just disappeared. Notably, the core update site is listed in this table, but it gets overwritten by the aforementioned script, so updating the DB doesn't help.
I know that that similar issues and topics exist, however my issue differs slightly and none of the proposed fixes have worked.
I was accessing the Magento backend as normal. Approximately 10 minutes after that I could no longer access the Magento backend.
What I mean is that when I go to the admin url login page, I get a 404. However the 404 isn't generated by my host, it's generated by my webstore.
Everything about my webstore works as normal.
I've seen a number of fixes, mainly this one...
http://www.magentocommerce.com/boards/viewthread/207981/#t274443
I have a few main issues.
Admin Custom URL had been set (but not by me). It was set over a year ago when Magento was installed. It worked entirely fine until today.
I do not even have "admin/url/custom" and "admin/url/use_custom" in my "core_config_data" PHP table. It simply does not exist so I cannot change it. I looked manually for it and did a search for it. Nothing.
I tried updating the local.xml file and clearing "var/caches" and "var/sessions" but that did not work either.
I've been working this for hours and it's beyond frustrating. It's imperative that this be fixed ASAP because we are a fairly sizeable company.
Thanks ahead for helping. Anything at all would be appreciated.
First Check your Apache configurations
I know that you said you were only in the Magento admin but I would first check that apache was configured correctly. This is the first point of contact and you need to ensure that it's working right.
You need to locate a default Magento htaccess file that you can upload to your server. There's additional configurations that you need to make if you're in a subdirectory and also check to make sure that your mod_rewrite is working properly. There's an extensive tutorial on these things here, magento htaccess.
Make sure that you have the right magento admin url
I have to assume that you know what your magento admin url is, but of course I would double check that you're getting it right. There is an option in the admin area to change the admin url, you could have adjusted that on accident.
You say that you don't have "admin/url/custom" and "admin/url/use_custom" in your core_config_data table. This actually means that you didn't set the magento admin url from the admin area. However there is a third place that you can look for your admin url. This is in app/etc/local.xml but you couldn't have changed this from the administration area.
Did you turn off search engine friendly urls?
If you had been accessing your administrative area using /admin and then accidentally turned off SEF urls, then your admin area could have just simply moved to /index.php/admin. Of course you mentioned that you have a custom admin url, but I don't know what that is, so I'm giving examples with the default.
I can't really give you any more suggestions without more information. I hope that this helps!
Found this and thought I would post here since it shows up in google.
http://sourcelibrary.org/2011/05/19/magento-404-page-not-found-error-for-admin-panel-access/#comment-8444
Can someone please explain why ?___SID=U is appearing in some Magento URLs on my site and not others?
I think it has something to do with sessions but I am not entirely clear. Also, what makes it more confusing is the fact that it's only appearing in some URLs and not others.
I don't need to know how to remove it as I am aware of the setting in the admin area. I would really like an explanation of what it is, what its purpose is and why it would show on some pages and not others. id rather understand what's going on fully than blindly follow some advice as to how to remove it.
I addition to Brendan's answer, the ___SID=U is used in the cache as a placeholder for the session ID. It is replaced by Mage_Core_Model_Url::sessionUrlVar() which in turn calls Mage_Core_Model_Url::sessionVarCallback(). These methods are called from Mage_Core_Block_Abstract::_afterCacheUrl(), which means that any URL found in block output will contain the correct session ID (if needed).
So to get rid of the parameter in your own code the "right way" use this:
$url = Mage::getUrl('some/magento/route'); // might append ___SID parameter
$url = Mage::getModel('core/url')->sessionUrlVar($url); // process ___SID
If the string still displays in the rendered page that is a bug. Are you using some custom caching module, or generating URL's using a non-standard way?
The SID is a "session ID". Magento uses this to track a user's activity within the same Magento installation. Normally, Magento powers one website and one store from one installation (database).
Magento could power multiple websites with multiple stores from one installation though. The SID allows users to stay logged in while navigating across these websites/stores.
I think if you have the function enabled, the SID is sent when accessing catalog URLs so Magento can update the session with the user's location/state for the current website/store.
If you're not running a multi-website or multi-store environment, it's safe to disable the SID on the frontend.
Just something i come across today and though i make a comment, maybe it will help someone.
I found that Magento will format/create an incorrect product url (inc. Session Id) if there were some errors during processing the page. This is not consistent though.
It worth having a look at your server logs for PHP errors.
This is a general Magento 2 bug which is already reported to magento.
Temporary fix is
Go to Document Root,
Find .htaccess and add
RewriteCond %{HTTP_HOST} ^abc.com
RewriteRule ^(.*) www.abc.com/$1 [L,R=301]
below.
This should solve the issue. For me this work in M2.1
All the best.
Reference : https://github.com/magento/magento2/issues/5517
I hunted for hours to find this and the precise answer was a combination of the other answers listed here. First, I cranked up my PHP error reporting and error logging (thanks Gergely Varga). I saw this:
PHP Fatal error: Call to undefined function mb_strrpos() in /var/www/html/app/code/local/ManaPro/FilterAjax/Model/Observer.php on line 59
So, one of our installed extensions requires the php-mbstring package, which my server didn't have installed. As soon as I installed that, the SID=U URLs all disappeared. (In future I'll be running Magento's pre-install checks before copying an existing install over to a new server!)
Thanks to Vinai too for the background of what this tag is for.
Go to Store > Configuration > General > Web > Session Validation Settings > Use SID on Storefrontand and set the value to No.
Clear the Magento cache
I'm running Magento 1.7.0.0 multistore and a few times a day I get the famous "Internal Server Error 500" in my browser.
When navigating to Magento backend or a different Magento Storeview, the backend and the Storeview are still available and show no Internal Server Error.
Visiting the homepage or any category page, product page or cms page doesn't make a difference.
After flushing /var/sessions, the frontend is available again.
So, what I've done already:
I think it's not related to permissions, as these are set properly. I ran Magento-Cleanup.php a few times, and that's not changing or helping.
I checked settings in htaccess. These seem to be good.
SID is off. With or without SID doesn't make a difference
Logs show no issues that could cause this.
Help!
Can you change your PHP setting to use Apache rather than fastCGI? I've seen this error before with FastCGI on some servers
When I install magento 1.6, it shows below errors, thanks for giving some advise:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
I was seeing the same error message when installing the Enterprise training environment. I just needed to delete app/etc/local.xml to clear out the default settings and allow the install process to proceed.
Had the same problem. I needed to delete database and create a new one. Even if the previous one was empty without any table. Still don't know why, but I found this solution from somebody who had the same problem.