Clearer thread URLs and email notifications

[galbaras]

Clearer URLs

Support thread URLs do not contain the slug of the forum (e.g. plugin name) they apply to. This makes them less useful when trying to recall the issue involved, particularly after a pause in the discussion, and prevents the successful use of site: type Google searches.

Example: ​https://wordpress.org/support/topic/cant-save-settings-56/

Please consider replacing topic with the forum slug in support thread URLs.

Example: ​https://wordpress.org/support/youtube-embed-plus/cant-save-settings-56/

Alternative: Example: ​https://wordpress.org/support/plugin/youtube-embed-plus/cant-save-settings-56/

As a matter of fact, both of these already redirect successfully to the official URL. Why not have a more meaningful/useful official URL, or, at the very least, use it in email messages?

Email Notifications

Email notifications about thread updates also show no indication if the forum they're in. Again, this makes recall difficult sometimes.

Example: [WordPress.org Forums] Can't Save Settings

Forum notifications are sent from WordPress.org Forums <noreply@wordpress.org>, so the string prefix [WordPress.org Forums] in the subject is redundant, and can be removed to make room for a forum identifier.

Using the forum name (e.g. Plugin: Embed Plus Plugin for YouTube, with YouTube Gallery, Channel, Playlist, Live Stream, Facade) may be too long, but slugs are normally OK, so a capitalized version of the forum slug would be better (e.g. Plugin: Youtube Embed Plus) for the email subject.

Example: [Plugin: Youtube Embed Plus] Can't Save Settings

The full name of the forum can then be added for reference in the body of the email.

Example: Plugin: Embed Plus Plugin for YouTube, with YouTube Gallery, Channel, Playlist, Live Stream, Facade

[Otto42]

All plugin topics exist in the same forum. They're not separate in any meaningful way.

There is one "plugins" forum. Not 60,000 of them.

[galbaras]

@Otto42 you may be correct, strictly speaking, but I'm sure there's some way to accomplish what I'm asking regardless.

It's only software, after all, and we do software.

[Otto42]

Yes, of course, however, I'm trying to explain that changing the URLs as you suggest is completely pointless. It doesn't separate anything from anything else. The slugs are the separation between topics, there is no point in adjusting the URLs for vanity reasons.

There is no reason to do what you're asking here as it does not solve any actual problems for us. The email issues, okay, but the slugs and URL paths? No.

[galbaras]

Who is "us"?

As for "actual problems", I've tried to find threads in the past using search, and using plugin names as text brings up mentions in support threads of other plugins (or other forum areas), and the URL obscures this fact.

Maybe I'm confusing the logical definition of "forum" with the specific way that's implemented on wp.org. Is there a different term for the subdivision that handles a particular plugin? I know for a fact that this thing, whatever it's called, has its own URL.

Example: ​https://wordpress.org/support/plugin/youtube-embed-plus/ <-- What is this called?

[dd32]

Whether or not they're "true" individual forums is irrelevant here. Let's not argue data-store semantics.

Support thread URLs do not contain the slug of the forum (e.g. plugin name) they apply to. This makes them less useful when trying to recall the issue involved

There are some limitations here due to bbPress and how we've implemented the individual plugin forums, but this is a worthwhile suggestion that we could definitely look into.

It would also make it clearer as to what forum a thread is in for the other forums, ie. fixing-wordpress/404-page-23 or alpha-beta/404-page-22.

The major limitation here is that we've got literally hundreds of thousands of threads, and changing the URL to each and every one of them has some serious SEO implications.

As a matter of fact, both of these already redirect successfully to the official URL. Why not have a more meaningful/useful official URL, or, at the very least, use it in email messages?

The URLs aren't supposed to work, technically, but what's happening is the 404 handler is being triggered to detect the likely non-typo'd page you wanted - and it'll be correct most of the time.

So using them just within emails wouldn't be exactly be ideal, but we could look at potentially changing it for threads going forward or something..

Email notifications about thread updates also show no indication if the forum they're in. Again, this makes recall difficult sometimes.

#2016 handled that at one quite some time ago..

The emails appear to be in the format of.. [WordPress.org Forums] [Plugin Name] Thread Title here for most emails though, but you're right, the prefix is redundant. Removing it might break some email filters though.

Are you still getting emails that don't have the plugin included in the title? Can you provide me an example? (You can forward it to me - you should have one of my emails) It might be that it's not applying the prefix in some edge-case.

