Simply doesn’t work

  • Resolved jacobrossdev

    (@jacobrossdev)


    6 years, 5 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 15 replies - 1 through 15 (of 24 total)
  • Thread Starter jacobrossdev

    (@jacobrossdev)

    Also, right out of the box I get this error message after activating my plugin after implementing the code from the dummy plugin:

    Notice: Undefined offset: -1 in D:\xampp\htdocs\dev\woocommerce\wp-content\plugins\woocommerce-product-table\lib\wp-package-updater\class-wp-package-updater.php on line 97

    Plugin Author Alexandre Froger

    (@frogerme)

    Hello @jacobrossdev
    Thank you for the feedback. I’ll investigate with the provided information, and report back here shortly.

    Plugin Author Alexandre Froger

    (@frogerme)

    I seem to have found the issue regarding the second message you sent: it’s how Windows system paths are handled. The issue would not happen on a production server (assuming it’s not a Windows server).

    There is a mix up between the use of wp_normalize_path (which converts backslashes into forward slashes in a string, among other things) in the constructor call of the updater class in dummy plugin, and the use of DIRECTORY_SEPARATOR in the class itself.

    I will update the dummy plugin and dummy theme to fix the issue. In the meantime, you can safely replace DIRECTORY_SEPARATOR by / in the WP_Package_Updater class.

    Regarding the issues noted in the first message, I would still need to investigate – it seems to me this type of issue is harder to troubleshoot for me as they occur on a localhost: the plugin was developed using a development and a staging server to make sure it reflects real life use, therefore its is difficult for me to replicate the environment leading to the 400 Bad Request error. Is there more information you could provide, such as the result of API calls inspected with Query Monitor?

    Thread Starter jacobrossdev

    (@jacobrossdev)

    I can check the bitbucket connection using Query Monitor, however, I was using WP Plugin Update Server on a remote hosting server and not on localhost. I only tested whether I can update my hosted plugin from my local machine.

    Plugin Author Alexandre Froger

    (@frogerme)

    I see – thank you for the information.
    In the browser, after clearing your permalinks, what would be the result of visiting the following URL (edited where applicable and assuming the licenses are not enabled for this plugin)?

    https://your-update-server-domain.tld/wppus-update-api/?update_action=get_metadata&plugin_id=woocommerce-product-table

    Thread Starter jacobrossdev

    (@jacobrossdev)

    {
    "name": "WooCommerce Product table",
    "version": "1.0.0",
    "homepage": "https:\/\/jacobrossdev.com",
    "author": "Jacob Ross Web & App Development",
    "author_homepage": "https:\/\/jacobrossdev.com",
    "last_updated": "2018-10-14 00:03:29",
    "slug": "woocommerce-product-table",
    "license_error": {},
    "request_time_elapsed": "0.060"
}

    This comes from manually uploading, although I would prefer that I use bitbucket, I don’t mind doing it this way if I can get rolling on this right away.

    • This reply was modified 6 years, 5 months ago by jacobrossdev.
    Plugin Author Alexandre Froger

    (@frogerme)

    Thank you ; I can see the there is license_error property, which means license check is activated for this plugin. Is it intentional? This is where the download_url property should be instead.
    If this is not intentional, please make sure to disable the license for this plugin in the “Overview” tab, and maybe omit the last boolean parameter when calling new WP_Package_Updater in your main plugin file.

    If the license check is activated for the plugin, then the URL to visit in the browser above should include more parameters (license and signature in particular), which I cannot guess – you can find them using Query Monitor would you decide to test with license checks enabled.

    Aside from this license_error, everything seems to work as intended ; once a download_url property can be found, the update process can work.

    Thread Starter jacobrossdev

    (@jacobrossdev)

    I’ll check this again and get back to you.

    Plugin Author Alexandre Froger

    (@frogerme)

    I tested just now and noticed the package name string is not the same as the intended plugin slug – it has the date appended to it.
    Extract from the on-screen help:

    The archive needs to be a valid WordPress plugin or theme package.
    In the case of a plugin the main plugin file must have the same name as the zip archive – for example, the main plugin file in package-name.zip would be package-name.php.

    Thread Starter jacobrossdev

    (@jacobrossdev)

    Hi Alex,

    I can assure you that my naming convention is correct. In fact, I updated the WP_Package_Updater class as you suggested and I am able to update my plugin as expected.

    However, I updated my plugin with a new version number, manually updated the package and toggled the license requirement. I was still able to update my plugin without being prompted for the license key.

    I deleted the plugin from my local wordpress installation, redownloaded the plugin from the package manager and added it to my local wordpress installation. After activating it, I was still not asked for a license key.

    I created a license key and went back to my local machine and “checked for updates” I was still not asked for a license key.

    No more errors, but I’m not being asked for a license key.

    Thread Starter jacobrossdev

    (@jacobrossdev)

    I checked again and realized that I didn’t add the fourth argument to the WP_Package_Updater class. I changed this because of testing and added it back.

    Ok. I can use this plugin without errors manually uploading my plugin to your plugin package manager.

    The final issue is that I haven’t been able to use a bitbucket repo.

    • This reply was modified 6 years, 5 months ago by jacobrossdev.
    Thread Starter jacobrossdev

    (@jacobrossdev)

    Error - could not get remote package. Check if a repository with this slug exists and has a valid file structure.

    I’m not getting anything in Query Monitor that tells me why the plugin can’t find my repo.

    The folder, file and repo slug all match woocommerce-product-table and I have an auth key that is permitted on my domain with “private consumer” checked. The permission set is to read repos.

    Plugin Author Alexandre Froger

    (@frogerme)

    Glad to see most of it is working!

    Regarding the remote repository part, could you confirm with me the value in the field “Remote repository service credentials” follows the format Key|Secret where Key and Secret are the values provided by the OAuth consumers section in bitbucket (with no space, just the 2 values separated with a pipe)?

    If this is not it, then I’ll investigate further. I personally use this plugin with Bitbucket for my own projects, therefore it may be a very specific error I do not experience.

    For me to help troubleshoot with more more information from you, the code would need to be edited. Indeed, this particular alert does not give the most meaningful message… I’m improving it right now, with extra server logs output, and will commit a new version in approximately 8 hours (I’m on Beijing time).

    Plugin Author Alexandre Froger

    (@frogerme)

    Another thing: the content of wp-content/wppus/logs/ may give us a clue, as it logs the requests going out to the repository service (bitbucket).

    Edit – it logs the incoming requests, not the outgoing ones – never mind…

    Plugin Author Alexandre Froger

    (@frogerme)

    @jacobrossdev v1.4.6 is out with better error handling and output to server logs.

Viewing 15 replies - 1 through 15 (of 24 total)
  • The topic ‘Simply doesn’t work’ is closed to new replies.