WordPress.org

Making WordPress.org

Opened 21 months ago

Last modified 2 months ago

#5093 reviewing defect

Proposal to allow users to remove URLs that they have added to their posts in the support forums

Reported by: carike Owned by: SergeyBiryukov
Milestone: Priority: high
Component: Support Forums Keywords: has-patch
Cc:

Description

The Problem:

  • Many users are asking that their posts be deleted or edited to remove URLs, which they included in their posts in order to get support.
  • We do not want users to be afraid to ask for help when they need it. Fear is not conducive to creating a positive learning environment.
  • Having these conversations take time and is taxing on moderators, as it can take a while to explain to a user why their URL cannot be removed. The outcome can often leave both the poster and the moderator dissatisfied.

The Constraints:

  • Removing posts / threads may hinder other users who are looking for answers to a similar problem.
  • Removing URLs currently require manual moderator intervention (time).

The Proposed Solution:

  • After the hour window to edit their own post has expired, offer the user a button that can remove URLs from their post instead of the box with their post contents.
  • This can be done by searching the post for http:// or https:// (these already turn into blue hyperlinks automatically upon posting) or www. and replacing them with:

"[URL redacted by poster]".

We could include a sentence about the tool being in beta, in the hopes that it will be useful to users, next to the button / on hover.
We could also specify that it will only work for links starting with http://, https:// or www. and that other links cannot be removed by the tool.

Attachments (6)

5093.patch (3.1 KB) - added by Clorith 10 months ago.
current.png (46.4 KB) - added by Clorith 10 months ago.
The current view when users post links to the topic starters site
new-others.png (47.1 KB) - added by Clorith 10 months ago.
The display to regular users after applying patch
new-topic-creator.png (51.1 KB) - added by Clorith 10 months ago.
The view for the topic creator after applying patch
new-reply-author-or-moderator.png (51.3 KB) - added by Clorith 10 months ago.
The view for the reply author or moderators after applying patch
50932.patch (2.9 KB) - added by vladytimy 7 months ago.
Minor non-functional changes

Download all attachments as: .zip

Change History (48)

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


21 months ago

#2 @sterndata
21 months ago

Which URL? The "page I need help with", or fragments of URLs in pasted debug logs, clarifications in replies? If there are multiple URLs in a post, which get removed?

As to only URLs beginning with http or https: This will lead to complaints that "I posted my URL and you removed X of them but not Y" and then we're right back to the moderators.

This is a can of worms and should probably be left alone.

#3 @carike
21 months ago

Which URL? The "page I need help with", or fragments of URLs in pasted debug logs, clarifications in replies? If there are multiple URLs in a post, which get removed?

"The page I need help with" link is only visible to signed-in users.
Giving the ability for that URL to be removed would be preferable as well, but it is generally less of a pain-point for users.

If there are multiple URLs in a post, they should all get removed.
The search would be for any instance of a recognized link.

As to only URLs beginning with http or https: This will lead to complaints that "I posted my URL and you removed X of them but not Y" and then we're right back to the moderators.

Just because we can't solve 100% of a problem (with one step in the first solution), doesn't mean we shouldn't take action to reduce it where we can.
In my experience, people tend to respond well to sincerity. While, yes, frustrated users may still be angry, I believe that a significant number of users will be appreciative of the good-faith effort.

Last edited 21 months ago by carike (previous) (diff)

#4 @sterndata
21 months ago

If there are multiple URLs in a post, they should all get removed. <

Excluding links to wordpress.org, stackexchange.com, etc. ?

My preferred solution is to no-index all topics when the first post is over X days old, where X is probably around 180.

If I quote a URL from the OP in one of my replies, is that edited too?

#5 @carike
21 months ago

Excluding links to wordpress.org, stackexchange.com, etc. ?

While some answers to questions in the support forums contain links to wordpress.org, stackexchange.com and the like on a relatively regular basis, I have only seen it in an OP's post on rare occasions.
I believe that, on a balance of probabilities, the benefit should go to the OP requesting the removal of the link in this case.

My preferred solution is to no-index all topics when the first post is over X days old, where X is probably around 180.

I can't say I disagree with no-indexing topics older than 6 months (for more reasons than just this one - consolidating / reducing content is actually likely to lead to a better user experience by means of facilitating more efficient search in this case), but this is not a sentiment shared by a number of forum volunteers and I'd like to acknowledge that.
However, I do not think that no-indexing alone is a sufficient solution to this particular problem.