Using the forum name (e.g. Plugin: Embed Plus Plugin for YouTube, with YouTube Gallery, Channel, Playlist, Live Stream, Facade) may be too long, but slugs are normally OK

Ugh, plugins that are doing that need to get a ban-hammer thrown on them :) Use your plugin name, and stop trying to game the search indexes.. That's a whole other topic, and one that is ongoing.

[galbaras]

Thank you for this explanation and for the support.

Alas, I know nothing about bbPress, but I do know software, and if it's anything like WordPress, there should be some hooks that can be used or functions that can be overridden.

Looking back to 17/03/2017, there's no a single email from "WordPress.org Forums" with the plugin name in the subject.

[dd32]

Replying to galbaras:

Looking back to 17/03/2017, there's no a single email from "WordPress.org Forums" with the plugin name in the subject.

Looking through my history of emails from the Forums, it looks like you're right..

Email notifications about thread updates

Thread updates don't appear to include the plugin/theme name, that is, replies to a thread you're subscribed to.

Plugin Subscriptions (ie. new threads) DO include it, but that's not what this ticket is about :)

I don't interact often with plugin support threads, and there's rarely any responses after I reply when I do, so I'd not noticed the lack of the plugin in the title.

Thanks @galbaras!

[galbaras]

I don't interact often with plugin support threads, and there's rarely any responses after I reply when I do, so I'd not noticed the lack of the plugin in the title.

That's because you're so awesome, man. I've had that experience of getting a reply from you, with the only response possible being "Oh, great. Thank you, Dion" :)

[dd32]

In 11528:

Support Forums: Emails: Prefix the plugin/theme name to the email subject for reply notifications to a topic.

Previously this was only applying to notifications of new topics / new replies to topics in subscribed terms, rather than also applying to replies to threads you participated in.

See #6079, #2016.

This removes [WordPress.org Forums] prefix from bbPress subscription notifications, and prefix the forum instead.

This results in two different style emails:

From: "WordPress.org Forums" <noreply@wordpress.org>
Subject: [Plugin Name] Help! My Topic Title!

or

From: "WordPress.org Forums" <noreply@wordpress.org>
Subject: [Fixing WordPress] How do I make WordPress write posts for me instead?

This is based on https://meta.trac.wordpress.org/ticket/6079

This might result in some email filters breaking, if they're expecting the WordPress.org Forums prefix, but the user-experience is sub-par at present as it results in longer email subjects, and duplicates the sender name on the emails.

This is potentially something that should be upstreamed to bbPress instead..

I've upstreamed this to bbPress: ​https://bbpress.trac.wordpress.org/ticket/3446

Some changes would still be needed on WordPress.org, to replace the forum name with the Term subscribed to.

[galbaras]

Having received an email with the subject [WordPress.org Forums] [Slider, Gallery, and Carousel by MetaSlider - Responsive WordPress Plugin] Lighthouse errors, I think it might be good to either truncate plugin names OR (better, I think) just capitalise the respective slug.

Option 1 example: [WordPress.org Forums] [Slider, Gallery, an...] Lighthouse errors

Option 2 example: [WordPress.org Forums] [Ml Slider] Lighthouse errors

[dd32]

Replying to galbaras:

Having received an email with the subject [WordPress.org Forums] [Slider, Gallery, and Carousel by MetaSlider - Responsive WordPress Plugin] Lighthouse errors, I think it might be good to either truncate plugin names

Unfortunately I tend to agree, but that plugin name is a guideline violation on many fronts, something I'll be dealing with later today.

Truncating it seems like it's something we'll have to do regardless though.

OR (better, I think) just capitalise the respective slug.

This is an option we can't do for whole range of reasons, primarily that the slug is not representative of the plugin.

[johnjamesjacoby]

I've made improvements in bbPress based on feedback from @dd32 in this ticket.

bbPress 2.6.10 and higher will now use the [Forum Title] instead of the [Blog Name] as the subject prefix.

Thank you everyone for the ideas & feedback, and for helping make bbPress better! 🐝

[galbaras]

I can confirm receiving an email today with the subject "[WordPress.org Forums] [OMGF | Host Google Fonts Locally] OMGF encountered an error while downloading Google Fonts: rest_no_route - No rou"

Thank you for doing this!

