This topic contains 34 replies, has 6 voices, and was last updated by Tom 1 year, 4 months ago.
November 30, 2016 at 12:40 pm #249911
Memo To Self: Never follow instructions from other users until Tom verifies the question… 😉November 30, 2016 at 12:42 pm #249913
Tom Lead DeveloperNovember 30, 2016 at 12:43 pm #249914
Whew! Thanks, Tom. That’s a great feature.
Memo To Self: Stop sending Memos to SelfNovember 30, 2016 at 12:44 pm #249915
Tom Lead Developer
Good 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 #249935
Tom Lead DeveloperNovember 30, 2016 at 2:07 pm #249945
Tom, yes it appears the other plugins are using EDD.
My XAMPP is using Apache 2.4.17
Tutorials and tips for GeneratePress, WP Show Posts, WordPress and ElementorNovember 30, 2016 at 4:56 pm #249993
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 #250481
Tom Lead DeveloperDecember 2, 2016 at 3:15 am #250567
Oh, no worries, Tom.December 4, 2016 at 7:58 pm #251447
Tom Lead Developer
Here’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:
If 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)
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 #251500
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 #251630
Tom Lead Developer
GP 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-updateDecember 5, 2016 at 2:00 pm #251716
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 #251760
Tom Lead DeveloperApril 12, 2017 at 7:11 pm #305254
Tom Lead Developer
Received 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
You must be logged in to reply to this topic.