Nothing happens upgrading to 2.0.14

[dcltdw]

I'm at 2.0.13, or so my footer says.
Admin -> Main -> File Permissions reports Writable for everything in green.
Main -> Package Manager -> Download Packages says that SMF 2.0.14 has been downloaded correctly.
I have mkdir'ed Packages/temp and 777'ed it.
I click on INSTALL MOD and it says that it's already installed.
I go to Installed Packages and hit UNINSTALL, and get

This package cannot be uninstalled, because there is no uninstaller!

Please contact the mod author for more information.

When from the smf/ directory I use
%find . -type f -exec grep -H "2.0.14" {} \;
the only file not in Packages/temp is

./proxy.php: * @version 2.0.14

Help?

[Sir Osis of Liver]

Look in /Packages/backups/, there should be a backup before 2.0.14 patch was installed.  Download, unzip, upload to forum root.

[dcltdw]

Look in /Packages/backups/, there should be a backup before 2.0.14 patch was installed.  Download, unzip, upload to forum root.

Didn't fix it -- forum still thinks 2.0.14 is installed.

Is the forum version in the db somewhere?

[dcltdw]

Is there a standalone python script that parses the smf_$version_patch.xml and executes the commands?  I'm willing to run that manually on snippets of the xml file to identify where the patch is breaking.

[Illori]

https://custom.simplemachines.org/upgrades/index.php?action=upgrade;file=smf_patch_2.0.14.tar.gz;smf_version=2.0.13

[Sir Osis of Liver]

Is the forum version in the db somewhere?

It's in _settings table, but you should try to determine what went wrong before tinkering with the database.  Which version do you see in index.php?

[dcltdw]

I manually entered in all the changes, and now I'm seeing 2.0.14.
Problem is, I've had to manually edit files each patch, and it's rather time-consuming, so I'd like to find an actual solution.

[Illori]

check the chmod to make sure the server is able to write to the files.

[dcltdw]

Dirs are set to 777; files are set to 755.

[Sir Osis of Liver]

Some servers block 777 for security reasons.  Dirs-755, files-644 usually works.

[dcltdw]

The .php files don't need to be +x ?

[Arantor]

Nope, because they're not run directly.

[dcltdw]

Excellent, good to know - thanks!

[Arantor]

To explain really briefly, PHP is not like Python or Perl, they're not files that have a call out to an interpreter directly. Apache or nginx are told 'if you get a request for a file that is a .php file, give it to this process to handle and serve the result to the user'.

Since they're done this way rather than conventional cgi-bin style stuff, there's no need to give them +x because they're not being executed, merely handled by Apache or nginx for you. This is also one of the key reasons why PHP proliferated as a thing for shared hosting, precisely because it didn't need the complexity of something like Perl with file permissions at the time.

[dcltdw]

*grin*
Yeah, for me, it was "I dunno, that's a server config thing".

Which probably explains why I'm terrible at DevOps.