question about plugin submission(s)

[mc12345678]

It's been a while since I have submitted a new plugin, but I've noticed that some of those that have submitted one have been able to identify what the download link will be. I'm curious what process does this and further if there is a way to "reserve" this link so that the information could be incorporated into the plugin where it is possible to identify when an upgrade is available? Either that or provide direction during submission to update the location in the code to provide the same?

[lat9]

Since I just finished this process, here's how I go about it:
1) Create the support thread, noting that the download link will be supplied once it's known. This way, you've got the link to the plugin's support page when you upload the new plugin.
2) Upload the new plugin, pasting the support-thread link from the thread you just created.
3) Zen Cart will send you an email with the download link that can be used once the submission is approved.
4) If you're quick enough, you can edit your previous thread posting to add the download link; otherwise, just create a new post with the link.

[mc12345678]

Seems like a sound process. Thanks for that.

Now to address the added feature(s) of ZC 1.5.3 with the added function plugin_version_check_for_updates that reaches out to the ZC server(s) for information about the current version of the identified plugin and can be used to provide the store owner/operator notification of an available update. Somewhat seems like a chicken/egg scenario, and wondering what the "correct" (preferred) way to incorporate that feature should be as a result of the following information and assumption(s):

1. As a plugin contributor, (assumption) won't know the specific data that will populate the field(s) until the plugin is made available on the site.
2. Once the plugin has been made available, incorporation of the information into the code and reupload (assumption) has the potential of modifiying the information that was made available to support the resubmission. This has the potential of making the new information out-of-date, requiring a "newer" submission... and this loop continues to no success...

Yes, the above has a bit of an extreme assumption; however, trying to identify what the process is/will be to support this new beneficial operation.

If the thought is that in the submission process to identify the file/line number to incorporate the data, then so be it or if there is an expectation to then post a corresponding "file" to the support forum, that's also well and good, though may get missed by those downloading the package unless the plugin also has a notification that the file to be downloaded hasn't been and provides a link to the thread (incorporation of which would more than likely exceed the timeout to edit the original message for the thread and therefore would suggest the link simply pointing to the thread not to a specific post).

This functionality can be seen in the USPS module. In particular installation of the version offered at the start of this year results in a notification in the modules->shipping section adjacent to the USPS plugin title because there is a newer version available.

Ideally, this type of functionality could be incorporated into other plugins moving forwards (for those either installed on ZC 1.5.3 or that include code to reproduce the same functionality in older versions). In the case of the USPS module, the notification is "innocently" appended to the title of the plugin; however, notification could be made in other parts of ZC as well (header bar notification or other areas/ways). Having seen requests to identify what version is installed or if an installed plugin is the most recent, it seems that this functionality was added to support more of a "routine" use and I'm trying to understand/document the proposed process. :)

[lat9]

Seems like a sound process. Thanks for that.

Now to address the added feature(s) of ZC 1.5.3 with the added function plugin_version_check_for_updates that reaches out to the ZC server(s) for information about the current version of the identified plugin and can be used to provide the store owner/operator notification of an available update. Somewhat seems like a chicken/egg scenario, and wondering what the "correct" (preferred) way to incorporate that feature should be as a result of the following information and assumption(s):

1. As a plugin contributor, (assumption) won't know the specific data that will populate the field(s) until the plugin is made available on the site.
2. Once the plugin has been made available, incorporation of the information into the code and reupload (assumption) has the potential of modifiying the information that was made available to support the resubmission. This has the potential of making the new information out-of-date, requiring a "newer" submission... and this loop continues to no success...

I didn't read your previous post very well -- just the title!

Re: Using the plugin_version_check function, it's a chicken/egg thing for the very first submission since, until the plugin is approved you don't know the plugin's download id. Using the usps shipping module as the basis, the function call looks like:

        $new_version_details = plugin_version_check_for_updates(1292, '2014-10-30 K6');

The 1292 value is the plugin's download id, assigned upon the first submission, so a plugin will require an update after the initial submission to add this functionality. The second parameter appears to be the version number specified by the plugin author at the time of upload, so if you uploaded a plugin with v1.0.0 that's what you'd specify as the second parameter.

[mc12345678]

I didn't read your previous post very well -- just the title!

Re: Using the plugin_version_check function, it's a chicken/egg thing for the very first submission since, until the plugin is approved you don't know the plugin's download id. Using the usps shipping module as the basis, the function call looks like:

        $new_version_details = plugin_version_check_for_updates(1292, '2014-10-30 K6');

The 1292 value is the plugin's download id, assigned upon the first submission, so a plugin will require an update after the initial submission to add this functionality. The second parameter appears to be the version number specified by the plugin author at the time of upload, so if you uploaded a plugin with v1.0.0 that's what you'd specify as the second parameter.

