Skip to content

Legacy twitter.com social links across ~183 project/chapter pages — proposing a coordinated convention before more one-off PRs land #402

Description

@huangsen365

Summary

Most OWASP project and chapter pages still link to twitter.com in their info.md sidebar. The links are not broken — twitter.com still issues a 301 to x.com — so this is a consistency and link-hygiene question rather than an outage.

I'm raising it here rather than opening PRs against individual repos, because the interesting finding is that partial migration has already started organically and has produced three incompatible conventions. A decision made centrally would be worth more than 183 independent judgement calls.

What the scan found

Searched via GitHub code search across org:OWASP (methodology note: code search indexes default branches only and truncates large result sets, so treat these as lower bounds).

Query Count
twitter.com anywhere in the org 554 hits across 274 repos
twitter.com in info.md 183 files
info.md already migrated to x.com 15 files
fa-twitter icon class 110 usages
fa-x-twitter icon class 0 usages

By repo family, the info.md occurrences break down as:

Family Count
www-chapter-* 144
www-project-* 38
www-committee-* 3
www-event-* 1
other 5

Beyond info.md, the same links appear in index.md (77), migrated_content.md (32), README.md (27), index.html (13), plus trainers.md, leaders.md and assorted tab_*.md files.

The actual problem: three conventions, one of them broken

Verified live against raw.githubusercontent.com today:

OWASP/www-project-juice-shop     [Twitter/X](https://x.com/owasp_juiceshop)
OWASP/www-chapter-denver         [Twitter / X](https://x.com/owasp303)
OWASP/www-chapter-quebec-city    [X](https://twitter.com/owaspquebec)     <-- label migrated, URL did not
OWASP/www-project-samm           [@owaspsamm](https://twitter.com/owaspsamm)
OWASP/www-project-dependency-track   [Twitter](https://twitter.com/dependencytrack)
OWASP/www-project-modsecurity    [Twitter](https://twitter.com/modsecurity)

So the site currently presents Twitter, Twitter/X, Twitter / X, X, and bare @handle as labels, across both domains. www-chapter-quebec-city is the clearest symptom: it reads X but still points at twitter.com.

Font Awesome

owasp.org currently loads Font Awesome Free 6.5.1. fa-x-twitter was added in 6.4.2, so the correct icon is already available in the bundle the site ships — but it is used zero times, while fa-twitter (the legacy bird) is used 110 times. Whatever is decided about link text, the icon can be updated without a Font Awesome upgrade.

Explicitly out of scope, in my view

A meaningful share of the 554 org-wide hits are citations of specific tweets inside _posts/ blog archives, cheat sheets and research reference lists — e.g. author credits like [Omer Gil](https://twitter.com/...). Those are historical record and rewriting them would edit the archive rather than fix a live link. Same for the handful of explicitly retired repos in the result set (www-chapter-vienna-old, www-OLD-chapter-..., etc.).

The defensible scope is live social links on active pages — principally info.md and index.md.

Questions for the web team

  1. Do you want this migration done at all? "Leave it, the redirect works" is a perfectly reasonable answer and would save everyone effort — but if so, it'd be worth saying so somewhere, because one-off PRs are already trickling in.
  2. If yes, what's the canonical label — X, Twitter/X, or X (formerly Twitter)?
  3. Should fa-twitter become fa-x-twitter in the same pass?
  4. Is a bulk change across ~183 repos something you'd want handled centrally, or do chapter/project leaders own their own info.md and need to opt in?

Offer

I have the full scan output (repo + file + current link text for all 183 info.md occurrences) and can share it as a list, or prepare changes in whatever shape is actually useful — a single scripted sweep, per-family batches, or nothing at all if the answer to Q1 is no. I'd rather not open 183 PRs into 191 separate maintainer queues without a signal that they're wanted.

For context, I opened OWASP/www-project-top-ten#93 for the single Top 10 occurrence before running the wider scan; happy to close it if this gets handled centrally instead.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions