[wp-trac] [WordPress Trac] #14179: Theme asking to update (theme with same name on WordPress.org)
WordPress Trac
noreply at wordpress.org
Wed Jul 19 22:59:46 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):
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
More information about the wp-trac
mailing list