[wp-trac] [WordPress Trac] #14179: Theme asking to update (theme with same name on WordPress.org)

Fri Jul 21 16:55:03 UTC 2017

#14179: Theme asking to update (theme with same name on WordPress.org)
----------------------------+----------------------------
 Reporter:  design_dolphin  |       Owner:
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  WordPress.org
Component:  Themes          |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+----------------------------

Comment (by dingdang):

 Hey, since I can't find a way to attach here .pdf files, I've copy/pasted
 something final as a proposal here. More of the things are already
 explained, there are some new.

 '''Proposal for a solution to the “collisions” of WordPress themes.'''

         '''Table of contents:'''
         Introduction
         Formal composition of a unique ID.
         API: determination of available theme updates.
         Other: calculation of theme's active installs.
         Benefits.
         Technical data.

 '''Introduction.'''

 A '''collision''' is a term that is describing the slug match of two
 themes that are not related to each other but have the same name.

 '''Two main problems''' are related to these cases of collisions:

 1. If there is a theme in the wordpress.org's database of themes and
 another one, created by another author, the second one would get an
 “Update” option and possibly will be replaced by the theme, published at
 wordpress.org. This can happen also to well distributed themes after
 uploading a new theme with the same name at wordpress.org and unexpectedly
 after an unwanted update to replace themes of web sites published long
 time before that.
 2. Calculation of active installations is taking in count not just those
 of the themes from wordpress.org's database, but as well other external
 themes as well random child themes residing in a folder with a matching
 name. Thus, authors exploit this to artificially place their new themes on
 top of the list by catching  names of long time distributed external
 popular themes.

 '''The proposed techniques solve all of the problems, with very little
 coding, while keeping backward compatibility, and solving the related
 problems for the old themes as well, not just the newly released.'''

 '''Formal composition of a unique ID.'''

 1. Need to chose a separator, that is currently not allowed to be present
 in theme names. Ex: “|”; will be used below.
 2. For every theme since WordPress 3.0 (and may be even earlier versions)
 the code is already reporting the following three strings:
 - theme '''Slug''' (ex: nicetheme)
 - theme '''Author''' (ex: John Doe). May not be present, if not – this is
 an empty string.
 - theme '''Author URI''' (ex: http://johndoe.com). May not be present, if
 not – this is an empty string.
 3. Compose a '''string''': “slug|author|author_uri”. Ex: “nicetheme|John
 Doe|http://johndoe.com”
 4. Calculate the '''MD5'''. Ex: “fff8d626c2e8cd611f66827a55028d7a”
 5. '''Final UID''' for that specific theme by concatenating again the slug
 with the MD5 using the same separator: “slug|MD5”. Ex:
 “nicetheme|fff8d626c2e8cd611f66827a55028d7a”

 Since all of the three fields are present in the themes (trough style.css)
 and are reported by WordPress (even by the very old versions) there is no
 need to implement and add any new data to the themes (like manually adding
 codes/hashes) nor to the code of the core or API to handle them.

 A one-time calculation of the UIDs for the current themes must be
 performed and store the list in a table.

 For all new theme version updates and new theme uploads, the UID will be
 calculated and added to the same table.

 As the UID contains the theme slug as a prefix, it is trivial to relate a
 given UID unambiguously to the theme slug if needed.

 '''Optimization''': (not needed, see the technical data) several lines of
 code can be added to WordPress core to calculate and add to the API call
 the UID at the client side, to save some API CPU time.

 '''API: determination of available theme updates.'''

 If the calculated UID is not provided by the client, it is calculated
 based on the three fields received trough the API call (as described
 above) by the API's engine.

 A small update (several lines of code) is needed to identify themes not by
 just a slug, but by this new UID, checking in the table of UIDs. Only if
 the UID is present the algorithm continues by identifying the theme slug
 from the UID and checking as usual if there is newer version and if so –
 to send back an “update available” reply.

 '''Other: calculation of theme's active installs.'''

 Active installations of a given theme are calculated by the sum of active
 installations for all the IDs related to that theme. This will result in
 real numbers and the “Popular themes” list will be sorted using the real
 numbers for the themes at wordpress.org, automatically excluding all the
 counts related to external themes (i.e. the wrong current numbers will be
 corrected to their true values).

 '''Benefits.'''

 - it is handled automatically;
 - solves all the problems;
 - fully backward compatible (old WP versions);
 - solves the problem for the old existing themes as well;
 - solves the "Active installs" count problem – active installs will count
 automatically just the real active installs of the wordpress.org's theme
 even for the old cases and exploits;
 - theme authors don't have to do anything – no changes to style.css or
 anywhere from their standpoint;
 - external authors don't have to do anything to prevent their themes to be
 messed by unwanted updates – no need for "private" tag;
 - no need for changes in the core (unless for optimization);
 - the check for updates at the backend (API) is almost the same, the
 search is performed in a table of UIDs instead of theme slugs;
 - since there is no change in the theme's structure and new fields, the
 updates related to API and Active installations counting are independent;
 can be done at different points in time;
 - backward compatibility for the old versions of WordPress and old
 versions of the themes w/o the need to change them which is the best part
 of this proposal.

 '''With simple words – implementing it the proposed way will put
 everything in place in a way like it was so from the beginning of
 WordPress existence.'''

 '''Technical data.'''

 Some tests were performed to help on decisions.

 1. An average single server executes '''100,000,000''' md5() calculations
 using PHP in '''40 seconds'''. If this is the daily number of requests for
 update checks to the API, that means only 40 seconds of additional CPU
 time will be needed, even if all the calculations are done by the API.
 '''In fact the optimization to make the calculation at the core is not
 needed.''' This will save programmers from adding code to the core and
 changing the API protocol by adding new fields.
 2. There are:
 - '''4876''' total themes at wordpress.org;
 - '''56730''' total different versions;
 - '''11.6''' average versions per theme;
 - '''1.5''' the average ratio of different UIDs per theme (a single theme
 has more than one related UID if the author or author URI have been
 changed over the time);
 - '''7300''' (approximately) generated UIDs for the current themes (the
 new list to search in, instead 4876), i.e. no difference in the CPU time
 needed to process search requests.

 ''07/21/2017
 by dingdang''

--
Ticket URL: <https://core.trac.wordpress.org/ticket/14179#comment:35>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform