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

 Some ideas how to solve this while:
 **(A)** Having backward compatibility - older versions of WordPress to
 handle (at least partially) the new implementation w/o any new code;
 **(B)** Maximal prevention of abuses;
 **(C)** Solve several problems at once as: 1. unwanted updates of not
 related themes 2. abuse of "Popular" themes page;
 **(D)** Minimal needs for new code writing.

 (I will use these **(A)**,**(B)**... marks below when related, not to
 repeat the above.)

 1. For all NEW themes - to add a generated prefix to the slug. The prefix
 should be unique and non-existing at the moment at svn. An example of such
 is "tNNNN-". This is required so old themes are not misinterpreted as new
 with a prefix. In the beginning unique prefixes (ids) can have 4 digits
 like "t2345-", after these are used to use 5 digits "t23456-" and so on.
 If a new theme is called "The Theme" its slug will be "t2345-the-theme".
 **(A) (C) (D)**

 2. For all UPDATES, authors should add an additional line in style.css's
 header: Uid: t2345 **(C)**

 3. New section at profiles.wordpress.org for logged in users for theme
 name reservation: the user can check trough a simple form if a name is
 available (checking the current svn and other reserved names) and if it is
 available – the system will reserve the new name for 1 hour **(B)**,
 generate the next available uid for that name and provide it to the user
 so he can include it in the style.css file. After an hour a garbage
 collector releases the name and uid if a theme with that name is not
 uploaded in the meantime. **(B)**

 4. In the same section the system will permanently auto-assign UIDs for
 all current themes, so the author could get it for inclusion in style.css
 in the future updates of that theme.

 5. Inclusion of UID in style.css is mandatory for all updates, not
 mandatory (would be ignored) for all new themes as it is present in the
 slug. **(A)**

 6. CORE: Send to API not just the slug, but the UID as well, if present in
 style.css. Slug of the new themes is the extended one, no need to do any
 additional tasks. **(A)**

 7. API: If the slug is of the extended type, do nothing special. If there
 is an UID in the data received, concatenate that UID to the slug in the
 form “UID-slug” and proceed as usual. **(D)**

 N.B. "Old" themes can be easily distinguished from "New" by looking at
 their slug and locating a presence of the prefix (so no need to store any
 additional data anywhere for the themes regarding this).

 >One decision has to be made about how long (or infinitely) to count for
 old themes as active installs both the extended slug and the old slug
 (like to ignore at some point the old slug after let say 1-3 updates) -
 this is required in order to detach all counts of active installs that
 have nothing in common with that specific theme (like child themes named
 the same way, other themes from other marketplaces, random custom themes,
 etc).

 All of the above solve all the problems related to name collisions; new
 themes extended slug works even on older WordPress installations; several
 lines of code needed for the core and API, not much for the name check and
 UID generator form for the logged in users and several lines for the
 sorting algorithm for the "Popular" page.

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