Update to 4.9 ~ Fatal error: Cannot redeclare get_shortcut_link()

as this doesn’t appear to be a either a theme or plugin related

Have you tried:

– manually resetting your plugins (no Dashboard access required). If that resolves the issue, reactivate each one individually until you find the cause. Also remember to deactivate any plugins in the mu-plugins folder (if you have created such folder). The easiest way is to rename that folder to mu-plugins-old.
– switching to the unedited default Theme (Twenty Seventeen) for a moment using FTP/ SFTP , or a file manager in your hosting account’s control panel (consult your hosting provider’s documentation for specifics on these), navigate to /wp-content/themes/ and switch to the default theme by renaming your current theme’s folder by adding “-old” to the end of the folder name. Alternately, you can remove other themes except the default theme (Twenty Seventeen). That will force your site to use it.

If the above steps do not resolve the issue, try MANUALLY updating. Download WordPress again and unzip it. Access your server via SFTP or FTP, or a file manager in your hosting account’s control panel (consult your hosting provider’s documentation for specifics on these), and delete then replace your copies of everything on the server except the wp-config.php file and the /wp-content/ directory with fresh copies from the download. This will effectively replace all of your core files without damaging your content and settings. Please read the Manual Update directions first.

• This reply was modified 7 years, 3 months ago by t-p.

Thank you for your speedy reply t-p,

Well I could go through that rigmarole but actually I don’t mess with my customers’ websites lightly and at this stage I’d rather wait to see if anyone else reports the same issue (I know others have elsewhere). When I say it ‘doesn’t appear to be a either a theme or plugin related problem’ I am simply referring to the error message which clearly implicates PressThis.

I managed to restore the core files in both cases but I don’t want to do that again.

• This reply was modified 7 years, 3 months ago by PressGang.

As Marius L. J. points out …

PressThis has been moved into a separate plugin, you will be prompted to install it if you try using this feature.

I have never tried to use this feature and probably never will.

The 4.9 update seems to fall over it.

Looks like you have an incomplete install/update.

Try MANUALLY updating. Download WordPress again and unzip it. Access your server via SFTP or FTP, or a file manager in your hosting account’s control panel (consult your hosting provider’s documentation for specifics on these), and delete then replace your copies of everything on the server except the wp-config.php file and the /wp-content/ directory with fresh copies from the download. This will effectively replace all of your core files without damaging your content and settings. Please read the Manual Update directions first.

Thank you t-p,

I have had two successful ‘one-click’ (as codex) updates to 4.9 and two failed ‘one-click’ updates all with the same excellent host. Your somewhat formulaic response suggests that you don’t actually have an answer to my question.

I know how to manually update WordPress but why would I do that to tens of sites (taking each down for half an hour) when the issue according to the error message is apparently related to a core problem with PressThis?

Hiya,

Since I noticed you referenced me here I figured it would make sense to drop by.

What @t-p is saying is correct, your update doesn’t appear to have completed properly, and some of the files are technically still from WordPress 4.8 or earlier, this is why you are seeing the error above, because the function mentioned has been moved to another file (and you have the new version of that other file, meaning you now have two identical pieces of code that can not co-exist).

The proper way to address this issue is to do a manual update, to ensure old files do not stick around causing problems with future updates.

Thank you Marius,

I agree with you both, but why would the update fall over at exactly the same point on two very different sites? And conversely why would two updates succeed? Realistically I cannot manually update tens of websites manually. Not only does that knock out each site while I delete existing files and upload replacements, it also completely contradicts the one-click update intention within the codex.

Surely it would be worth at least trying to work out why this is occurring? Are my web hosts to blame in some way (how would I check?) or is clever fail-safe coding being lost in the ether … or is there an intrinsic problem with this update? Personally, I’m focussing on the latter.

Surely, this issue is with PressThis and it’s moved functions. Either the move is not handled well or the deletion of the old function is not timely.

There’s no problem with the update, with millions of downloads in the last 36 hours we’re not hearing about any large amount of failures.

The copied files failing can be for many reasons, permissions may be incorrectly set, the unpacking of the new version might not have been properly verified due to high system loads with your host if many users are updating at the same time or they have a very loaded service, honestly there’s no good way to track down -why- a partial update occurred, we can only recommend what to do if one does occur.

Well it’s good to hear that there are no problems with the update so far. I suspect many other millions of other (wiser?) users are waiting a while longer before they commit.

It’s interesting that you refer to permissions, I had considered that too. Is there a method built in to the updates that ensures permissions are set correctly? I used to use Joomla a lot years ago and that was terrible for ownership and permissions issues and that was one of the many reasons I moved over to WordPress … it’s robustness.