If I quote a URL from the OP in one of my replies, is that edited too?

I thought about that, based on a recent incident.
I don't think it should be included in this proposal.
Personally I have been using

https://example.com/wp-admin/ (replace "example" with your own domain name)

in my replies to forum users.
While I do not think this practice must be required, I think it should be highly encouraged.
Again, there will be one or two edge cases that won't be covered, but our aim here is to reduce the issue as much as possible, not to chase perfection we can never achieve within the constraints.

#6 follow-up: @jonoaldersonwp
21 months ago

Not keen on blunt date-based dexindexing. Some older posts are useful and should be discoverable (often the crux of the "we should never delete anything" argument, even when posts are patently not useful), and noindex'ing has broader strategic and SEO implications.

If older posts aren't useful, we should be deleting/consolidating/merging them, not noindex'ing them but leaving them to haunt the server until the end of time for no reason.

#7 in reply to: ↑ 6 @Howdy_McGee
21 months ago

Replying to jonoaldersonwp:

Not keen on blunt date-based dexindexing. Some older posts are useful and should be discoverable (often the crux of the "we should never delete anything" argument, even when posts are patently not useful)...

I'm also not a fan of deindexing older threads.

If I quote a URL from the OP in one of my replies, is that edited too?

This will more than likely be a pain point eventually, if it's not already one now.

I don't think we should do too much to the URLs in the question itself. The only link that the user should be able to remove once the edit limit has expired should probably be the "Link to the page you need help with" box.

#8 @carike
21 months ago

I don't think we should do too much to the URLs in the question itself. The only link that the user should be able to remove once the edit limit has expired should probably be the "Link to the page you need help with" box.

The problem is that many users do not use the "Link to the page you need help with" box initially or that they provide additional URLs in their follow-up posts.

The "Link to the page you need help with" box also requires that a user be signed in to see it, which means it is not accessible to search engines.

Last edited 21 months ago by carike (previous) (diff)

#9 in reply to: ↑ description @Otto42
21 months ago

Replying to carike:

The Problem:

  • Many users are asking that their posts be deleted or edited to remove URLs, which they included in their posts in order to get support.

Why are they asking for this, exactly?

Solutions to problems require understanding the problem, not simply providing the requested solution.

#10 @sukafia
21 months ago

It seems some users don't want their client finding out they sought help to resolve an issue or build a site they were paid. This isn't really a privacy issue, it's more of some people trying to form "know all" after having got help to resolve a particular issue or achieve a feature.

There are pros and cons to this suggestion. I support this feature only because I've witnessed mods make a big deal out of removing URL for a user, in a situation I felt wasn't necessary.

I also fear this feature could be abused.

If it's possible to have guidelines under which mods can remove URLs from posts for a user, I'll certainly opt for that.

#11 @carike
21 months ago

"Because that is what users want" isn't a bad reason.

People's expectations around privacy / choice are changing.
YouTube's new Terms of Service allow users to delete their comments at any time. They previously had a perpetual license and there was no functionality for the user to remove comments.
(I may add that in some jurisdictions consumer protection legislation prohibits contracts in perpetuity and restricts long term contracts to those that can show a demonstrable benefit to the user of the service.)
LinkedIn have also increased their privacy options to give people more choices when it comes to what data is shown publicly - and the changes are retro-active.

In a democracy, the power is given to the people.
This isn't just supposed to be tokenism, it is supposed to be real and meaningful public participation, based on consultation.

We should not micro-manage them, or seek to subject them to quasi-judicial approval.
Democratizing publishing means listening to the needs of users and empowering them in a meaningful way to make informed choices.

This ticket was mentioned in Slack in #forums by howdy_mcgee. View the logs.


21 months ago

#13 @bcworkz
21 months ago

Removing links could still "hinder other users who are looking for answers to a similar problem." It also could remove important context that hinders followup replies after some time that other users might want to add due to recent developments like patches, new features, etc.

I would support hiding all links from non-logged in users, similar to the page I need help with box. Doing so alleviates the need for the box in some respects, but leaving it still has some benefits like encouraging people to leave a link in the first place.

