Simply doesn’t work

  • Resolved jacobrossdev

    (@jacobrossdev)


    7 years, 8 months ago

    I have implemented the integrations from the sample plugin to the main file of my plugin. I also followed the naming convention so that the plugin folder, main plugin file name, and repository slug all match.

    When trying to “prime” the plugin from my bitbucket, all I get is that the repository could not be found.

    I tried uploading the plugin directly using the file input. On the plugin page of my client side wordpress admin, there is a red notice that says “Could not determine if updates are available for blah blah”.

    I try to “check for updates” from the client website where I uploaded a copy of the same plugin, “HTTP response code is 400 (expected: 200) puc_unexpected_response_code”

    I tried for about 3 hours, re-committing my plugin to bitbucket making sure the file structure was correct. I checked to make sure that my consumer/secret keys were correct. I made sure that my oauth keys were authorized to read my repos.

    Nothing worked.

Viewing 9 replies - 16 through 24 (of 24 total)
1 2
  • Thread Starter jacobrossdev

    (@jacobrossdev)

    7 years, 8 months ago

    Great! I’ll check it out and see if I can get a new clue.

    Thread Starter jacobrossdev

    (@jacobrossdev)

    7 years, 8 months ago

    I did some digging and it turns out that bitbucket is connecting just fine and downloading my plugin. The problem is somewhere in repack_package method in the zip package manager class. It’s either unable to zip it or it zips it and fails to register it to the package manager and deletes it.

    This is not a problem with connecting to Bitbucket, it’s the part where it tries to repackage it and register it. I already spent 3 hours trying to find the issue and I just don’t have anymore time to devote to fixing this.

    Plugin Author Alexandre Froger

    (@frogerme)

    7 years, 8 months ago

    Hello @jacobrossdev
    Thank you for the hard work – I wasn’t expecting you to spend even half of the time you spent on it, merely giving feedback would have been greatly appreciated already.

    If you’d still be keen on attempting to resolve the issues you’re experiencing, I added even more server logs to the WPPUS_Zip_Package_Manager class to help. Also FYI, meaningful error messages were already in place, and set to be shown via trigger_error, provided WordPress debug mode is activated.

    The packages are deleted whenever there is an issue repacking the files coming from the remote repository in the following cases – this is so that the file system does not contain the remnants of failed attempts to create the archive:

    • There is an error determining the local temp path of a package downloaded from the repository (logs the message of the wp_error object)
    • The local temp path is empty
    • The file system is not accessible
    • The archive could not me moved (usually a permission issue)
    • Unzipping the archive received from the remote repository failed
    • Zipping the archive when relevant changes have been applied failed
    • The archive received from the remote repository contains more than one directory (invalid package structure)

    On that last one in particular, it does not mean the repository itself must contain a single directory – it means the archive, when unzipped via WordPress’s call to PclZip, must contain a single directory. For example, when visiting https://bitbucket.org/user_name/package_name/src/branch_name/, I see all the files and directories contained in the final package_name, with the main file package_name.php at the root of the repository.
    If I go to https://bitbucket.org/user_name/package_name/downloads/ and click “Download repository”, I get an archive named user_name-package_name-some_ID.zip.
    When manually extracting user_name-package_name-some_ID.zip, I get a user_name-package_name-some_ID repository containing all the files of the package at its root. Because the name of the downloaded zip archive does not correspond to WordPress naming convention for packages, WPPUS_Zip_Package_Manager needs to unpack, rename, and repack the archive, and for that to happen, a specific file structure must be in place. I am not saying this is where the problem is for sure (not having access to your repository or code base), but if it is the case, I do hope the information helps.

    All these cases are now logged in v1.4.7 even when the WordPress debug mode is not active, for troubleshoot purposes.

    Thread Starter jacobrossdev

    (@jacobrossdev)

    7 years, 8 months ago

    I downloaded the newest version but I’m not finding where the logs are showing up. I checked wppus/logs and the log is not being updated. I checked wp-config.php to enable debug mode, but still no new logs.

    Also, checked my https://bitbucket.org/user_name/package_name/src/branch_name/ and the main files of my package are there, they are not nested in another directory or anything of the sort.

    When I goto BitBucket downloads and download the package, I get username-package-name-id.zip and extracting the zip file gives me username-package-name-id/username-package-name-id and all my files are within that folder including package_name.php.

    Thread Starter jacobrossdev

    (@jacobrossdev)

    7 years, 8 months ago

    Ok. I think I found the problem. My plugin dies on new ZipArchive in the zip_package method of \wp-plugin-update-server\inc\class-wppus-zip-package-manager.php

    Thread Starter jacobrossdev

    (@jacobrossdev)

    7 years, 8 months ago

    I got it working. It so happened that PHP zip extension was not installed on my server. I think that if you have an error triggered where ZipArchve is no found, it would be helpful.

    Plugin Author Alexandre Froger

    (@frogerme)

    7 years, 8 months ago

    Hi @jacobrossdev!
    Thank you very much for the information!
    You are right – I assumed the class ZipArchive would be available. I added it as a requirement on plugin activation and in the readme.txt for v1.4.8

    Again, thank you so much!

    Thread Starter jacobrossdev

    (@jacobrossdev)

    7 years, 8 months ago

    I found two other bugs. When trying to activate a plugin by license key on a localhost, I get an error “Malformed response” in the XHR requests.

    Second bug, the inline notice/warning is persistent asking for a license key depite having successfully activated one. This causes confusion for clients that think they haven’t registered my plugin correctly. It’s also kinda ugly lol.

    Plugin Author Alexandre Froger

    (@frogerme)

    7 years, 8 months ago

    Hi @jacobrossdev

    When trying to activate a plugin by license key on a localhost, I get an error “Malformed response” in the XHR requests.

    Seems like it’s a feature, not a bug 😉 – this applies to localhost (which ain’t a domain), licenses are per domain. Licenses are for plugin updates when the plugin is in production environment, whereas localhost is typically used for development or tests.

    Second bug, the inline notice/warning is persistent asking for a license key depite having successfully activated one. This causes confusion for clients that think they haven’t registered my plugin correctly.

    I’d be happy to help troubleshoot this in a separate issue (BTW it’s easier on Github for keeping track of things).

    It’s also kinda ugly lol.

    Indeed, it’s barebone – that’s code sitting in the lib folder of the dev’s plugin, devs are free to extend the WP_Package_Updater and override the methods to include different templates. I’ve been trying to keep assumptions to a minimum here and cater to immediate needs: have a field to input licenses for themes and plugins, have an error message. Devs can and are encouraged to improve the interface as they see fit.

Viewing 9 replies - 16 through 24 (of 24 total)
1 2

The topic ‘Simply doesn’t work’ is closed to new replies.