Jump to content

Peter Symes

Approved members
  • Posts

    3
  • Joined

  • Last visited

Everything posted by Peter Symes

  1. OK, I got to the bottom of the mystery, but only after much head scratching A while back, apparently after I did my previous upgrade, our website's URL format was, at long last, changed from http://www.domainname.com to the secure protocol: httpS://domainname.com. While our site can be accessed both with and without the www prefix, we also changed the preferred default url from having the www prefix to not having it. No problems, until I ran into this upgrade. One or both of these changes was apparently more that the upgrade process could detect and bridge. Once I went through all the entries in the config.file, stripping all references therein of www prefixes and also renaming the config file from www.domainname.com.conf.php to domainname.com.conf.php the install process went flying through in an instant and without any further hiccups. Thanks for providing feedback nonetheless.
  2. Perhaps I have not expressed myself clear enough. I follow the instructions to the letter, as I have done so many times before over the last decade or so that I have used and upgraded to successive versions. Among the steps, as pr the instructions, is to make a backup, a new copy, of the database which is named according to version. The configuration file is also copied and after the database name, user and password has been edited to reflect the new copy of the database. This amended configuration file is the uploaded in the var sub-directory, in the new installation, as directed. Commencing the upgrade, the process obviously recognizes the database and all, hence the warning which is about something about the database. Usually the upgrade will continue smoothly but stops, and what is it about some old entries anyway? As the new code base is a fresh clone of the preexisting one, which is still the live version, it surely has all the details needed. In any case, heeding the warning, even though it does not make much sense, I indeed tried putting the preexisting configuration file (with the older data base info) in the var folder instead as the prompt seem to suggest. That didn’t make any difference, it still does budge. Second option was to try and change the table prefixes. That only produced an empty installation, functioning apparently but with no content.
  3. I have performed quite many upgrades to newer versions over the years, following the instructions posted here every time as so many times before. This time, however, attempting to upgrade from version 4.1.3 to 4.1.4 at the second step of the update process I get this alert which I don't seem to be able to get past. I tried to copy the existing configuration file (for version 4.1.3) into the var folder for the new ( 4.1.4.) install as instructed in alert below - even though there is no such instructions in the general upgrade guide but trying it nonetheless - and that didn't change a thing either. I am still stuck at this point. Any ideas anybody?
×
×
  • Create New...