Are you truncating the forum name at some point to keep the thread title visible?

[dd32]

Replying to galbaras:

I can confirm receiving an email today with the subject "[WordPress.org Forums] [OMGF | Host Google Fonts Locally] OMGF encountered an error while downloading Google Fonts: rest_no_route - No rou"

That looks like the old code sent that, not bbPress 2.6.10+ (which we're not yet running on w.org, we're using 2.7.0-alpha from 2021-11-29).

The truncation of the email subject was due to.. the support threads title being truncated.

Once the bbPress change flows through, the email subject should read:

[Plugins] [OMGF | Host Google Fonts Locally] OMGF encountered an error while downloading Google Fonts: rest_no_route - No rou

Plugins is the forum name, technically, all plugins are within a singular forum they're not separate forums, despite appearing as individual forums.

Once the code is deployed to WordPress.org, I'll continue with this ticket and I'll update the above email to read:

[OMGF | Host Google Fonts Locally] OMGF encountered an error while downloading Google Fonts: rest_no_route - No rou

Through #6106 & #6108 we'll make some headway into plugins that abuse the plugin name, such as the original mentioned Embed Plus Plugin for YouTube, with YouTube Gallery, Channel, Playlist, Live Stream, Facade which should really be just Embed Plus Plugin for YouTube (per it's plugin headers displayed within WordPress)

[dd32]

In 11653:

Support Forums: Prefix the plugi/themen name only to email notifications, do not include the Forum name or Forum Site name as a prefix.

eg. This changes it from [WordPress.org Forums] [Plugin Name] Thread title to just [Plugin Name] Thread title.

See #6079.

Merged in https://meta.trac.wordpress.org/changeset/11653

[tellyworth]

Just noting for feedback that this has affected automated email filtering for some users. Especially those that use subject lines to route plugin support requests on the forum into a support ticket tool.

[johnjamesjacoby]

Replying to tellyworth:

Just noting for feedback that this has affected automated email filtering for some users. Especially those that use subject lines to route plugin support requests on the forum into a support ticket tool.

You know, I’d considered that, but didn’t think to question it since the blog name is represented in the sender. 😬

I checked the email RFCs and did not find a hard length limit on the subject header. If we want to limit it, we get to set our own patterns. Advice varies on the web in my research here, too. I would think first 3 or 4 words of [blog name] and 3 or 4 words of [forum title] would be adequate?

Should we revert and put the blog name back at the front so existing email filters keep working?

[galbaras]

@tellyworth Yeah, some people might have to re-jig their email rules, but they'll have the benefit of this change to enjoy, so should consider it a good tradeoff.

@johnjamesjacoby The RFC isn't the problem. It's how many characters email users can see in List View, and then in Message View. Since the most meaningful bits are at the end, we want to make them as visible as we can.

[dd32]

Should we revert and put the blog name back at the front so existing email filters keep working?

I don't think so.

Instead, I think we should consider adding one of the ​`List` headers to the emails to allow categorization of them that way, for future filters people create. This would be a WordPress.org-specific thing, as it would mostly apply to Plugin/Theme forums, not general bbPress emails.
Notably, we do include the List-Unsubscribe header for those on WordPress.org already.

Email subject-based filtering is always going to be a little problematic when things change, I had thought of this before making the change, but figured it would be worth it.

[Starbuck]

I created #6525 and #6526 because I didn't find this ticket on my research, but these are all related. The issues have been bothersome for years, and only now have I considered them frustrating enough to formalize requests. I'm glad this topic has some eyes on it and hope to see more.

I'm hoping we can reduce the definition of the problem down to a concise statement:
This site is curiously deficient in providing "context" in search results or emails. The overall request here is "do better, everywhere" about presenting meaningful information about context to a consumer.
Can we agree on that?

We get emails that have a user-crafted topic, perhaps "i-need-help-3433", but no information about what that topic is related to. (Screenshots of examples in other tickets.) It's not an unreasonable request to ask for more information that tells us what that email is about, so that we can decide if we want to look further.

Similarly, search results don't provide context - there is no data around that "I need Help" title that identifies the theme, plugin, or forum that contains the thread.

The remedy for the problems depends on the location, and perhaps personal preferences. I suggested in the other tickets that User Profile preferences might be used to allow each of us to toggle how we want these issues handled.

