Add delist option to theme directory

[dd32]

The plugin directory has three main states, Published, Closed, and Disabled. Disabled is a hybrid between Published and Closed, where the plugin can be updated and serve updates, but is not fully published into the directory.

The Theme Directory has two states - Published and Suspended.

Occasionally the Theme Directory has a similar need to the plugin directory, where a theme should able to be updated, but shouldn't appear in search results / archives.

A delisted theme should still be accessible directly (ie. /themes/my-theme/) and serve updates.

I don't think Disabled works for the Theme Directory, which is why I'm suggesting it should be called Delisted instead.

[carike]

:wave:
Hallo, Dion.
Is it possible to require login to see the readme.txt content for delisted themes?
That way, search engines would not have access to that particular content, without breaking the .org internal search, which relies on Google.

[bph]

In the unfortunate event that a theme needs to be delisted, I would think, that it would hardly trigger any particular behavior change, if it wouldn't be also removed from the search results of current available themes in the repository and from the WP-admin screens.

In the case of a 5 week suspension, the theme should not be visible in the repository.

The only actions that should work would be

• upload a new version by the theme author
• the visiblity of the Update notification in WPadmin, and
• And the update process from the repository

[dingo_d]

@dd32 If I understood right from taking a look at the code, it's just registering new post status, in the admin-edit.php like

register_post_status( 'delisted', array(
    'label'               => __( 'Delisted', 'wporg-themes' ),
    'protected'           => true,
    'exclude_from_search' => true,
    'label_count'         => _n_noop( 'Delist <span class="count">(%s)</span>', 'Delisted <span class="count">(%s)</span>', 'wporg-themes' ),
) );

The query done in the themes list is pinging the API which only shows published themes. This way, the theme won't be posted and searched, but won't be blocked for updates (which are blocked if the status is suspended).

[dingo_d]

Added patch for the new repopackage post status

[carike]

Replying to carike:

:wave:
Hallo, Dion.
Is it possible to require login to see the readme.txt content for delisted themes?
That way, search engines would not have access to that particular content, without breaking the .org internal search, which relies on Google.

After discussion with Jono, there should please be a no-snippet tag on the readme contents instead.

[ionutn]

Hey,

I am not sure if it is possible, but at least I think it makes sense that the themes would rank for their name only. Those users know already what they want and in those cases the directory would just create a bad experience for them, forcing them to move on Google, find the zip and come back to upload it.

Re: the penalty, if this feels unfair for other authors like us that got suspended in the past, or lack of consistency in the TRT messaging, I guess the authors can have the option or TRT would decide: 6 weeks with brand search ban vs 8 weeks or more for e.g without brand search ban.

This should keep both a good directory experience for users and content creators + a fair treatment regarding the guidelines broken.

[carike]

Hallo @ionutn ,

Per discussion in the meta channel on Slack, the main aim is to create a basis and then improve on that later (e.g. introducing date-pickers and other nifty tools to make it more versatile).
If this takes too long to implement, that is not beneficial to anyone.
While having a brand search vs. non-brand search delistings can perhaps be useful, there should not be so much complexity introduced into the ticket that it takes effectively never happens.
From what I understand, the current design requirement is that it should be possible to find a theme for an exact-match of their name.

Re: the penalty, if this feels unfair for other authors like us that got suspended in the past, or lack of consistency in the TRT messaging,

This is really not the right forum for that discussion.
Please comment on the relevant P2 post, so that the input can be taken into consideration.

[acosmin]

@dd32 could you please take another look at this. :) It doesn't need datepickers and all that stuff for now. A simple button will do (exactly like in the ticket description)

Thank you!

[acosmin]

@tellyworth Hi! Would it be possible to rush this :) make it a high priority? We would like to introduce some new policies/requirements and it is all tied up to this ticket. It would mean a lot to us.

Thank you for contributing time to this.

[tellyworth]

A lightly tested attempt

[tellyworth]

attachment:5362-delist-actions.diff​ is a first pass at implementing this. It makes some assumptions that need checking.

