I have migrated my magento website from one server to another, I have changed base url for secure and non secure to new domain, also changed database credentials in env file. but still i am getting error of PDO exception regard databse connection on exception log.
Note: I have enabled error log in index.php file.
Can you post the error details?
(keep sensible data out of it)
As far as I usually encounter, errors like these are related to file permissions. Especially after migrating. Kindly check your files & folders permissions.
Of course the above is assuming the new server meets the system requirements (PHP version, PHP extensions and Mysql versions).
Here are the Magento System Requirements for v2.1.x: https://devdocs.magento.com/guides/v2.1/install-gde/system-requirements-tech.html
Here is some info about permissions:
https://devdocs.magento.com/guides/v2.1/install-gde/prereq/file-system-perms.html
And if you happen to use SELinux check this: https://devdocs.magento.com/guides/v2.1/install-gde/prereq/security.html
Related
I am facing error in nopcommerce 3.90 when run the project at that also at sometimes it is working good but after sometimes it shows the error of "no database instance". I am surprised it shows this type of error. Because the normal thing I have done to run the nopcommerce project.
I have done these things:
set the setting file by installation of nopcommerce.
delete the bin folder of nopcommerce.
clean the solution and rebuild it.
But still facing the same issues.
"no database instance" this type of error occures when the Nopcommerce is not able to connect with the database. If you have created database locally then try to find SQL service and restart the service. But if you are having database being hosted on any other server then check you network connection.
There are some of summery solution that i have mention as below
=> Since i had moved a live cart to a test server, the settings in the database for that cart had force ssl and also force www before any url. Also under Store settings i still had the domain info for that site which was now difrent in the test server. Once i noticed this and updated the database it all started working.
=>
You try change settings.txt file:
DataConnectionString: Data Source=localhost/IP;Initial Catalog=DBName;Integrated Security=False;Persist Security Info=False;User ID=DBUser;Password=DBPass;MultipleActiveResultSets=True
=>
In my case I need config application pool for nopcomerce
my connection string
DataProvider: sqlserver
DataConnectionString: Data Source=.;Initial Catalog=nopcommerce370;Integrated Security=True;Persist Security Info=False
I need set Application Pool Identity to user has access right to db
Check the image to details.
=> Check also db permission.
=> try with
Data Source=9X.2XX.7X.XX\"yoursqlservenameinstance"
or
Data Source="yournamemachine"
or
Data Source="yournamemachine"\"yoursqlservenameinstance"
You can do some thing like
Check setting file on App_data existing or not
Check connectionstring is correct or not
Check your SQL server working or stop by try connect
Clear cache your browser
Try This ``
Right click on the downloaded file (nopCommerce_3.40_Source.rar) ->select properties -> press "Unblock".
and
and change connection string in Settings.txt file.
I tried to transport a joomla! project from an online server to my local WAMP server. I followed this tutorial of how to do it and everything went well. I downloaded all the joomla! files from servers public_html folder, then I set up the database (dowloaded .sql file from phpMyAdmin, and exported it to my local wamp sql server), then I set up the configuration.php file as in the tutorial (changed the $log_path and
$tmp_path, and everything else stayed the same.) Then it worked fine, localhost loaded all the website, all links worked, it just threw out strickt standart and notice errors, so I just turned them off - in config file $error_reporting value changed to "E_ALL | E_STRICT". And then everything worked except the user accounts. I can't log into the joomla/administrator, I can't register to website, and it seems it doesn't store / take the data from database. What should I do to? It clearly has connection to it, because there is no more error about that. What else should I do? Any help would be much appreciated and if there is need for more information, please just ask, I'll give it.
I am new to symfony and am responsible for a site that I didn't build. For some reason the site is on a live server but running in dev mode. - Im not sure why??
That aside - The website keeps writing _sess files to my /tmp directory. The contents of each _sess file is exactly the same. See below:
_symfony2|a:3:{s:10:"attributes";a:0:{}s:7:"flashes";a:0:{}s:6:"locale";s:2:"en";}
Do I really need all of these files? Can anyone suggest a way of disabling this feature?
Thanks in advance
The default session storage of Symfony2 writes the session information to file(s). The location these files are written to is determined by the config parameter framework.session.save_path. The default value for this is %kernel.cache.dir%/sessions. This means that in a default installation of symfony the session files would be written to the cache directory for the environment.
However, this can be a problem as the cache directory has to be cleared each time an app is deployed, thus logging all the users out. Therefore presumably your app has been configured (most likely in config.yml) to store the session files in /tmp.
As I understand it, sessions that have expired should be garbage-collected at some point. Symfony also has some config params that affect this - see the FrameworkBundle Configuration. I don't know how much traffic your website has but obviously you do need the session files for active sessions. If you think you have a lot of expired sessions you could try tweaking the gc config params.
Alternatively, if having the session files in /tmp is specifically the problem you could relocate them (by changing the value of the framework.session.save_path) or use PDOSessionHandler to store sessions in the database.
I have this problem with symfony 1.4.20 on a web site I inherited.
It is writing files to
/var/lib/php/sessions
every second, until the server runs out of iNodes.
I've tried changing settings in settings.yml. app.yml and PHP session variables.
Nothing sees to be working though, the only way I can stop it is to change the ownership of /var/lib/php/sessions to root and that prevents any session files being created.
EDIT - HUGE ERROR ON MY PART
I found another site that had the issue that I knew was not on the same server. Then I realized that the original site with the issue was also on a different server and had not been moved over completely yet. The server in question was actually a Plesk Parallels' server and the issue was caused by a patch applied to the server over the weekend due to a security update. This server did have the file path and I just had to chmod it to 777 instead of 77x for it to work. I apologize for the confusion and thank everyone for trying to help. +'s for all. :)
Original Post
I have a website on a shared hosting server (also mine) that since yesterday started giving me this error:
Warning: session_start() [function.session-start]: open(/var/lib/php/session/sess_678cf69f0f17b87c52136ee0280d23cc, O_RDWR) failed: Permission denied (13) in /var/www/vhosts/domain.net/httpdocs/index.php on line 1
I've checked /usr/lib/php.ini and /usr/local/lib/php.ini to see where it is set and both say it is set to the /tmp directory, which is where it should be set and always has been. The /var/lib/php/session directory never even existed. I did create it and give it 777 permissions but that did not help. Though the bigger issue here is why did it change to begin with. There is no .htaccess file for this site and I cannot find this being set anywhere on the site itself either.
This is the ONLY site on this server with this issue, telling me its something local to the website. I just cannot figure out what. So my question is this: what should I look for to check the session save path settings for an individual site on a shared hosting environment to find out why it suddenly changed for this one client?
FYI, I am running a WHM server.
Thanks
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../tmp'));
You need to add the above code before starting the session.
You don't appear to have write permission to the /var directory on your server. This is a bit weird, but you can work around it. Before the call to session_start() put in a call to session_save_path() and give it the name of a directory writable by the server. More details here
I found another site that had the issue that I knew was not on the same server. Then I realized that the original site with the issue was also on a different server and had not been moved over completely yet. The server in question was actually a Plesk Parallels' server and the issue was caused by a patch applied to the server over the weekend due to a security update. This server did have the file path and I just had to chmod it to 777 instead of 77x for it to work. I apologize for the confusion and thank everyone for trying to help. +'s for all. :)
I am upgrading an existing magento website for 1.4 to 1.6.1.0.
I had dumped the existing database,
Copied all the required custom extension in the blank magento version 1.6.1.0
and after running the installation got the following error:
Error in file:
"/app/code/core/Mage/Customer/sql/customer_setup/mysql4-upgrade-1.5.9.9-1.6.0.0.php"
- SQLSTATE[HY000]: General error: 1025 Error on rename of './sales_flat_order' to './#sql2-3af-a7' (errno: 152)
How can I fix this issue?
Upgrading magento is very painful process. I suggest you to import-export data from old to new shop.
I just went through the same heartburn. I found that letting the page try to load until the script got an error or timed out and then trying again eventually worked. The upgrade script will attempt to start where it last stopped.
Before you do that, make a backup of you site and database. If it continually errors in the same spot, restore and try again.
These tips may help improve the odds of a quicker success:
Put the site in maintenance mode (by adding the maintenance.flag file
to the root directory) before starting.
Increase server and php timeouts by a very large amount (3-5minutes).
Cleanup temp and log database tables that you don't care about
(carefully, everybody has different needs here)
I tried several different methods and that is the only thing that worked. It took probably 10 reloads (waiting for a 3min timeout each time). In the end, everything upgraded correctly. No matter what method you choose, if you want to keep your store data, you will have to run the bulky db upgrade scripts that take forever.
I had similar issues when updating from 1.4.2 to latest.
I built a custom maintenance script included in my index.php that only allowes to access my ip. But the update process via shell replaced my index.php so it was accessible for everyone.
That was the cause that the final sql scripts where run by several clients and caused errors like "can't move table" etc. because those steps where already done.
--> Summing it up: Be sure that the site gets called only once, until the upgrade was successful!
The very best way to migrate magento in my opinion, is to import your entire db to an environment that you have your new magento. Then magento will run all scripts and updates and keep your data.
Maybe you find some problems on the upgrade scripts, but it's easier to fix them than fix the problems regarding model/eav's problems on the fly.
I have succeed by doing this on migrate from 1.4.1 to 1.8.1.