Simply doesn’t work
-
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.
-
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 ofDIRECTORY_SEPARATORin the class itself.I will update the dummy plugin and dummy theme to fix the issue. In the meantime, you can safely replace
DIRECTORY_SEPARATORby/in theWP_Package_Updaterclass.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?
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{ "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.
Thank you ; I can see the there is
license_errorproperty, which means license check is activated for this plugin. Is it intentional? This is where thedownload_urlproperty 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 callingnew WP_Package_Updaterin 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 adownload_urlproperty can be found, the update process can work.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.
The topic ‘Simply doesn’t work’ is closed to new replies.
