Upgrade a Website
I'm a bit out of my depth as usual and would really appreciate some help.
Next week I'll be upgrading a site from J2.5.14 to J3.3.3 or maybe it will be J3.4.0.
I didn't build the site myself but was brought in when there was little more than the bare bones, because the project had stalled.
Up till now I've had only Administrator permissions, no FTP or cPanel access and can't do an Akeeba Backup. The site builder relies on the host for backup. A backup has never been needed.
But next week I'll have superuser access and the site will be moved to new hosting where I'll have full control. At least, that what I've been promised.
I originally populated the site, then an in-house journalist took over the publishing of the articles.
Because of the changes that will occur along with the upgrade, and the political necessities for meetings and approvals, the job could well stretch into a couple of weeks. The journalist can't wait that long while I work on the restored dev version and then make it live.
So my main question: Will this work?
* Do a backup and get the site looking and working right on a dev site, while the journalist continues to work on the live site.
* When the dev site is approved, do a backup of the database only from the working site and restore that to the dev site.
* Download the images folder from the working site and upload the image files via FTP to the dev site. (Can I just upload the whole image folder in one go?)
* Move the working site out of the root and move the dev site in.
* Fix the temp and log URLs.
NOTE: The main thing I'm worried about is whether I can overwrite the database with the newly added content. This is where I'm most out of my depth.
In very broad terms, the way you've outlined how you would go about upgrading a website (or, perhaps, "migrating" a website would be a better description) seems, to me, to be a workable strategy. There are a few points that I'd like to offer my own opinions about:
I find this a little surprising. It's certainly true that Joomla administrators—not to be confused with "super users"—are hamstrung by not being able to install Joomla components; Akeeba Backup is a Joomla component. However, we all know that it doesn't require much technical expertise to install something like Akeeba Backup that would allow any site administrator account to be able to backup the site files and database and download the backup so that it could be used to generate a site for testing/migrating elsewhere.
Laurie wrote: I have ... [Joomla] Administrator permissions ...and can't do an Akeeba Backup. The site builder relies on the host for backup. A backup has never been needed.
If you have a "difficult customer"—one who is reluctant to work with you to help with "whatever it takes" to assist them to achieve the outcomes they're looking for—this is the first barrier that needs to be addressed. Difficult customers (like misbehaving children) need to be educated. It's not a case of telling people that "I can't help you if you don't change your ways". It's more about helping them understand that there are better ways.
Obviously, if you cannot get access to your customer's website files or their database, you aren't going to get very far past the starting line. If your customer believes that relying on their webhost to undertake "regular backups" is the only insurance they require, we—we who have been in the business for decades—all know that that kind of thinking is naïve (at best) or untenable in the long run. Undoubtedly, the "regular backups" that most webhosting companies perform offer some degree of insurance but none of us really knows the full extent that any webhosting company can guarantee "minimal" data loss.
This may sound a bit flippant, but I'm sure you've heard the saying, "nothing's impossible but miracles take a bit longer".
Laurie wrote: Because of the changes that will occur along with the upgrade, and the political necessities for meetings and approvals, the job could well stretch into a couple of weeks. The journalist can't wait that long while I work on the restored dev version and then make it live.
At some point there needs to be a cutover from development to live. During this cutover period, your customer's site will have to be "locked out" (to prevent changes to content). If this was my customer I would tell that person that we need to agree, now, on a strategy that minimises the amount of "down time".
Looking at your strategy, I would guess that it will take some time (hours or days, I suppose) to work on a development website using "test data" obtained from the current site. Cutting over, from your development environment into live operations, could take 30 minutes or an hour or two. I really don't know.
Most of the development projects that I've been involved with usually have "progress payment points". Building a website is a bit like engaging a builder to remodel your house. I'm sure people can relate to this model: you get a builder to give you a quote, you accept the quote and put a percentage down-payment as a deposit before the work begins, there are periodic payments made when various parts of the building project are completed and, on final inspection, there's a final payment. Developing a website for a customer is not really much different.
The progress payment model ensures there's high level of commitment from both sides: the buyer (who wants to make sure that their investment is realised as soon as possible) and the seller (who knows that their reputation will suffer if they don't fulfil the terms of the contract professionally or in timely manner) quite aside from the financial penalities imposed if one party or the other fails to fulfil the contractual terms.
Once you have agreement as to the scope of the work and the delivery schedule, and after you've done your "development" work, the next phase is to obtain agreement from the customer that your approach meet their functional requirements. You may need to demonstrate—either to yourself or your customer—that you have tested the "cutover strategy" (within a test environment).
When a customer says "yes, I agree that the development site meets my needs, that you have a sound strategy to switch it into production, and I'm ready to have the development site switched over", that's the point when I would raise an invoice and get payment before taking things further.
Point by point:
* Do a backup and get the site looking and working right on a dev site, while the journalist continues to work on the live site. Sounds good to me
* When the dev site is approved, do a backup of the database only from the working site and restore that to the dev site. Sounds good to me. I would also add the rider that it's at this point when you should freeze further access to the live site. From this point onwards, any additions or changes to the working site content would be lost when you "switch over".
* Download the images folder from the working site and upload the image files via FTP to the dev site. (Can I just upload the whole image folder in one go?) I don't know the answer to that question. It all depends on where "the image files" were located in the first place.
* Move the working site out of the root and move the dev site in. Sounds reasonable to me.
* Fix the temp and log URLs. There may be a bit of "Joomla administration" housekeeping to do, yeah.
* Backup Absolutely!
Assuming that you're working on a separate database during development, and assuming that your database table prefixes are the same, there should be no problems replacing data from your development environment into the live environment. If you've removed components (and those components had their own database tables) then the live site may still have unused data. If you're unsure, you could always DROP all the tables before you do a Akeeba Kickstart site restore.
Laurie wrote: The main thing I'm worried about is whether I can overwrite the database with the newly added content. This is where I'm most out of my depth.
I hope some of this information helps.
I can't go into the details of the arrangement in the public forum except to say that there are four entities involved rather than the regular two.
I sub-contract for the business consultant and I'm at the bottom of the stack. I have a very good relationship with the consultant; we're on the same team, so to speak. He's in the process of turning around the anomalies you mention, and others, some of them on my advice.
I've struck a major hurdle. On my multiple dev versions, local and remote, I can't upgrade to J3.3.3. I got it up from J2.5.14 to J2.5.24 with a manual upgrade but there's something wrong with the upgrade to J3.3.3. I've spent three non-invoicable days on this.
Following your advice on the database, I think I'll create a clean J2.5.24 installation and export/import the database from the dev site from the backup of the original site. That should tell me whether the problem is with the files or the database.
Is export/import the way to go or should I simply do an Akeeba Backup with all the folders and files excluded from the backup?
Let me put it another way: if you get a better deal elsewhere, while you're waiting to be "kitted-out" for this particular gig, I'd take it.
When I read that you were being engaged to migrate from J! 2.5.14 I shuddered and thought to myself, "Oh, hell, here's situation that's just screaming with the potential for problems."
Laurie wrote: I've struck a major hurdle. On my multiple dev versions, local and remote, I can't upgrade to J3.3.3. I got it up from J2.5.14 to J2.5.24 with a manual upgrade but there's something wrong with the upgrade to J3.3.3. I've spent three non-invoicable days on this.
We all know there's a reason why people talk about "best practice". Obviously, in the highly volatile world of internet site construction and maintenance where technology is the major currency, if people are still reliant on technology that was "new" a little over one year ago, outdated technology doesn't trade well today. Further, when sites are allowed to go unmaintained—as far as implementing the latest software releases are concerned—they usually beckon additional overheads for a professional's time to work through issues that may arise. Best practice means just that: it means remaining vigilant, alert, in tune with what's happening. But it's also a question about economics and about the criticality of a person's website to their business. There's no justification to use "best practice" if a person's website is merely a plaything/hobby/diversion. In situations where someone has all the time in the world to play around, to experiment or who couldn't really care less, then it doesn't matter whether they use "best practice" or not. However, when a person's website is critical to the success or failure of their business, people need to invest in their site ... and that's where professional website contractors earn their money.
It's probably unnecessary to create a J! 2.5.24 website from scratch. The reason that I say that is because the database structures for the key data items (the user tables and Joomla articles) aren't different between J! 2.5 and J! 3.3 ... yet! The key difference in J! 3.x—the part that makes J! 3.x not backwardly-compatible with J! 2.5—lies within the Joomla framework. Generally-speaking, J! 3.x extensions will not work with J! 2.5.
In other words, a J! 2.5 site template won't work with J! 3.x (and vice versa), just like many modules, plugins, languages or components. There are exceptions—some developers have built their extensions to work on both J! 2.5 and J! 3.x by creating discrete compartments to handle the different frameworks—but the exceptions do not mean that the general rule doesn't apply.
You could get away with creating a J! 3.3 site now, importing the existing J! 2.5.x database tables, and see if you can get things working. Without knowing the full extent of the components currently installed on your customer's website I can't say if this suggestion is guaranteed but it may be worth the effort.
I guess when you say "importing the existing J! 2.5.x database tables" you mean to export and import via PHPMyAdmin?
I'm out of my depth in PHPMyAdmin but I'll give it a go. Can't break anything that's critical.
I guess I'll only need to set up a couple of categories and menu items to find out, once I create a new J3.3.3 installation and import the database tables.
You seem to be saying the problem is likely in the files, not the database.
Yeah, that pretty much sums it up. J! 3.x adds a couple of extra database tables (and removes a couple) but the differences are fairly insignificant in general terms, as far as stock-standard, vanilla-flavoured, out-of-the-box Joomla is concerned.
Laurie wrote: You seem to be saying the problem is likely in the files, not the database.
The subject of this topic is "upgrading a website"; I prefer the term "updating" a website. Most of the time, updating requires some kind of migration of site content.
The site content may be images, articles and the users who access it.
Leaving aside the issue of how the site was originally constructed—whether the original site may have been J! 1.5, J! 2.5, Wordpress, Drupal (or some other CMS ) or merely a collection of files with some HTML drawing everything together—the data is what's really the thing that people are most interested in. Some people—I'm not one of them—are primarily concerned with how the site looks. Some people are more concerned with a slick, trendy-looking interface and not as much concerned about the site content. Considering that this particular website is one that's being used by a journalist whose stock-in-trade is the words and images they've written, the content is the primary reason for the site's existence.
Joomla is merely one mechanism used by people to publish content on the internet.
So, what's the important data—the data that, if lost, would be irreplaceable?
1) The Joomla users: the access permissions (passwords, ACLs, etc.);
2) The "articles" and images associated with those articles and the relationships between one article and another (in Joomla terms, the categories); and
3) The relationship between the user's site and other sites (including, among other things, internet search engines).
Everything else—the menu system, the template, etc.—is probably secondary.
Yes, phpMyAdmin is going to become one of your dearest friends.
I'm pretty sure I've got it, thanks to your suggestions.
The problem was that some well meaning person has deleted a file/s to do with the update and there was a database table missing, jos_update, and who knows what else. The count jumped from 61 t0 86, but that was from a clean install to the site's tables.
Before your suggestion arrived to go straight to J3.3.3, I already had a clean J2.5.24 installation created. I've successfully imported the old database tables into the new database.
The one click update looks to be working now, so when I've done the preparation I should be able to do a one click update to J3.3.3. Here's hoping!
Looks like I owe you a beer at the next JUG so if you're there first, hang out till I get there.
I am very surprised that your J! 2.5 database table(s) had the prefix "jos_"—this prefix was used in J! 1.0 and J! 1.5. From J! 1.6 onwards, the Joomla database table prefix was randomised. I don't know what the table jos_update did or does. Whatever legacy functions it performed (or performs) are probably forgotten or no longer relevant.
Laurie wrote: The problem was that some well meaning person has deleted a file/s to do with the update and there was a database table missing, jos_update ...
The count of what?
Laurie wrote: The count jumped from 61 to 86 ...
I'm not clear on this. Joomla (from J! 1.6) has always had a "one-click update" to allow you to update from one maintenance version release to the next. Even though it has never been a case of upgrading from one major version of Joomla to the next, it's usually been fairly simple to update from one maintenance release of Joomla to the next version.
Laurie wrote: The one-click update looks to be working now ...
When talking about major Joomla versions, I mean
- J! 1.0,
- J! 1.5,
- J! 1.6/1.7/2.5, and
- J! 3.0.
Going from J! 1.0 → J 1.5 is a major headache if anyone is contemplating doing it!
Going from J! 1.5 → J 2.5 is also a fairly substantial jump and most people use one of several third-party extensions to accomplish the migration.
Going from J! 2.5 → J 3.3 is a relatively short jump ... but ...
... I haven't seen a "one-click update" from J! 2.5 → J 3.3. If you have information about this one-click update I would very much like to see it, please.
Laurie wrote: I should be able to do a one click update to J3.3.3 ...
Yes, I noticed you mentioned that in conversation the other night. I wondered whether I'd heard you wrong or if you know something I don't.
It's Components>Joomla Update>Options>Short Term Support>Save and Close. Then click the update link and ya laughing.
Please see the screenshot:
It seems I got a bit too excited a bit too soon. Looks like my articals and categories didn't come across with the database tables. They're empty!
I'll create yet another remote subdirectory site and restore the original backup. Then export the tables and import to my current version of the site.