In the process of moving a Magento shop to a new server.
Have copied clean copy of files for Magento 1.5.1, then copied the app/media/shin folders to overwrite the clean ones.
All seems ok, except I am getting PDO permission denied, despite the details in local.xml being 100% correct.
I have wiped the cache folders.
Any ideas?
Sorted, I must have missed something, but wiping the lot and starting over seemed to fix it.
Thanks,
What home page is returning?
Have you changes values in database?
Check this query.
SELECT * FROM core_config_data WHERE path = 'web/unsecure/base_url' OR path = 'web/secure/base_url';
Are you sure you didn't left old information in a local.bak.xml for example ? Magento reads every xml file in /app/etc
Related
I moved a magento project (version 1.9.0.1) from one server to another (lets say from magento.domain.com to magentotest.domain.com). I changed the web/unsecure/base_url and web/secure/base_url in the core_config_data table, I also changed the paths in the local.xml
I deleted everything var/cache, var/session and var/tmp and yet when I try to access magentotest.domain.com I am always redirected to the old page (magentotest.domain.com/admin as well)
I tried to track the problem in the magento code and what I found was that in Mage_Core_Store_Model the URL called with $this->getConfig('web/unsecure/base_url') still contains magento.domain.com - and for the life of me I cannot find out why.
Having googled this for three hours now and what I found was a clue that magento sometimes stores its cache files in the SYSTEM tmp folder. When I looked there I found a folder magento/var/cache but it was empty. I deleted it but to no avail.
I don't know what else to do. Did anyone ever encounter this problem?
seems like mine was a special case: for performance reasons, there was an extension named "redis cache" installed and only when I emptied THAT, it finally worked.
I just pulled down a copy of a customers live site to correct some plugin issues and set up a demo site on our local dev server, but I cannot get into the administration panel of the site due to a broken captcha (the captcha image does not display, so entering it correctly is pretty much impossible).
I do however have access to the codebase and the database, so if I can toggle this off somewhere, remove something from config.xml or comment out a line to temporarily shut it off until I can get in and disable it correctly, that would be perfect, because I only really have about ten minutes of work to do in the backend.
This issue is due to a missing resource, probably due to some DNS setting somewhere that doesn't match up with the URL on our dev server, though I don't know exactly where. The customer is running Magento EE v.1.13.0.2 if that is relevant. Thanks in advance.
Search on core_config_data table in your database .Search admin/captcha/enable on run the below code
Update
core_config_data set value=0
WHERE path LIKE '%admin/captcha/enable%'
insert into core_config_data (scope,value,scope_id,path) values ('default',0,0, 'admin/captcha/enable');
Remove the cache
Solution:
For Magento 2.x & higher versions
If you have access to Database:
Run the following query
SELECT * FROM `core_config_data` where path LIKE "%captcha%"
Set both the rows to 0
If you have access to code base
Remove the backend_login form entry in the following config file
Magento\vendor\magento\module-captcha\etc\config.xml
Don't forget to Flush the cache : php bin/magento cache:flush
NOTE: Once login in to admin revert the code changes.
We were having similar issues, after duplicating & moving an existing site to a new domain.
The other answers here helped but did not entirely solve the issue. When attempting to login it would silently error and not login.
To fix this we did the following:
Search in the core_config_data table in your database for the web/cookie/cookie_domain entry, and ensure the value here is correct for the new domain.
I just figured this out actually, I navigated to /app/code/core/Mage/Captcha/etc/config.xml and removed the following node (required sudo vi because it was read only):
<admin_user_authenticate_before>
<observers>
<captcha>
<class>captcha/observer</class>
<method>checkUserLoginBackend</method>
</captcha>
</observers>
</admin_user_authenticate_before>
I still like Amit's answer better because it does not require manually editing any files in the core, but this also works and I wanted to put this up as an option in case someone had the same issue in the future and did not have access to the database. Probably a good idea to restore the config to it's original state when you are done, unless you need to get back to the backend in the ongoing sense. I do like doing it through the database better though when possible.
After logging in, I restored the file to it's original state and disabled the captcha properly through the backend.
On M2.4 disable admin google recaptcha
select * from core_config_data WHERE path LIKE '%recaptcha_backend%';
update core_config_data set value=NULL WHERE path LIKE 'recaptcha_backend/type_for/user_login';
Ok so i moved hosting. Everything is working great except i cant get images to show up on the site. The only place that they show up is when you are editing the product on the image tab. No images are displayed on the list of products nor on the front end.
I have no idea what is going on here. If it helps at all when i inspect elements on the list of products page the "src" is blank but has alt text. But on the front end there is just nothing, no image tag at all.
I am not really sure where to start on this one. I have tried changing the path on the
define('DIR_IMAGE', BASE_DIR.'/image/');
To the absolute path on the server to the image directory, but that didn't help.
I have tried a few things that i found on google like deleting the cache directory.
Any ideas on something anything to try to resolve this issue?
The easiest way to make sure all of your details are correct is to do a "fresh install" to generate the configuration files again. Here's what you need to do
Back up your config.php and admin/config.php files to config.backup.php
Create a new database to use (this ensures that your original remains and can be used once your configs are created)
Clear the contents of your original config.php files and make sure they are writeable
Go to http://yoursite.com/install and fill in the details for the site, including the new database details NOT THE ORIGINALS
Once install is completed, Open the config.php and admin/config.php and change the database details at the bottom to match those of the originals in config.backup.php
Delete the new database and remove the config.backup.php files if everything has successfully been restored
If it were me and you would like your site not to go down. I would simply do a search on the code base for your old domain, and more importantly do a search in mysql for instances of your old domain.
Searching your codebase is easy using grep on command line. If you are not comfortable with command line download Sublime Text editor, download your code base and use Sublime to very quickly search the entire codebase.
Use phpmyadmin to search your database and use this snippet to replace your old domain with the new one: http://www.mediacollege.com/computer/database/mysql/find-replace.html
Hope that helps
I would like to point out you should always back up your website before doing this sort of change (that includes your database), and always test on a development instance where available!
I have been searching over the net for a specific solution on this problem in magento connect but I can't hardly find the right solution to solve it I have been constantly deleting files such as cache.cfg and connect.cfg as what other solutions have been stating but it would work temporarily then accessing it again would bring the problem back this also prevents me from installing new modules over the site, this is what I see:
Cannot unpack gzipped data in file contents: '/var/www/magento/downloader/../downloader/cache.cfg'
what do you think really causes this?
Try deleting the config.cfg file and check. Don't forget to take the backup of the same.
Hope it works for you.
The proper file to delete in this case is cache.cfg. Of course You can delete connect.cfg as well. Both are generated at entering magento connect.
I'm using TortoiseSVN. Recently there is a file in conflicted state. I right click it, choose 'Edit conflict', then choose 'Delete local file'.
I thought after deleting the local file, I could update to get the file from SVN server. But the fact is that TortoiseSVN doesn't let me get the file on server down to my local computer.
TortoiseSVN just shows that there are no changes.
I need the latest version of that file from server!!!
If you want to get the version of the server, the easiest way is to
revert your local copy (if there are any changes in that directory or below, you will loose these, but if that conflict is the only problem, it helps. To do that, do the following:
Select Revert... from the menu
In the opening dialog, accept that the file is reverted.
You now have a local copy without changes, so there should be no conflict there.
Now update that file to the current state of the repository.
If that does not work for the file itself, try to to if for the directory where the file lays in. Normally, it should be possible for this directory (with the conflicted state) to be reverted ...
I hope this order of actions works under any circumstances.
For editing conflicts... You need to open Edit Conflict panel and select the portions of the code you want to keep.
In case you delete a file, try importing that file again. If it doesn't work you need to make a fresh working copy.
Assuming the original local file is in your Recycle Bin, I would restore it. Then, try updating again, but this time say "resolve using theirs." It should replace your local copy with the head copy.