Support » Requests and Feedback » Plugin and Theme – Same Name Conflict from different Authors – method to fix

  • Problem ;
    Some themes use the same name as another already established theme.
    And some plugins may or may not do the same thing.
    But some plugins may use folders by the same name even if the plugin name is different.

    For the process that accepts new themes and plugins –

    Possible Solution – Concept;
    Require that the metadata that is associated with the uniqueness check for a theme/plugin, includes the author name.
    The date of first creation can also be included (version numbers get treated the same as presently).
    So even if the theme/plugin has the same name, the combined data will be different.

    Example Implementation methods;
    a) Listing of the theme/plugin in lists, ‘ties’ the plugin name with the author name.
    A plugin is therefore not referenced (if using a stringent mode) by name alone, but also the additional associated metadata.
    The name of the folder that the theme/plugin gets installed to, is named based on the name of the plugin, the name of the author, and the date of first creation.
    Folder names will be longer than at present, but will be much more likely to be unique, and will cope with the majority of random items.
    The probability of ‘accidental’ conflict of matching names and folders, is drastically reduced.

    or
    b) WordPress takes the plugin name, author name, and date of first creation, and uses a standard method to generate a code and/or folder name for the plugin.
    There may be an option to generate an error detection/correction check number, so alteration is more difficult.
    This folder name is then issued by WordPress and is checked (automatically against its list of plugins) as being unique, and given to the plugin author to use as their unique plugin name and/or metadata, and folder name.

    There are other variations that are possible, but it is hoped that something like the concept described here may be helpful in obtaining the following benefits;
    a) The theme and plugin names and folders are much more likely to be unique.
    b) If wordpress issues the unique name, then there can be no argument about any actions made by ‘other’ theme or plugin authors (date of first creation can help solve this).
    c) The theme and plugin authors are less likely to have to retrospectively make adjustments to avoid conflict.
    d) The theme and plugin authors are protected from actions of other authors that may wish to pass their product off as being the original product (and do what ever they do), which significantly increases their confidence in the system.
    e) since the system uses small metadata for each plugin, and lists can be maintained (as they already are for themes and plugins – on wordpress site), then having made/generated an name, it can easily be automatically checked against the list to check for conflicts (this check could be initiated by the author or the staff that process plugin submissions.

    Note
    Themes/plugins which are available only from off site locations, may still be permitted to join a separate list (of this metadata), that works the same way.
    So all theme/plugin authors that are keen to avoid conflicts can join the respective list, and get checked against both lists. This would reduce the chance of a conflict even with themes and plugins which are not downloadable or listed on the wordpress site.
    The user does not need to know which plugins are not downloadable, as they are not presented with those anyway. But the user gets the piece of mind that the chances of conflicts with other plugins on the net have been reduced.

    Using methods that have reduced the chances of ‘accidental’ name/folder conflict, means that precautions can be taken in the unlikely event of a conflict happening.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator Jan Dembowski

    (@jdembowski)

    Brute Squad and Volunteer Moderator

    I think you’re overthinking and over engineering this by a great deal. 😉

    If a name or slug is already used, why wouldn’t the plugin or theme author just use a different name or slug as they do today?

    That’s how this is sorted out today and it works.

    Read this ticket and the Make post it references:
    https://meta.trac.wordpress.org/ticket/3192

    Hi Joy,

    Thanks for the link, and some implied acknowledgement of importance.

    Those folks sure are doing some thinking (may I encourage it).

    That ticket seems to be primarily addressing a function to ;

    serve plugin checksums for all the files for all plugins from the plugin repository, in all their versions.

    That is good for checking that something (e.g. file and folder) is what it is.

    What I am talking about is checking that something is not appearing to be something else.
    That requires a test for uniqueness.
    My suggestion does that by including the author’s name, and date – which have high probabilities of uniqueness.
    And if the author’s name is the same, then there are problems,
    and if the dates are the same as well as the plugin name and author name being the same, there there should be questions.

    In either case;
    having satisfied the checks for being correct (e.g. checksum),
    there can also be a check for uniqueness.
    I have suggested plugin name, author name, and date, for forming some sort of uniqueness test.
    Checksum (of the file and folder names) could also be used for uniqueness.

    Combining the two, the checksum could also include the other meta data, which is a way of checksum-ing the measure of uniqueness.

    A thought for the team at that link is ;
    “consider how plugin upgrades can work so as to minimize risk of intervention at the point of update”.
    The themes that are ‘spoofing theme name’ (or what ever that process is called), do so at the time of update.
    A method to maintain confidence during update is possibly to

    Use a coded identifier for a plugin that ;
    a) identifies the plugin across all versions
    b) indentifies how the next (or group of subsequent) updates will be uniquely identified, so that when an update is declared, the update identifier will match the unique identifier supplied by the previous version (of the same plugin, by the same author, originally created on the same date). This might involve getting issued with a unique identifier, so that the same identifier is not issued to any other author or plugin/theme

    This may not fully prevent incorrect updates for a plugin or theme, but what it does do, is eliminate the chance that such an event is an accident.

    Also
    Joy,
    I am not sure what “make” you were meaning, but would this have been the link from that page that you were referring to? ;
    https://meta.trac.wordpress.org/ticket/619

    Thanks

    • This reply was modified 2 months, 3 weeks ago by  MKSnMKS. Reason: added something I forgot to include
Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.