- This topic has 34 replies, 6 voices, and was last updated 7 years, 8 months ago by
Tom.
-
AuthorPosts
-
November 30, 2016 at 12:40 pm #249911
Jay Martin
Memo To Self: Never follow instructions from other users until Tom verifies the question… π
November 30, 2016 at 12:42 pm #249913Tom
Lead DeveloperLead DeveloperSorry, I meant your settings won’t be lost. Totally safe to delete and re-upload π
November 30, 2016 at 12:43 pm #249914Jay Martin
Whew! Thanks, Tom. That’s a great feature.
Memo To Self: Stop sending Memos to Self
November 30, 2016 at 12:44 pm #249915Tom
Lead DeveloperLead DeveloperGood to know it happens with other plugins, Lyle. I assume they’re using EDD as well.
I’m talking with Pippin about it right now π
November 30, 2016 at 1:55 pm #249935Tom
Lead DeveloperLead DeveloperAre both of your XAMPP installations running Apache?
November 30, 2016 at 2:07 pm #249945Lyle
Tom, yes it appears the other plugins are using EDD.
My XAMPP is using Apache 2.4.17
November 30, 2016 at 4:56 pm #249993Jay Martin
Yes, I am running XAMPP for Windows 5.6.24, which includes Apache 2.4.23.
With only minor exceptions (PHP xscream, debug, etc), it’s pretty much a stock deployment.
December 1, 2016 at 11:55 pm #250481Tom
Lead DeveloperLead DeveloperHaven’t given up on this – just waiting on Pippin.
December 2, 2016 at 3:15 am #250567Jay Martin
Oh, no worries, Tom.
December 4, 2016 at 7:58 pm #251447Tom
Lead DeveloperLead DeveloperHere’s the official response. Looks like it’s a Windows/WordPress bug (even though the localhost is running Apache):
———————-
Fair warning, this is going to get pretty technical really quickly, so bear with me.
The issue you are seeing is actually a limitation in the file system APIs within the Windows operating system combined with a ‘bug’ within the WordPress HTTP API (that we’ve submitted a patch to try and fix: https://core.trac.wordpress.org/ticket/38231). What happens with using a Windows server (or in this case XAMPP) is that the depth of the path to the files being extracted hits a the maximum number of characters that the operating system itself allows:
http://stackoverflow.com/questions/1880321/why-does-the-260-character-path-length-limit-exist-in-windowsIf we break down something like XAMPP, or other localized development environments, the path to the folder where WordPress unpacks the files during an update looks like this (using my machine as an example)
/Users/tom/Development/sites/edd/wp-content/updates/
This is 59 characters, which leaves us with 200 left for our unpacking, which seems reasonable, however, as pointed out in that Trac ticket above, WordPress uses just the last part of the URL requested as the file name when saving an update that is being requested. When you do this from .org it’s something like ‘my-plugin-latest.zip’, however in the case of EDD we use a tokenized URL to secure the endpoint so someone cannot just download the files at will.
Because of this WordPress bug, our .zip file that’s delivered is actually nearly another 80-100 characters, which is better than it used to be, but not perfect. This token contains all the checksums needed to make sure the person downloading the file has permission to. So once this .zip is unpacked we’re looking at ~ 1/2 of the allowed characters in a Windows file path diminished before we even start with your plugin’s file structure.
Until that Trac ticket is merged in, there really isn’t much more we can do with Windows based environments since we are limited by the file system itself, but we’re pushing to get that WordPress core patch which would all but resolve these problems for users of Windows based systems.
If you have any other questions about this, please don’t hesitate to reach out. It’s a frustrating one that we know exists and we are limited by what we can do while keeping the files save from wondering eyes, but we’d love to know if you have any other ideas or feedback related to it as well.
———————-
So for now if you’re running XAMPP/any kind of local server on Windows and run into this issue, you might just need to manually update until the Trac ticket is closed.
December 5, 2016 at 2:28 am #251500Jay Martin
Yes, the excessive resulting paths would appear to be the problem. So it would appear that we will have to manually upgrade whenever this Windows/WP bug manifests itself.
Having never done a manual upgrade of a theme (or plugin, for that matter), I searched Google for instructions and found this fairly recent page describing the processes. In essence, it says one must do the following (for a locally installed WP site):
- Download the theme update ZIP file and unzip the theme files onto your local machine
- Delete the existing theme directory from the wp-content/themes/ directory
- Replace the deleted directory by copying (or moving) the unzipped theme into the wp-content/themes/ directory
I’ve omitted the obvious backup/verification steps one would use as part of the process.
Tom, is this the process you would recommend for manually installing a GeneratePress theme update? I just want to be sure here.
December 5, 2016 at 9:52 am #251630Tom
Lead DeveloperLead DeveloperGP Premium is in the wp-content/plugins/ directory – so that would be the only change.
Otherwise, you can just follow these instructions: https://generatepress.com/knowledgebase/updating-add-ons/#manual-update
December 5, 2016 at 2:00 pm #251716Jay Martin
Sheesh, for some reason I got side-tracked and thought the installation failure was on the (recently updated) theme.
So sorry to bother you, Tom.
December 5, 2016 at 8:18 pm #251760Tom
Lead DeveloperLead DeveloperNo bother! Thanks for helping me debug – good to have a post to send people to who are experiencing this issue π
April 12, 2017 at 7:11 pm #305254Tom
Lead DeveloperLead DeveloperReceived an email from David Jesch from ServerPress – they developed a plugin which should fix this issue with Windows/EDD updates: https://github.com/ServerPress/Windows-Compatibility-Fix
Thanks, David!
-
AuthorPosts
- You must be logged in to reply to this topic.