Upgrading from PhpMyAdmin 4.5.5.1 (and earlier versions) to 4.6.0 breaks table export (and when many upgrades from earlier versions) also the "Server: Localhost" breadcrumb access.
I have raised a bug report with PhpMyAdmin folks here: https://github.com/phpmyadmin/phpmyadmin/issues/12159
, and they fixed that for 4.6.1, but also referred to fact that PhpMyAdmin should never be upgraded by file-overwrites, but always by first deleting previous files then writing new ones: https://github.com/phpmyadmin/phpmyadmin/issues/12159#issuecomment-20636...
Quoting http://docs.phpmyadmin.net/en/latest/setup.html#upgrading-from-an-older-...
Never extract the new version over an existing installation of phpMyAdmin; we had evidence of problems caused by this.
Please consider changing the upgrade method of PhpMyAdmin, as it obviously leaves old files that are potentially vulnerable.
Comments
Submitted by JamieCameron on Wed, 04/06/2016 - 22:45 Comment #1
Deleting the old install is tricky for most apps, because that would also remove any custom config files - even phpMyAdmin has its own config file which users presumably want to preserve across upgrades.
However, if there are specific files that should be removed, I could add that to the upgrade process.
Submitted by beat on Fri, 04/08/2016 - 06:55 Comment #2
To reply to your question of what to remove: According to this comment:
https://github.com/phpmyadmin/phpmyadmin/issues/12159#issuecomment-20636...
These folders should be at least removed before unpacking the new PhpMyAdmin package:
However, imho a much better and security-wise safer way would be to just keep the PhpMyAdmin configuration file, and whipe out the rest of the folder before an upgrade.
Submitted by JamieCameron on Fri, 04/08/2016 - 17:17 Comment #3
Does phpMyAdmin have just a single consistent config file though?
Submitted by beat on Fri, 04/08/2016 - 17:23 Comment #4
As far as I can remember (around 10 years), it's always been:
config.inc.php
But best and safest is to ask the PhpMyAdmin team directly on the github thread I referenced to above ;-)
Submitted by JamieCameron on Sat, 04/09/2016 - 17:16 Comment #5
Another reason why I'm reluctant to delete files first is that if extraction of the new tar.gz file fails after deleting old files (for example due to lack of disk space or quotas), the phpMyAdmin installation will be broken.
In the original problem case, which file needed to be deleted?
Submitted by jimdunn on Sun, 04/10/2016 - 10:18 Pro Licensee Comment #6
You could:
-- rename the phpmyadmin folder to phpmyadmin_orig
-- do a new install
-- copy the config file over
-- leave the _orig folder until the next update (where you would remove it, and rename again)
Submitted by JamieCameron on Sun, 04/10/2016 - 11:56 Comment #7
Let me see if there's a more general way I can solve this, such as by comparing files in the tar.gz package with those that already exist before upgrading.
Submitted by beat on Sun, 04/10/2016 - 15:51 Comment #8
Indeed, that would be the most general method for all scripts: Once you have done a new clean install with the new script installer method: Simply compare files of (old) installed version with files of new version to upgrade to. Then remove files that disappeared between the two.
However, that would not work for existing installations when during years, old versions have simply been overwritten without deleting obsolete files. Except for the config file, I believe that would not be a problem for phpmyadmin, however for other scripts it's an issue.
One case to take care of in all cases, is when scripts have been installed in subfolders of other scripts, like often the case with phpmyadmin in a subfolder of a CMS.
Submitted by beat on Sun, 04/10/2016 - 15:56 Comment #9
Quotas is a different issue: Quotas hitting during an upgrade are anyway a big issue, as you end up with half-upgraded version anyway. In fact script upgrades should simply not be allowed when over quota.
However, in practice, quoatas have many other issues: E.g. If you hit quota in a site, MySQL files would also have hit quota issues, and MySQL queries hang one after the other until maximum number of SQL queries or processes is reached, and then whole server MySQL services stop. But that's certainly disgressing from this bug. Just wanted to make aware that when disk quotas are hit, it becomes a way bigger issue server wide. So, except for checking that enough quota is available before script upgrades, I think it's a non-issue in upgrades.
Submitted by beat on Sat, 04/16/2016 - 12:15 Comment #10
Now the upgrade from Piwik 2.16.0 to 2.16.1 results in unusable stats-views when a file that disappeared in 2.16.1 is not removed in the installation (plugins/CoreVisualizations/Visualizations/HtmlTable/PivotBy.php):
I just experienced the same issue with Piwik 2.16.1 upgrade:
https://forum.piwik.org/t/viewdatatable-id-table-is-already-in-use/18837
I believe that files that are not anymore in packages and were there before should also be deleted on upgrade. A simple files-overwrite upgrade is not sufficient anymore....
Submitted by JamieCameron on Sat, 04/16/2016 - 12:48 Comment #11
Thanks, I'll fix the piwik installer to remove that file on upgrade.
Just deleting the old directory before upgrading isn't going to work as a general solution, because each script may have an unknown number of undocumented config files that need to be preserved.
Submitted by beat on Sat, 04/16/2016 - 12:52 Comment #12
Agree that for a general solution deleting all is not the solution, because of config files and installed extensions/plugins/media files.
However, if you can compare the zip of installed version and new version to install, and only delete files and folders that were in the installed zip, but not in the upgrade-version, that could work ?
Submitted by JamieCameron on Sat, 04/16/2016 - 15:28 Comment #13
That could work - I'd need to keep track of all files that were in previous versions though, which doesn't currently happen.
Submitted by beat on Sat, 04/16/2016 - 15:29 Comment #14
As long as the zip of the installed version is still in the cache (or can be downloaded), no tracking required imho ?
Submitted by beat on Sun, 04/17/2016 - 07:42 Comment #15
Actually, a good night of sleep sometimes provides good advice: Why not use
git cloneinstead of tar.gz to install scripts ?Then git fetch && git checkout version would automatically overwrite/add/remove files...and ignore any files that are not in the git repository! e.g. config files, media, and so on.
I see 2 ways to do that:
Submitted by JamieCameron on Sun, 04/17/2016 - 11:44 Comment #16
That could also work, however I prefer the tar.gz tracking approach, as it seems to have less dependencies. I'll work on implementing that..
Submitted by beat on Sat, 04/23/2016 - 08:02 Comment #17
FYI: Today I had a similar issue upgrading OwnCloud from 8.2.2 to 9.0.1: Virtualmin failed. I had to move all folders out of public_html, except data, config and settings, then upgrade in Virtualmin from 9.0.1 to ... 9.0.1 for the upgrade to succeed.
OwnCloud recommends too to not just write-over files but to keep config and data folders: https://doc.owncloud.org/server/9.0/admin_manual/maintenance/manual_upgr...