It's my perception that most removal requests are for links in topic content and not necessarily for the page I need help with box, so hiding all links could alleviate most user's objections to leaving links in place for all time.

#14 @carike
21 months ago

Removing links could still "hinder other users who are looking for answers to a similar problem."

The OP is under no obligation to keep those links up.
They can easily turn into 404 errors (and some who have asked for the removal of links have turned into 404 errors because the link was to a test. subdomain).
The issue is that for whatever their private reasons, these users do not want their username associated with a particular domain.

Our interest should be in preserving the links with the ANSWERS, not the links that caused the questions.

#15 @Clorith
21 months ago

So my extended worries are that by providing a tool here, we are legitimizing the request to have URLs removed, this will lead to _more_ of them, not less.

Oh, you offer a tool to remove my URL, but it didn't remove _all_ versions of it, fix it, we've now made it clear we will fix it, and therefore have to honor this and do the extra labor our selves.

The nature of links is that they are on the internet, they are discoverable in one way or another, so why go to all the extra work of trying to hide them?

This is as much a matter of convenience and staffing, and isn't really a legitimate huge concern in my opinion, we get far less requests to remove links than you would think.

We've introduced a field for users to post into if they wish to do so (I've seen your related topic), if they choose not to use that field, this is on them, and not us.

I'm all for looking at new alternatives, but to me, this is most definitely a detrimental approach that will lead to an unacceptable burden on our volunteer moderation crew, and that's just speaking from the international forum which has very active mods, now imagine the outcries on a rosetta site which only gets moderated once a week for example, any change we make has far reaching impacts on the other parts of our community, and this would not be a good one in my opinion.

#16 @jonoaldersonwp
21 months ago

Our volunteers and moderators aren't our target audience. The forums aren't "for" them. They're for the end users, and people who post messages. If we're providing a bad experience to end users (which is demonstrably true at the moment), then we need to solve for that first and foremost.

If solving that impacts the resources/processes of our volunteers, then we need to change those resources/processes. We can't just immediately shut down any discussion of improvements which impact/alter our resourcing (volunteers/moderators or otherwise/beyond) as a dead-end, unless we've actively decided that WordPress' reputation and market share doesn't matter to (all of) us - which as far as I know, isn't the case. Instead, we need to find a way in which the needs can be met, within the constraints (or, to alter the constraints).

Furthermore, a partial fix is better than no fix at all. Maintaining the status quo isn't an option when it's harming users.

So... Let's try to be a bit more open and productive around how we explore this, maybe? If volunteer resourcing is the issue, then let's not conflate that with the utility or viability of the proposal, and let's work collaboratively to find a compromise. I think that, perhaps, we're all over-reacting on the amount of additional resource required to police this. We already police it, and, it's evidently a drain.

What if we just gave the moderators the tool to remove the link, as a test? Then nobody's doing any more / different work than at present, but we create some more happy, positive interactions, rather than making enemies of the community? If nobody dies, then we circle back around, regroup with some learnings and insight, and discuss next steps.

Last edited 21 months ago by jonoaldersonwp (previous) (diff)

This ticket was mentioned in Slack in #core-privacy by carike. View the logs.


21 months ago

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


16 months ago

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


12 months ago

@Clorith
10 months ago

@Clorith
10 months ago

The current view when users post links to the topic starters site

@Clorith
10 months ago

The display to regular users after applying patch

@Clorith
10 months ago

The view for the topic creator after applying patch

@Clorith
10 months ago

The view for the reply author or moderators after applying patch

#20 @Clorith
10 months ago

Firstly, I wasn't meaning to dismiss the ticket, I was merely pointing out that the proposal as it stood would add workload to an already small team.

Any way, 5093.patch is my take on solving the underlying issue of links only being private so long as they remain in that field the topic creator added.

This will filter out the link and make it a code-wrapped example.com link if the one viewing the reply is not logged in, or if they are any random user on WordPress.org
It will show the link it self to the author of the post, any moderators, and the original topic author. The reasoning behind this approach here is the user experience, if the user is looking at the wrong page on their site, needs to be directed to a wp-admin settings page etc, you can drop the direct link directly into the reply.

Most of the requests to remove a link I've seen recently have been because others have posted the link in their replies, this would solve that, but keep the user in mind. And honestly there's no value in various links to another users site to that extent, the original issue link is still retained in the original topic post.

