[Resolved] Failure to update GP Premium version 1.2.92

Home Forums Support Failure to update GP Premium version 1.2.92

This topic contains 34 replies, has 6 voices, and was last updated by  Tom 2 years, 10 months ago.

Viewing 15 posts - 16 through 30 (of 35 total)
  • Author
  • #249911

    Jay Martin

    Memo To Self: Never follow instructions from other users until Tom verifies the question… 😉


    Tom Lead Developer

    Sorry, I meant your settings won’t be lost. Totally safe to delete and re-upload 🙂


    Jay Martin

    Whew! Thanks, Tom. That’s a great feature.

    Memo To Self: Stop sending Memos to Self


    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 🙂


    Tom Lead Developer

    Are both of your XAMPP installations running Apache?



    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 Elementor


    Jay 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.


    Tom Lead Developer

    Haven’t given up on this – just waiting on Pippin.


    Jay Martin

    Oh, no worries, Tom.


    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.


    Jay 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):

    1. Download the theme update ZIP file and unzip the theme files onto your local machine
    2. Delete the existing theme directory from the wp-content/themes/ directory
    3. 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.


    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-update


    Jay 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.


    Tom Lead Developer

    No bother! Thanks for helping me debug – good to have a post to send people to who are experiencing this issue 🙂


    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

    Thanks, David!

Viewing 15 posts - 16 through 30 (of 35 total)

You must be logged in to reply to this topic.