• URLs might be enhanced with context according, perhaps wordpress.org/support/topics/slug?plugin=this or ?theme=that or ?forum=the-name. Such a URL can be filtered in email as well as being an inelegant but effective solution for search results and other place where we see links.

• Search results might get a 'Label: plugin-slug' - or just show the context along with other data: Title, Excerpt, Plugin/Theme/Forum Name, and maybe a Date. I wouldn't understand any objection to this. That this data is missing seems to have been an early oversight that's easily corrected at any time now.

• As noted in this thread, the email subject line can be a problematic place for metadata like this.
  • I think the email subject line is used too often to provide too much detail, and agree that a list header or other X-header might be appropriate. These are universally recognized, can be used by everyone for filtering, and adding such a header doesn't break anything else.
  • Some might find it reasonable for all emails to have a fixed "Subject: WordPress.org Discussion", with the first line of the message being the context "Plugin : The Great Plugin" the second line "Topic : I need Help", and the content following. This is not inconsistent with contact form emails other system-generated notifications.

Any of these options or others can be implemented based on wp_usermeta.

Note that changes in email do not solve the problem in Search results or where a URL doesn't provide context. So I maintain these are different issues - and neither #6525 nor #6526 are dupes if that is the focus on this ticket.

In summary, I suggest that there is no "best" or "final" or "one size fits all" solution, but that any solution that shows recognition of the problems is a step in the right direction. If people want other options, they can be considered. But let's not dismiss the problems or not come to any resolution at all through discussion about "best" solutions.

[Starbuck]

I suggest a change to the ticket Type here. I don't believe this issue is a Defect.

More accurately, we've identified new challenges resulting from the existing processes here and we're looking for Enhancements to address these challenges: specifically that none of us have a clue what a topic is about until we visit the thread.

I cite this distinction because someone could legitimately flag this and other tickets as "won't fix", because the issue isn't a "bug". Compare to Enhancement requests for quality of life improvements

I can see someone arguing that this isn't a bug. But I find it difficult to understand how people can argue that it's not a problem that we are constantly presented with text that has no context.

[mrfoxtalbot]

I believe that the underlying goal of this ticket was to provide a way to filter notifications based on the forum they come from. Doing this by changing the permalink structure does not seem viable but adding the plugin/forum/theme name to the email subject seems to have provided a path forward.

I think we can close this and leave #6525 open in case we want to continue exploring the possibility of changing URL structure (even if it does not seems likely).

My only question is, should be close this as solved or as wontfix? What do you think @Otto42, @dd32?

[galbaras]

Since resolution may continue in #6525, why not use "maybelater"?

[Starbuck]

Example of email from Trac

[Starbuck]

In general, I don't think any ticket should be closed unless 1) The author says the issue is resolved, or 2) the author is not active and consensus is that the issue is resolved.

Therefore, for this ticket, unless solutions are actually proposed and implemented, and this ticket is processed as an intentional or accidental bonus, I don't think this ticket should be closed.

At the end of the day, as I've noted above, can we agree that "context" is the goal, and without obvious "yes, there is context in the result/notification" it seems none of these can be closed.

I'm getting a bit frustrated with this topic, though please don't take this as aggressively, I'm just conveying sentiment in a collaborative manner. At the time a search result or notification is generated, all of the context is available. So why is any of this such a big deal that takes 1-2 years for consideration and resolution?

Let's step away from changing URLs as a solution to the context problem and just focus on adding more context. What's wrong with adding in emails and search results a standard template that includes relevant names and links? The exact same code can be used for emails and search results. Example:

Plugin : [plugin name](url) {PluginID} or N/A
Theme : [theme name](url) {ThemeID} or N/A
Forum Section : [section name](url) or N/A
Thread : [thread name](url) or N/A

Just fill in all relevant detail that is available. This text-as-meta is easily searchable and filterable. The IDs are included in case a plugin name changes - we have the opportunity to use either as we wish.

As a great/existing example, look to the emails we get from Trac as a model:

In summary, just stepping back a moment - why is this concept such a big deal? Or are we hung up on the specific suggestions for implementation? :)

Thanks!

[galbaras]

This is a great new direction, and hopefully easier to implement.

Searches seemed to have changed to include intext:"Plugin: PLUGIN_NAME", and this narrows down the results to what they should be. As the author of this ticket, I'd say this bit is complete now.

This leaves possibly adding contextual information in the body of the message.