Trouble Moving Site
Permalink
Hi all,
I am having some frustration moving a site from one server to another. I have done this before and I have never had this particular problem.
I have gone through all of the steps to move the site, copying the files, exporting an importing the database and so forth, but when I go to the site I get the following error
Invalid "DIRNAME_APP_UPDATED" defined. Please remove it from /home/cocktail/public_html/config/site.php.
It is worth knowing that the the updated site.php in fact contains correct information. I am not getting a cannot connect to database error, but when I set the information in the site.php file to be completely incorrect I am getting the same error.
The only difference that I am seeing from the other sites that I have moved is the original site.php file and I am wondering if maybe this has something to do with it.
Here is the file as it originally was written - pre-updating for new server:
<?php
define('DB_SERVER', '10.223.192.169');
define('DB_USERNAME', 'btugwell');
define('DB_PASSWORD', 'encoded');
define('DB_DATABASE', 'C5');
define('PASSWORD_SALT', 'W6f8Vxi5iTMeNDsoTx4CIZASQjwRttr8cnNgLhDtiOWPtkP0KYpKx6L');?><?php ?><?php define('DIRNAME_APP_UPDATED', 'concrete5.6.3.2');?>
The thing that springs to mind is that the DB_Password definition is not the password we actually used -however it appears to be encoded here - could this be at the root of the issue?
Any thoughts or ideas would be greatly appreciated. Environmental information is included below.
Environmental information
# concrete5 Version
5.6.3.2
# concrete5 Packages
Extended Form (2.7.2), Facebook Like Button (1.1), Facebook OpenGraph Tags (0.9.1), Formidable (2.0.12), Social Links (5.0.0), tnSpacer (1.3), Treviso Theme (0.9.9).
# concrete5 Overrides
None
# concrete5 Cache Settings
Block Cache - On
Overrides Cache - On
Full Page Caching - Off
# Server Software
Apache/2.2.15 (CentOS) DAV/2 mod_ssl/2.2.15 OpenSSL/1.0.1e-fips
# Server API
apache2handler
# PHP Version
5.4.36
# PHP Extensions
apache2handler, apc, bcmath, bz2, calendar, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, json, libxml, mbstring, mcrypt, memcache, mhash, mysql, mysqli, newrelic, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, Reflection, session, shmop, SimpleXML, sockets, SPL, sqlite3, standard, tidy, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, zip, zlib.
# PHP Settings
max_execution_time - 30
apc.max_file_size - 1M
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 1000
memory_limit - 128M
post_max_size - 8M
sql.safe_mode - Off
upload_max_filesize - 2M
memcache.max_failover_attempts - 20
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
newrelic.special.max_nesting_level - -1
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - nocache
session.gc_maxlifetime - 7200
I am having some frustration moving a site from one server to another. I have done this before and I have never had this particular problem.
I have gone through all of the steps to move the site, copying the files, exporting an importing the database and so forth, but when I go to the site I get the following error
Invalid "DIRNAME_APP_UPDATED" defined. Please remove it from /home/cocktail/public_html/config/site.php.
It is worth knowing that the the updated site.php in fact contains correct information. I am not getting a cannot connect to database error, but when I set the information in the site.php file to be completely incorrect I am getting the same error.
The only difference that I am seeing from the other sites that I have moved is the original site.php file and I am wondering if maybe this has something to do with it.
Here is the file as it originally was written - pre-updating for new server:
<?php
define('DB_SERVER', '10.223.192.169');
define('DB_USERNAME', 'btugwell');
define('DB_PASSWORD', 'encoded');
define('DB_DATABASE', 'C5');
define('PASSWORD_SALT', 'W6f8Vxi5iTMeNDsoTx4CIZASQjwRttr8cnNgLhDtiOWPtkP0KYpKx6L');?><?php ?><?php define('DIRNAME_APP_UPDATED', 'concrete5.6.3.2');?>
The thing that springs to mind is that the DB_Password definition is not the password we actually used -however it appears to be encoded here - could this be at the root of the issue?
Any thoughts or ideas would be greatly appreciated. Environmental information is included below.
Environmental information
# concrete5 Version
5.6.3.2
# concrete5 Packages
Extended Form (2.7.2), Facebook Like Button (1.1), Facebook OpenGraph Tags (0.9.1), Formidable (2.0.12), Social Links (5.0.0), tnSpacer (1.3), Treviso Theme (0.9.9).
# concrete5 Overrides
None
# concrete5 Cache Settings
Block Cache - On
Overrides Cache - On
Full Page Caching - Off
# Server Software
Apache/2.2.15 (CentOS) DAV/2 mod_ssl/2.2.15 OpenSSL/1.0.1e-fips
# Server API
apache2handler
# PHP Version
5.4.36
# PHP Extensions
apache2handler, apc, bcmath, bz2, calendar, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, json, libxml, mbstring, mcrypt, memcache, mhash, mysql, mysqli, newrelic, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, Reflection, session, shmop, SimpleXML, sockets, SPL, sqlite3, standard, tidy, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, zip, zlib.
# PHP Settings
max_execution_time - 30
apc.max_file_size - 1M
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 1000
memory_limit - 128M
post_max_size - 8M
sql.safe_mode - Off
upload_max_filesize - 2M
memcache.max_failover_attempts - 20
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
newrelic.special.max_nesting_level - -1
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - nocache
session.gc_maxlifetime - 7200
You should very quickly remove the database detail with which your c5 installations connects to the database. Or better - change it directly. As soon as this gets into the wrong hands, your website will be open doors for any malware a database can contain.
Seems to me like the directory of the update-core is not true to where the files really are. You've ran the update process to get to 5.6.3.2 and now all the concrete5-core-function are runned through the instance of the core in your /update folder. If there is anything missing, it cannot work well.
Have you "moved" the site by creating a new version of concrete5 in the new server location? Or did you just ZIP up the old page and copy it over to the new place?
Have you "moved" the site by creating a new version of concrete5 in the new server location? Or did you just ZIP up the old page and copy it over to the new place?