If the links have not been modified, a message letting the user know why is appended to the end of the topic. This will hopefully bring ease of mind to the user, in knowing only they see their website link.

#21 @Clorith
10 months ago

  • Keywords has-patch added; needs-privacy-review removed

Adding the has-patch keyword, I believe this is a good starting point, let's see where that takes us :)

This ticket was mentioned in Slack in #forums by clorith. View the logs.


10 months ago

#23 @carike
10 months ago

I can support a solution where the link is only visible to the reply author, the OP and moderators.

Just to be clear, this applies from the initial posting?
It does not require moderator action, or self-service from the OP?

Would it be possible to deal with the related concern / ticket in this same patch?
I.e. can we just make all links in the *original* post (not replies) only visible to logged in users?
That should take care of situations where new people don't use the correct field, or use it in the post body in addition to the "page I need help with" field.
It would also have the benefit of being a disincentive for spam.

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


9 months ago

#25 @psmits1567
9 months ago

I think it is important that we follow GDPR rules,and the proposal from Carice is one step forwards to the goal "Meet GDPR" regulations.

This ticket was mentioned in Slack in #forums by vladytimy. View the logs.


9 months ago

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


9 months ago

#28 @tellyworth
9 months ago

  • Priority changed from normal to high

#29 @tellyworth
9 months ago

To the best of our knowledge, WordPress.org already meets its GDPR obligations (see https://wordpress.org/about/privacy/ for details). Which is not to say this ticket is unnecessary - I think it's a good idea.

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


9 months ago

This ticket was mentioned in Slack in #forums by vladytimy. View the logs.


7 months ago

#32 @robscott
7 months ago

I think this proposal is a good idea.

At the same time, we should look at this:

https://wordpress.org/support/forum-user-guide/faq/#my-post-shows-up-on-a-search-for-my-domain-will-you-delete-my-post-or-my-link

Let's consider the two issues here as @Otto42 asked for the use-case (the why):

1) The use case - someone has posted a link to their (or their client's) website; that link, when you search for the domain on Google now shows up, pointing to this issue in WP forum, about some problem they have. This is embarrassing.

2) The wording in the above post is not neutral. It describes Google spidering and indexing content as "scraped". It also concludes with "Keep in mind, even if your post is deleted, Google already scraped it and we can’t fix that. Don’t post anything you’re not willing to have in public forever."

Someone came here with a problem - seeking support - and perhaps this was their first time in the community. Perhaps they didn't know this support forum would rank in Google searches. This came up, and it was embarrassing for them for their problem to show up in Google. When they felt embarrassed, that person sought help, and was directed to the above message.

This is a very hostile experience. It's not a good introduction to our community at all.

In many cases, the URL is not really particularly relevant to the support ticket.

Keeping the support thread is the best solution - with the URL redacted, and therefore the ticket doesn't show up in Google under searches for this domain, next time Google indexes the ticket, which, by the way, can be very fast (contrary to the message in the forum user guide - sitemap.xml ftw).

Everyone wins - and less for moderators to do, because user can fix their own problem.

Last edited 7 months ago by robscott (previous) (diff)

#33 @bedas
7 months ago

Would like to add a word here on a few details.

A) I think it is not up to GDPR, lawyers or anyone else to determine what is the persons "private" stuff. I tend to agree even with the statement that the URL to the website may be considered "private", what is however most important is to remember that the content written by any user is not our property, it is the property of the user who wrote it (again, this may differ in law enforcements however this is my opinion).

Just like comments, a user should have the right to remove everything they wrote from online instances, by default, as a basic right. This includes, but is not limited to, links.

WordPress is a leading CMS and setting a standard that may go above what GDPR asks us to do can have a positive impact.
Even "evil" Facebook allows to delete your content and removes content (mostly) once you delete either said content or your account, which does not seem to happen in WordPress (please correct me if I am wrong on this).

Understandably this is a help forum, and removing content would kind of dispose of the goal (to keep a log for other users to find the same solution), however, with the modern times, users do not research, they ask anew. So the "loss of information" - even if deleting a full topic - is actually not that big and the impact is probably close to zero.

Users ask again, even if they found a solution, often they ask the same question again "just to be sure".
That said, this is perhaps off topic but I believe that the "threads are not deleted even if you request us to" approach may not be the most respectful way to deal with data that, bottom line, is neither ours nor WordPress's property.