• Delist is only available from a published state.
• Relist will set the status back to publish.
• Delisted themes are excluded from site search.
• Something is wonky in the noindex handling, but if it worked it would use nosnippet.
• There is no bulk or row action because I'm assuming this will be used sparingly.

[tellyworth]

Fixed the nosnippet issue; also found some other bugs. Thanks @dd32!

[tellyworth]

Fix a bug in the .2 version where noindex could be overridden

[poena]

Does the delist state change if the trac ticket status is changed?
For example if a trac ticket has been reopened and the trac status is changed to live.

[tellyworth]

Replying to poena:

Does the delist state change if the trac ticket status is changed?
For example if a trac ticket has been reopened and the trac status is changed to live.

No. What should happen then?

[poena]

"No" is good. I just wanted to make sure that changing the trac status does not cause problems.

Because currently the statuses are not synced. A theme ticket can have the live status on trac, while being suspended in the admin area and this is confusing.

[tellyworth]

In 10240:

Theme directory: add a Delist status.

This temporarily hides a theme from search, while still making it available directly.

More testing and refinement is probably needed.

See #5362.

[acosmin]

@tellyworth @dd32 thank you!

[acosmin]

@tellyworth would this affect the trac in any way? :) I'm asking because themes.trac is creating new tickets for themes that are already in review and because it started right about the time when this patch was applied.

​https://themes.trac.wordpress.org/report/2
The last 5 tickets except Travel Ace. For example Simple News is duplicated...

[tellyworth]

Replying to acosmin:

@tellyworth would this affect the trac in any way?

I don't think so but I'm looking into it.

[tellyworth]

In 10243:

Theme directory: revert r10240 to test for trac issues.

This might have been related to ticket creation issues, reverting will help confirm.

See #5362

[acosmin]

@tellyworth The Trac didn't create new tickets for these themes (both uploaded a few hours after the revert):
​https://themes.trac.wordpress.org/ticket/87927#comment:6
​https://themes.trac.wordpress.org/ticket/87509#comment:11

If that helps :)

[acosmin]

@tellyworth The issue seems to have stopped :) It's either a big coincidence or something went wrong with the patch applied.

[acosmin]

@tellyworth could we apply the patch again and see if it happens again :) thank you!

[acosmin]

@tellyworth @dd32 any news on this? :)

[acosmin]

@tellyworth @dd32 could we please try adding this back again :)

[jonoaldersonwp]

Sorry for arriving late to this conversation, but, I'd like to add another consideration.

Currently, when themes are suspended, requests to their URLs return a 404 error.
In many cases, these URLs are still linked to (within the wp.org ecosystem, in search engines, and on/from the wider web), and are still relatively heavily trafficked.

Quantitively, Google Analytics shows ~10k unique pageviews in the last month for 'hidden' themes, of which ~40% are entrances to the wp.org, of which ~50% immediately bounce from the site.

This is obviously pretty bad for user experience, SEO, branding, our general collective success, etc. In attempting to regulate and manage misbehaving themes, we're harming our audience.

Some suggestions on how we might manage this:

• For themes which have been intentionally and permanently removed, return a "This theme has been permanently removed" template, with a 410 HTTP status.
• For themes which are temporarily suspended/delisted, return a "This theme is temporarily unavailable" template, with a 200 HTTP status. The page should also contain basic/minimal information about the theme (the name, the image, and links to support/reviews etc).

[acosmin]

@dd32 "monthly" reminder :) that this is really important

[dd32]

In 10635:

Theme Directory: add a Delist status.

This temporarily hides a theme from search, while still making it available directly.

More testing and refinement is probably needed.

Reverts [10243] which reverted [10240].
See #5362.

[dd32]

In 10642:

Theme Directory: Fix the query logic for the delisted post_status.

This query modification function was overwriting the post_status specified by WPORG_Themes_Upload::get_theme_post().

See #5362.

[dd32]

Marking as fixed, no issues have been reported since the above fixes.

Re-open if it's not working as expected, or file a new bug if it's just a bug in the feature.

[dd32]

In 11227:

Theme Directory: Delisted themes are excluded from searches, don't override it by specifically requesting delisted themes in the query.

See #5362.