Yeah, guess I should have used "questions" in the title. :)

Well, seeing my track history with plugin submission of having to submit a second time because I seem to forget something minute on the first submission and that my latest submission finds it's way to the site, I probably could see these things all falling into place relatively quickly.

1. Start thread post (don't hit submit yet).
2. Start plugin upload (all files so far up-to-date with exception of the plugin id). Identify that a second equivalent upload will be provided with the plugin download location included, so that reviewer(s) don't start right at that minute if they are/were so inclined/available.
3. Submit thread.
4. Update plugin area with thread information.
5. Update post with emailed plugin path (if times out add separate post)
6. Modify file(s), zip files again for submission.
7. Resubmit upload indicating to replace the previous submission to account for the version check.

Done...

At least that way the brave few that start out the gate because the program seems right but haven't yet considered the need to periodically check for an update because it works fine as is, will be looped into the update notification. Otherwise, second+ versions would be fine, but I was trying to consider the full audience, not just the "late" comers. :)

[DrByte]

Yeah, guess I should have used "questions" in the title. :)

Well, seeing my track history with plugin submission of having to submit a second time because I seem to forget something minute on the first submission and that my latest submission finds it's way to the site, I probably could see these things all falling into place relatively quickly.

1. Start thread post (don't hit submit yet).
2. Start plugin upload (all files so far up-to-date with exception of the plugin id). Identify that a second equivalent upload will be provided with the plugin download location included, so that reviewer(s) don't start right at that minute if they are/were so inclined/available.
3. Submit thread.
4. Update plugin area with thread information.
5. Update post with emailed plugin path (if times out add separate post)
6. Modify file(s), zip files again for submission.
7. Resubmit upload indicating to replace the previous submission to account for the version check.

Done...

At least that way the brave few that start out the gate because the program seems right but haven't yet considered the need to periodically check for an update because it works fine as is, will be looped into the update notification. Otherwise, second+ versions would be fine, but I was trying to consider the full audience, not just the "late" comers. :)

Duplicate submissions is only going to make extra work for moderators, which will probably result in delays getting things reviewed.

At the present time "new submissions of new plugins" don't have an easy way to concretely identify the number that will be assigned.
DO NOT bother trying to "game the system". We'll probably just delete your submission if you do that.
If your plugin has a critical need for automated detection of updates, add it in your next update when you fix bugs or add other functionality.

Making changes to allow for a reservation of some future unique code will require coding adjustments in the backend that currently fall into the "lower priority" category ... and may create backward compatibility problems too ... so need to be carefully thought out.

This is an unfortunate chicken/egg problem. But it's a good problem to have :)

[mc12345678]

On the flip side of things and why I didn't want to bother one of the moderators via PM is that with the process being discussed in an open forum, my next thought is that with the restriction/expectation of single posting a new plugin, that if the thought of software upgrade notification is to be included that there are two things that could be considered: 1. Force a notification to check the plugins for an update. 2. After posting the first thread post, set the notification to have a clickable link to the thread indicating something about checking for updates. This would then be part of the original submission to be updated on next revision. That way basically have the loop closed to address the update check at all points of "production". *with heavy sarcasm* oh shucks I couldn't edit my post in time because I was compressing my changed file into this zip for submission. Guess I'll have to post a second message to provide the link. I would be happy if I could say those two sentences. :) at least then I would know I did it right... Will be a fun challenge to see if/how often it can all be done before the edit timeout where the file is submitted once and the thread post is edited instead of being posted to twice.

I'm not trying to make extra work for anyone, just trying to see how we (volunteer coders) can continue to consider the needs of the new zenners with the functionality provided us out-of-the-box.

[mc12345678]

New list:

1. Start thread post (don't hit submit yet).
2. Start plugin upload (all files so far up-to-date with exception of the post thread location). Be sure code is present for future upgrade notification upon next submission of the pluginm
3. Submit thread.
4. Update plugin area with thread information. Including updating the files to reference the thread as part of the notification link. Files to be fully submitted.
5. Update post with emailed plugin path (if times out add separate post)
6. Await comments/identify changes or improvements. Modify file(s) be sure to update the version check section if it needs updating, zip files again for submission of a version change.
7. Resubmit upload with changes and as necessary repeat the previous step and this step... :)

[DrByte]

You seem very intently focused on nailing down a policy/procedure on something that's extremely new and not officially published yet.
What exactly is this plugin you're anxiously waiting to publish with automated update notification?

[swguy]

Remember that worst case if something gets messed up you can PM your friendly plugin moderator and he will address your request. :)