B) I have worked for years in a (PRO/PAID WordPress Plugin) company providing Support for WordPress users, and the way this issue was dealt with there, was as follows:

  • if a user request deletion of their thread, we complied with it. No Questions Asked.
  • a custom code logic applied to the threads masked all URLs by default and made them visible only to Moderators and OP. Only if a specific "prefix" (in our case an @) was added to the URL, then the URL was public.
  • the masking logic automatically excluded major domains like Stack Overflow, Google, WordPress, etc from the masking process.
  • this masking process of course applied to everything what had the syntax anything.anything. Similarly to WhatsApp when you type anything.anything and that gets converted to an URL, this sometimes resulted in funny issues due to typos (when a user mistakenly forgot the space after a dot). These issues however are minimal, and can be resolved by Mods quickly.
  • last but not least the user in the forums was able to edit their posts until marked as resolved. After that, the users where welcome to contact us for further edit or removal.

This effectively ensured that no "private" url got public by accident, it allowed to make specific URLs publicly readable if needed, and as well automatically ensured that most of the common external sites (as said, like SO, WP, etc) where public so other readers could follow the links to potential solutions.
If it helps, I am sure said Company will be more than willing to share their code solution with WordPress or even commit directly, as they are directly involved and contributing to the platform almost daily. I can, if this is desired or/and welcome, reach out and ask for inputs.

Concluding, I believe it is utmost important to respect the peoples content, and to understand that their written content, wether an ask for help or else, in no way ever changes property. It is and stays the OPs property, I believe, and the OP should free to do with that content what they consider best.

Implementing such solution as above described would not add work to Moderators, rather, it would probably save a lot of time.
Of course the difference between "paid" and "volunteer" forums is, that here we couldn't "employ" someone responding to needs of peoples on demand. But I think the approach with the prefixing already would solve 99% of the "please remove URL" issues, and the option to delete even after OP marked a topic as resolved, could simply be ignored in the WP case. After all, no one but the OP can mark as resolved, so perhaps just adding a last notice there, saying "If you mark as resolved, you won't be able to remove Urls or else edit the postings" would complete the resolution.

Finally, posting an URL that the OP shared in our reply to the OP is (IMO) a plain simple no-go. We should always anonymise and never directly copy paste the OP's URLs.
That is simply good practice I believe.
Public Urls can in fact be a minor security issue. What if I mistakenly post my customised login URL? While security thru obscurity is not a solution, it is part of a solution (because since the WP login Urls are widely known, renaming them can have a huge impact on brute force bots, because they would not know my customised login url).
Publicly sharing these customised login urls would effectively "destroy" this (tiny) measure.

Mainly thou I think it is just a form of respect to not copy-paste in replies the URL shared by Users. Especially, if that URL was part of the "I need help with" field.

I hope this helps and sorry the long-ish post, and of course, this is mostly based on my opinion and experience. Not trying to force it on anyone ;)

Last edited 7 months ago by bedas (previous) (diff)

@vladytimy
7 months ago

Minor non-functional changes

#34 @vladytimy
7 months ago

Just tested 5093.patch and it works like a charm. Love it!
There are a few minor (non-functional) things I propose we change in 50932.patch (:facepalm: for not including a dot before 2)

  1. Use reply instead of post (except when it actually reffers to the post)
  1. A comprehensive function description - for our future selves :laughing:

