WordPress.org

Making WordPress.org

Opened 2 months ago

Last modified 11 days ago

#5362 assigned enhancement

Add delist option to theme directory

Reported by: dd32 Owned by: tellyworth
Milestone: Priority: low
Component: Theme Directory Keywords: needs-testing has-patch
Cc:

Description

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.

Attachments (4)

5362.diff (1.0 KB) - added by dingo_d 2 months ago.
Added patch for the new repopackage post status
5362-delist-actions.diff (7.7 KB) - added by tellyworth 7 weeks ago.
A lightly tested attempt
5362-delist-actions.2.diff (8.5 KB) - added by tellyworth 7 weeks ago.
Fixed the nosnippet issue; also found some other bugs. Thanks @dd32!
5362-delist-actions.3.diff (8.5 KB) - added by tellyworth 7 weeks ago.
Fix a bug in the .2 version where noindex could be overridden

Download all attachments as: .zip

Change History (38)

This ticket was mentioned in Slack in #themereview by bph. View the logs.


2 months ago

#2 follow-up: @carike
2 months ago

: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.

#3 @bph
2 months ago

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 in search result from the repo visible 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
Last edited 2 months ago by bph (previous) (diff)

#4 @dingo_d
2 months ago

@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
2 months ago

Added patch for the new repopackage post status

This ticket was mentioned in Slack in #meta by carike. View the logs.


2 months ago

#6 in reply to: ↑ 2 @carike
2 months ago

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.

#7 @ionutn
2 months ago

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.

#8 @carike
2 months ago

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.

#9 @acosmin
2 months ago

@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!

This ticket was mentioned in Slack in #themereview by ilovewpcom. View the logs.


2 months ago

This ticket was mentioned in Slack in #meta by carike. View the logs.


2 months ago

#12 @tellyworth
2 months ago

  • Owner set to tellyworth
  • Status changed from new to assigned

#13 @acosmin
8 weeks ago

@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
7 weeks ago

A lightly tested attempt

#14 @tellyworth
7 weeks ago

  • Keywords needs-testing added

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.

#15 @tellyworth
7 weeks ago

  • Keywords has-patch added

@tellyworth
7 weeks ago

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

@tellyworth
7 weeks ago

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

This ticket was mentioned in Slack in #themereview by acosmin. View the logs.


7 weeks ago

#17 follow-up: @poena
7 weeks ago

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.

#18 in reply to: ↑ 17 @tellyworth
7 weeks ago

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?

#19 @poena
7 weeks ago

"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.

#20 @tellyworth
7 weeks ago

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.

#21 @acosmin
7 weeks ago

@tellyworth @dd32 thank you!

#22 follow-up: @acosmin
6 weeks ago

@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...

#23 in reply to: ↑ 22 @tellyworth
6 weeks ago

Replying to acosmin:

@tellyworth would this affect the trac in any way?

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

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.


6 weeks ago

#25 @tellyworth
6 weeks ago

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

#26 @acosmin
6 weeks ago

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

This ticket was mentioned in Slack in #themereview by aristath. View the logs.


6 weeks ago

#28 @acosmin
6 weeks ago

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

#29 @acosmin
6 weeks ago

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

#30 @acosmin
6 weeks ago

@tellyworth @dd32 any news on this? :)

#31 @acosmin
5 weeks ago

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

This ticket was mentioned in Slack in #themereview by acosmin. View the logs.


3 weeks ago

#33 @jonoaldersonwp
3 weeks ago

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).

#34 @acosmin
11 days ago

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

Note: See TracTickets for help on using tickets.