I completely understand that as advisers you mainly advise about alternative methods but what you are suggesting in this case is practically implausible. I simply cannot charge my customers to take down their sites for half-an-hour (in order to add a few frills that they are unlikely ever to use) because a one-click function doesn’t work every time.

We do check permissions as well as we can on every update, but computers are weird, things happen now and then ??

Yup, I get it ;-).

Who would have thought that such an apparently simple trip point would be so hard to solve?

I’ll wait this one out with the wise people and hope that either 4.9.1 or my eagerly waiting web hosts can come up with a solution. Dammit, I hate not having up-to-date WordPress sites.

@clorith,

Let’s go back to something you said earlier …

… your update doesn’t appear to have completed properly, and some of the files are technically still from WordPress 4.8 or earlier, this is why you are seeing the error above, because the function mentioned has been moved to another file (and you have the new version of that other file, meaning you now have two identical pieces of code that can not co-exist).

Please explain how that is possible (apart from the silly permissions excuse) within the wp-includes directory.

Hey @pressgang,

Updates can fail for a large number of different reasons and it is often hard to diagnose the failure due to specific configurations present on each server running the update.

Most commonly I see issues with file permissions causing this. Usually a user mismatch caused by the server user being different to the FTP user and both not being present in each other’s usergroup (generally meaning 1 of the users – usually the server user – is unable to update or overwrite files owned by the FTP user). That is a common issue I see when WordPress has been installed by a hosting providers 1-click option in their hosting panel.

If permissions is not the problem here I seen some other things trigger a fail on update for me in the past. An IO hang – if the server the site is on has a moment where it is either overloaded or your system needs to wait a long time for a different system’s IO to complete on the hard disk then the PHP process may time out and be killed by the server (very common on shared hosting systems).

Another thing I have seen cause a problem is that when files are being validity checked and they fail due to a corrupted bit it can halt the installation by breaking the flow with a malformed character or not properly closing a connection it has open resulting in a blocking thread hanging until some of the defensive code in the server realises it’s blocked and decided to recycle the process.

There are many more reasons that things could have failed. It’s easy to speculate what MIGHT cause the issue but a lot harder to say definitively it SURELY caused the problem. It’s especially hard to diagnose the reason without full access to server logs and to have logging levels on their absolute maximum (which can be a slowdown in production setups and is usually not enabled at hosting companies).

My specific theory here as to why your updates failed on 2 different sites at the same point is that it’s caused by permissions issues. An installer can create the files with 1 set of permissions and have different set of default permissions on the directories. I suspect that the directory permissions allowed it to add a new file to the folder as server user but it does not allow that server user to delete files as they are possibly owned by a different user or part of a different usergroup.

What I suggest is that you perform a manual update over FTP on 1 of the sites and see if it can fix it. If it does then I would look more closely at the permissions and what user owns each file and each directory. You can likely use 1 manual update to isolate the issue, perform steps to fix it on the other instances and then with some luck you could perform the updates on all the additional sites using the autoupdater system.

@williampatton

Thank you for your very comprehensive breakdown of what could have gone wrong, I really appreciate it. Regarding permissions/ownership in this case, is it safe to assume that any errors are within wp-includes? I’ve checked several sites with FileZilla and they all look identical (directories 0755 and files 0644) including the two that failed.

I posted here in the hope that someone else might have experienced the same error and that this might lead to an easier, less inconvenient solution than manually updating so many sites. I’ll do a late night manual update soon and post the results here.

@pressgang

Yes I think it is probably somewhere inside the wp-includes directory that has something unusual going on. Manually override that directory when your uploading the latest version manually may be all that is needed to fix the problem.

So far there hasn’t been a huge number of reports of failed install and a large number of sites (my own sites included) updated without any problems. I’m not sure where your exact problem comes from but if we can figure it out then that may be able to help the next person who comes across this problem ??

In FileZilla you can see the permission numbers and if they are all matching then it would be strange that a certain file would be set differently. Depending on your connection type you might also be able to turn on another field in FileZilla to show the file owner and the group (if you are connecting with SSH/SFTP you could see this, standard FTP it won’t show). Sometimes with 1click installers certain files are set with different users or groups so they can be edited by the installer at runtime (it’s a long shot but worth checking if you can see that in FileZilla).

If you don’t have a working backup from before this problem started then I suggest you make a backup of the current state just before you start the manual update.

Also it might be worth reaching out to your hosting company and asking if they could download WP and unpack it on the server somewhere that you can access and ensure correct permissions are set, they may also be able to perform a full filesystem backup for you in a quicker way that you may be able to do it yourself.

If the host can unpack WP on the server for you then you would just have to move around some files or folders and it could be a lot faster than manually uploading the individual files over FTP.