hardcoded version list Subs-Editor.php

[illori]

    $versions = array(
        'SMF 1.1',
        'SMF 1.1.1',
        'SMF 1.1.2',
        'SMF 1.1.3',
        'SMF 1.1.4',
        'SMF 1.1.5',
        'SMF 1.1.6',
        'SMF 1.1.7',
        'SMF 1.1.8',
        'SMF 1.1.9',
        'SMF 1.1.10',
        'SMF 1.1.11',
        'SMF 1.1.12',
        'SMF 1.1.13',
        'SMF 1.1.14',
        'SMF 1.1.15',
        'SMF 1.1.16',
        'SMF 2.0 beta 1',
        'SMF 2.0 beta 1.2',
        'SMF 2.0 beta 2',
        'SMF 2.0 beta 3',
        'SMF 2.0 RC 1',
        'SMF 2.0 RC 1.2',
        'SMF 2.0 RC 2',
        'SMF 2.0 RC 3',
        'SMF 2.0',
        'SMF 2.0.1',
        'SMF 2.0.2',
    );

we have the above list in Subs-Editor.php, this list would need to be updated at each version upgrade, unless it is documented somewhere this list will not be updated and would confuse users that try to use the drop down. as it is currently it is missing 1.1.18 and 2.0.4

[Arantor]

As per the above mentioned pull request, we need some API on the sm.org website that will list all the suitable versions.

I'd personally suggest it need not be anything more complex than a simple text file listing all the versions since 1.1 final. Interestingly that still means we end up having to maintain list, it just means we don't do it in the software but we do it on the site - that'll be more useful once 2.1 final goes out and we get into 2.1.1 territory.

If it is a simple text file, I see no reason why it can't be pulled via the existing admin_info_files mechanism and then the auto suggest task can do a lookup on that information (doesn't have to be accessed via viewsmfile after all)

[illori]

sounds good to me, that would make it easier to keep the list updated, but what would happen if a user does not upgrade but gets a list that includes versions greater then what they have installed?

sadly we do have users that dont upgrade, or dont upgrade in a timely manner. i guess it does not really cause an issue overall, as the version is assumed automatically and very few should even need to use this drop down

[Arantor]

Hmm, yes, I'd forgotten about that.

[emanuele45]

I would simply remove the list as it is almost useless "nowadays". ;)

[illori]

how well has the new auto version emulation feature been tested? if it works 100% of the time then the emulation area could be removed

[emanuele45]

I didn't say to remove the entire emulation area, you never know what it may be wrong, just the list.
And the autosuggest of course.

[illori]

the list is actually a good idea IMO as some people do have issues with what version to put in the box

[jdarwood007]

I think we can add this as another .js file (so it is a json_encoded array) and push it into the latest SMF file fetching code. Solves the problem. This would either be stored in the database or a cache file.

[Arantor]

It'd be stored in admin_info_files. I haven't touched that code in a while, does that export the current SMF version in the lookup URL?

[jdarwood007]

Yes, when those requests are made it pushes the current SMF version as defined by $forum_version in the querystirng. We do make use of that to do things like properly serve SMF 2.0 or SMF 1.1 information.

[Arantor]

Cool, provided we make sure sm.org can serve that appropriately, let's do that.

[illori]

sounds good to me.

[jdarwood007]

Well I've ideas on how to change that even. I should push that discussion over to internals at this point, since its a site configuration thing really.

[Oldiesmann]

Sounds good SleePy.

[Arantor]

Raised issue in appropriate board. Meant to do it earlier but forgot.