I was going to point you to the wiki for the change to pdo
but it seems you already found the info you needed.
I would recommend to have a backup of your DB and files before starting the upgrade on the production site, just as a precaution.
I just upgraded the way skenow suggested. But I upgraded on the localhost just to be sure not to disable the production site.
The upgrade went perfect, only one issue (see below), I am at 137 now, locally. I am now going to update the news and sprockets modules
But my new question is, what about the DB, an error in admin says:
System Warnings Edit
The mysql extension is being deprecated as of PHP 5.5.0 (PHP MySQL Extenstion). Switch to PDO, instead
I was thinking about protector again and it could be a good practise to disable it while doing the upgrade. It has a file manipulation check feature which gives a blank page as default reaction when an altered file, lets say by ftp, was found.
Have a good day!
I just tried updating to PHP 5.4 on an existing 1.3.7 site, and I get a bunch of similar errors and a white screen:
It was fully functioning until after the php upgrade, then it gave me that first error. After I tried upgrading, thinking that was the case, as someone mentioned a fix would be 1.3.7 but that didnt work either lol.
Before upgrading I downloaded all files, back up after back up, then zipped it all up, tried uploading 137 and kept getting upload errors, so with the back up files I wrote them over with 137 then zipped and uploaded that unzipped, changed permissions, then upgrade the db, I created a new db with old backed up db, upgraded and didnt get but a blank scree during the tablecreate process.
I can try again, but not sure If I can get that original errors, or even try to duplicate fiammybe, using 133 with php5.5.11
Not operable, even at the original version? That is an assumption I make -- always start with a functioning website, or was functioning, prior to server updates.
If the site becomes inoperable because of server changes - PHP version, file/folder permission changes - that becomes more of a challenge. In that case, I would work offline in an environment where the site works without modification, then apply the upgrades and redeploy to the server.
problem with step 5 is that the site is not operable at this instant, so we can't login. I'm getting consistent blank pages everywhere (homepage, user page, admin page), so I'm thinking in the direction of a protector problem. But unless I can verify that, I have no way of knowing for sure.
I can see we can be more helpful in upgrading existing sites.
Here's my process, if that will help... I went from 1.2.8 to 1.3.7 (after making sure all the modules worked in 1.3.7)
1. Backup: files and db
2. Download the latest full install package (1.3.7, in this case)
3. Uncompress, remove cache/, install/, templates_c/, uploads/, mainfile.php, favicon.ico, robots.txt (we should have a package for this)
4. I usually empty cache/ and templates_c/ on the server
5. Log in to the site as an administrator
6. Close the site
7. Upload the files to the server and overwrite. If any files fail - figure out why and fix.
8. Go to the admin control panel - update the system module (you should be prompted. If not, do it manually)
9. Test every module
10. Open the site
Log out and back in. Depending on your starting point (prior to 1.3.3), you may be prompted to reset your password, because of changes to the encryption schemes.
Often, I will test this locally before doing in production.
Note: also in 1.3.3, we packaged an updated version of Protector. You'll need to be sure you are the latest version from us for it to run error free on PHP 5.3+
There was an issue with the install at the tablescreate stage, because of settings in PHP 5.5 - these were addressed in the 1.3.7 release.
ok got that, but so far, I did the following:
new install, full 1.3.7, using old db (as it stated can use one already used). After clicking on write to mainfile.php, i get a pause then a blank page.
so I went backwards and changed the db to the newly created empty. and when clicked on write to mainfile I get the same blank page:
what I did with those transfer files, I copied a backup on local PC then copied the files over the old files and zipped it up and uploaded then unzipped, etc, still didnt work lol
about to go to bed
1. You are not upgrading a xoops-or-impresscms_1.0 site if you are going from 1.3.3 to 1.3.7.
Because of the number of files changed in 1.3.6, you'll need the full 1.3.7 package, minus the mainfile.php, cache/, templates_c/, install/, robots.txt, favicon.ico.
Do NOT copy the upgrade folders to your site root.
2. For the file transfer errors - the file you mentioned goes in the plugins/ folder. Does your FTP user have write access to that folder and those files?
This isn't a core issue, but a web host issue. I run into this on my sites occasionally, when I log in with SSH and do stuff, then go back to FTP - different user.
during the upload of files from htdocs to server root (install path) 35 files failed, when I tried to reupload as they were going up I noticed said:
Response: 553 Can't open that file: Permission denied
Error: Critical file transfer error
I am following these instructions:
1. Get the xoops-or-impresscms_1.0-to-impresscms-1.3.5 package from the website at http://.
2. Copy the content of htdocs/ over your existing files.
3. On your server, delete the file cache/adminmenu.php
4. Access <your.site.url>/upgrade/ with a browser.
5. Follow the instructions to update your database.
6. You will then be asked to enter the admin area will see a message saying you are entering the admin area for the first time, click on the Submit button.
7. You will then be asked to Update the System module. Follow the instructions.
8. Flush your browsers cache (on windows IE & Firefox you can do this by pressing CTRL+F5. MAC & Safari users can press CTRL+R, Linux Users can also press CTRL+R or CTRL+F5 when using Firefox).
9. A few folders were moved to other place in ImpressCMS structure to introduce more logic in the structure. Thus, you will need to remove these folders and files from your server:
10. Enjoy !
...and this is what I got as a result of upgrade/index.php
None | All | Errors (5) Queries (25) Blocks (0) Extra (2) Timers (3) Deprecated (2) Filters (0)
Strict: Only variables should be assigned by reference in file /SITE_TP/modules/protector/include/postcheck_functions.php line 23
Notice: Use of undefined constant XOOPS_CONF_AUTH - assumed 'XOOPS_CONF_AUTH' in file /upgrade/upd-2.0.13-to-2.0.14/index.php line 97
Notice: Use of undefined constant XOOPS_CONF_AUTH - assumed 'XOOPS_CONF_AUTH' in file /upgrade/upd-2.0.15-to-2.0.16/index.php line 31
Notice: Use of undefined constant XOOPS_CONF_AUTH - assumed 'XOOPS_CONF_AUTH' in file /upgrade/upd-2.0.16-to-2.0.17/index.php line 31
Notice: Use of undefined constant XOOPS_CONF_USER - assumed 'XOOPS_CONF_USER' in file /upgrade/upd-2.0.18-to-impresscms-1.0/index.php line 144
My host changed servers and moved my sites to a new server, all went well except for one site, and happens to be this one with impress.
Everything I have looked for is ok, but still getting 500, no clue as to whats the cause. checked the db, and the mainfile and all pointing correctly.
dont know what else to check.
I can get to the index page on the website but I havd the news files in a sub dir and that link doesnt come up.
http://www.bullfightingnews.com comes up, but...
http://www.bullfightingnews.com/2012/index.php doesnt and thats where impress is installed.
if anyone can take a look, lemme know thanks
Thank you all. Now it's working.
According to your host you need to get the server information from you control panel and 'localhost' will not work
The information there should be available when you login to the cpanel of your hosting (000webhost seems to offer cpanel as management console).
But again, please consider upgrading to a newer version. No more development is done on the 1.2 series itself, and no recent modules are guaranteed to work (most will not).
I was thinking to change version, but there are some changes in this CMS that I already have. I'm not sure if it change anything, because there can be a problem with hosting, not with CMS.
I would make a separate install of the new version and migrate a copy to this.