Before: Filter away the site URL from a post, UNLESS it is the topic starter them selves.
After: Filter away SITE_URL_META from a reply, UNLESS current user is the topic starter themselves, a moderator or the author of the reply.

  1. Fix minor typos ( ot -> to, examplify -> exemplify, them selves -> themselves, starters page -> starter\'s page)
  1. Use the same comments wording used before for similar functions

Before: Let the reply author ... see ...
After: Do not filter ... for ...

  1. Use the same wording already used for site_url_description when creating a new topic

Before: These links are only viewable to...
After: These links will only be shown to...

  1. Remove maybe redundant commas in contains one, or more, links -> contains one or more links (this needs a native speaker confirmation, as it is based on online research only)

That said, the proposed full outputs are:

This reply contains one or more links to the page you need help with. These links will only be shown to you and the author of this reply.

AND

This reply contains one or more links to the thread starter's page. These links will only be shown to you and the person who created this thread.

Last edited 7 months ago by vladytimy (previous) (diff)

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


7 months ago

#36 @SergeyBiryukov
7 months ago

  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

#37 @Ipstenu
2 months ago

Related to this is #5916

Since we need people to know 'this won't delete your URLs in posts, yo!' we should have this finished as well so we're giving them the power to remove themselves.

#38 @dd32
2 months ago

Thinking out loud, 50932.patch could potentially be altered so that..

  • Links are visible by all logged in users
  • Links are 'anonymised'/hidden to logged out users

That would mean all support volunteers, whether moderator or not, would be free to discuss / view links, and we'd avoid the whole "Oh nooo my thread is showing in googlleeee".

#39 @Clorith
2 months ago

Do you mean any link will always be "anonymized" to logged out users, or just the link marked as the one a user mentioned needing help with?

I wouldn't be opposed to that, just blanket fix it across the board, but it would be hard to capture all variations in which a link could be shared, without a fixed point of reference which the "Page I need help with" currently provides.

#40 follow-up: @jonoaldersonwp
2 months ago

A related thought...

A frequent objection to us retiring stale/outdated/thin support content is that there's perceived value in enabling users to search for and find existing/legacy threads that contain solutions for their problems.

How do we reconcile 'disabling' potentially useful and relevant links with this? There's a reasonable chance that this change would significantly devalue these pages as 'resources' that help to solve the problems of other/future users.

Either we need to maintain the utility of existing posts for 'resource building' reasons (in which case, we can't hide the links without undermining that), or, we need to revisit and adjust our stance on never being able to delete or clean up thin/legacy support content.

#41 in reply to: ↑ 40 @dd32
2 months ago

Replying to Clorith:

Do you mean any link will always be "anonymized" to logged out users, or just the link marked as the one a user mentioned needing help with?

Replying to jonoaldersonwp:

How do we reconcile 'disabling' potentially useful and relevant links with this? There's a reasonable chance that this change would significantly devalue these pages as 'resources' that help to solve the problems of other/future users.

Thank you both, yeah, I had thought that.. but you're right - this is a case where it's not as straight forward, my suggestion would ease the support burden upon us, but remove useful content for others.

How about..

  • Anonymise all instances of the domain in the 'link I need help with' field
  • Fill that field in automatically with the first link posted by the OP if they don't specify it? Just on the new post screen (or when replying)

I'm thinking that upon clicking submit, if the field isn't set, throwing a red alert around the box with a "Hey! You've mentioned a URL in your post but not filled in this field. If you'd like to keep your website private and not post it publicly, entering it in here will show it to logged in users and support volunteers, but hide it to search engines."

#42 @bedas
2 months ago

I think this would defy the purpose of the ticket.

The issue is, users post links to their websites inside the support topic. Then, later they realise that google will show those support topics when they google for their website name.

Then they will go to #forums and request the topics to be deleted or at least the urls to be removed.

The field where users can add the private (visible for logged in users only) website, is I hope, already not part of the google index.
So just anonymising that wouldn't really help anything here.

Letting a user remove an URL mistakenly or purposely posted in a topic will not break usefulness of said topics. In most cases, like 99% of all cases, there is nothing useful anyway to see on those links in relation with the support topic.
It is mostly "I need help with issue X - this is my website"
It almost never is "I have the very precise example here on this page and that is not working"
Even so, once they fix the issue, the issue wouldn't be visible anymore on their website, so theres' no value in visiting said website neither to see the issue as a reference to the topic.

In fact, if the topic posts do not explain the issue well enough without the need to go to a website to see it, then there is little use in that topic anyway.

Not to forget is also - many many users do not even bother reading existing topics. Too many times a topic is opened where a simple google search will immediately return the answer, from the same forum as they posted in. Thus, I wouldn't fear the existing topics to lose value if we remove a couple links inside those topics.

I am in favour of letting the users delete ALL their links in ALL their posts no matter what, if they want so.
These urls are usually of no value anyway, to the topic itself that is.
In fact I would even go a step further and let the users delete their topics, because after all, it is not _our_ content. But that is another discussion.

Last edited 2 months ago by bedas (previous) (diff)
Note: See TracTickets for help on using tickets.