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

[WordPress Trac]

#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):

 @williampatton

 May be I had to give some examples. The raised cases are handled by the
 method very well. There is no problems to change the author and author URI
 infinitely trough the new versions at wordpress.org.

 Example 1:
 Let say there is a theme uploaded at wordpress.org that is named "ABC", by
 author "XYZ" with author URL "http://xyz.com". That theme has UID:
 abc|fff8d626c2e8cd611f66827a55028d7a

 Later the theme is acquired by another author: "MNO" with author URL
 "http://mno.com". This new version of the SAME theme (since the slug is
 not changed) has UID: abc|gfkshjg41765jg2j53nghg3ghf76323

 Let both these (the older and the newer versions) are installed at two
 separate WordPress sites.

 Then another newer version gets published by the latest author. That new
 version of the theme will have the same UID (since neither of slug, author
 and author URI's are changed): abc|gfkshjg41765jg2j53nghg3ghf76323.

 It's clear that the second site will get an update. It's not so clear on
 first look that the first site will be updated, too (so I guess that's why
 it was raised as a question) but in fact it will be updated:

 - the API gets a request to update a theme with UID
 abc|gfkshjg41765jg2j53nghg3ghf76323
 - it checks against the list of native themes' UIDs and it founds it (as
 it is an old version from the SVN) and continues (as in the workflow I
 described in the proposal) otherwise it would stop here
 - it extracts the actual theme slug which is "abc" just from the UID
 (getting the part before the delimiter)
 - continue with the algorithm and return back to the site a reply with the
 current version of the theme "abc"
 Voila!

 Example 2:
 Same happens with those cases of developers that have distributed their
 theme some time before their upload at wordpress.org. Their initial
 uploaded at wordpress.org will have the same UID that would be generated
 for their prior-upload installations. And so automatically all of them
 will get "native" to wordpress.org. Later if they upload updates, the new
 versions will have either the same UID, or linked to the same theme (as in
 the example 1) so all of their installations (even those installed before
 their upload to wordpress.org) will get an authoritative update.

 To explain again:

 - there are N themes "native" for wordpress.org (those that are currently
 active) for which the UID is precalculated (the "one time job" in the
 proposal) for all of their old and the current version in the SVN, and a
 table with that list is created
 - there are a total of N*1.56 UIDs (that's because some themes have
 "evolved" and got changed author or (in most of the cases) the author
 URI). I've got that real 1.56 coefficient from the partial download I've
 done of about 1400 themes that I've downloaded all versions of (about
 16000 in total)
 - so 1 theme is identified in general by more than one UID of the new type
 - any site with any of these UIDs is unambiguously linked by the API to
 specific theme slug (the part before the delimiter) and the API sends back
 the new version as usual (there is no changes in this part of the code at
 all)
 - any external theme with the same name however comes with different UID
 and so the API stops at that point where this UID is unknown (not present
 in the table of UIDs) and so doesn't send back an update info, nor counts
 this as active install.

 It is very simple but efficient.

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