[#238] Remove unused blog data, a stray redirect post and outdated share links

[vharseko]

Summary

Cleanups from #238:

• Unused data file — deleted _data/blogposts.yml (778 lines). Nothing references it: no template, page or migrate-to-posts.py; it predates the move to _posts/ (Migrate to Jelyll _posts directory to use paging and page dates. #227).
• Stray redirect post — deleted _posts/2024-06-20-How-To-Protect-Web-Services-with-OpenIG copy.md, a layout: redirect post pointing at /blog/2025-11-05-openig-getting-started. It was not in the issue, but it was visible: an empty card "How To Protect Web Services With Openig copy" on /blog/page10/, and a noindex URL listed in sitemap.xml. Nothing links to its …-OpenIG-copy URL; the original 2024-06-20-How-To-Protect-Web-Services-with-OpenIG article is kept.
• File name with a space — renamed _posts/2026-02-04-opendj-5-0-3-released .md to 2026-02-04-opendj-5-0-3-released.md. The URL stays /blog/2026-02-04-opendj-5-0-3-released.
• Share links — _includes/share-buttons.html now uses https://twitter.com/intent/tweet?url=… instead of the deprecated http://twitter.com/home?status=…, and https://www.facebook.com/sharer/sharer.php?u=… instead of http://…/share.php; the shared URL is URL-encoded on all four buttons, LinkedIn included. Every share window opens with window.open(url, '_blank', 'noopener'), so the social site gets no window.opener back to this tab.
• Pinterest button — it was wrapped in {% if page.image %}, which no page sets, so it never rendered (and it passed an empty url=). It now renders when the page has a non-empty imageurl and passes the page URL, /assets/img/<imageurl> and the title (landing-title or title), all URL-encoded, to https://www.pinterest.com/pin/create/button/. The six OpenIDM posts point at openidm-og.png, which [#232] Add the missing OpenIDM and OpenICF Open Graph images #244 adds; until it is merged their Pinterest image, like their og:image, is a 404.

The fourth item of the issue (empty imageurl: '') is fixed in #239.

Fixes #238

Verification

Built the site with bundle exec jekyll build (Ruby 3.1, as in CI) and ran the same htmlproofer internal-link check as the workflow: no errors.

• Compared with a build of master, the only removed output file is blog/2024-06-20-How-To-Protect-Web-Services-with-OpenIG-copy.html; blog/2026-02-04-opendj-5-0-3-released.html keeps its path.
• sitemap.xml and the blog pages no longer mention the -copy URL.
• Share buttons render e.g. https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.openidentityplatform.org%2Fblog%2F2025-12-18-openam-vs-keycloak and https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fwww.openidentityplatform.org%2Fblog%2F2025-12-18-openam-vs-keycloak&title=&summary=&source=.
• All 513 rendered window.open(…) calls (135 pages × 3 buttons + 108 Pinterest buttons) pass '_blank', 'noopener'.
• The Pinterest button renders on 108 of the 135 pages with share buttons; the other 27 have no imageurl, so there is no image to pin. Example: https://www.pinterest.com/pin/create/button/?url=https%3A%2F%2Fwww.openidentityplatform.org%2Fblog%2F2025-12-18-openam-vs-keycloak&media=https%3A%2F%2Fwww.openidentityplatform.org%2Fassets%2Fimg%2Fopenam-og.png&description=OpenAM+vs+Keycloak.

[maximthomas]

praise: The cleanup removes only dead weight and every URL that is still live stays the same.

• _data/blogposts.yml has no reader: at the base, site.data is used only for products, product_links and vendors, and an org-wide code search finds no other consumer.
• The rename keeps /blog/2026-02-04-opendj-5-0-3-released: Jekyll 3.9.3's pretty Utils.slugify turns the trailing space into - and then strips it (lib/jekyll/utils.rb:222).
• url_encode keeps the new share URLs safe inside the single-quoted onclick strings (' → %27, & → %26).

---

issue (non-blocking): The Pinterest button now appears on six OpenIDM posts whose imageurl file does not exist.

_includes/share-buttons.html:40, _posts/2024-09-10-openidm-ad-idm.md, _posts/2024-11-13-openidm-can-your-idm-play-chess.md, _posts/2025-05-13-openidm-two-way-ad-opendj.md, _posts/2025-07-16-openidm-6-3-0-released.md, _posts/2025-11-05-openidm-getting-started.md, _posts/2026-02-05-openidm-7-0-2-released.md

These posts set imageurl: 'openidm-og.png', but assets/img/ has only openidm-logo.png, and openidm-og.png has never been in the repository. The old page.image guard hid the button on these pages; the new guard shows it, so a click sends Pinterest media=…%2Fassets%2Fimg%2Fopenidm-og.png, which returns 404 on the live site (openidm-logo.png returns 200). The same missing file already breaks og:image (_includes/header.html:4) and the JSON-LD image (_includes/structured-data.html:120) on these pages.

# front matter of each of the six posts
imageurl: 'openidm-logo.png'

Or: add assets/img/openidm-og.png, which fixes Pinterest, og:image and JSON-LD at once and keeps a proper preview image.

---

suggestion (non-blocking): Encode the LinkedIn share URL like the other three.

_includes/share-buttons.html:39

Line 39 still builds &url={{ site.url }}{{ pageurl }}, while Facebook, Twitter and Pinterest now pipe the URL through url_encode, and the description says the shared URL is URL-encoded. Post URLs contain only [A-Za-z0-9-], so nothing breaks today; a URL with &, # or ' would cut LinkedIn's url= or break the JS string.

onclick="window.open('https://www.linkedin.com/shareArticle?mini=true&url={{ site.url | append: pageurl | url_encode }}&title=&summary=&source=');"

---

suggestion (non-blocking): Open the share windows with noopener.

_includes/share-buttons.html:37-40

All four window.open('…') calls pass no window features, so the Facebook, X, LinkedIn and Pinterest pages get window.opener and can navigate the openidentityplatform.org tab. The pattern predates this PR, but three of the four lines are rewritten here. noopener on its own does not request a popup, so the share page still opens in a tab.

onclick="window.open('https://twitter.com/intent/tweet?url={{ site.url | append: pageurl | url_encode }}', '_blank', 'noopener');"

---

suggestion (non-blocking): No CI step checks the rendered share URLs.

.github/workflows/build.yml:19-30, _includes/share-buttons.html:37-40

The build runs jekyll build and htmlproofer --checks Links with every external https URL ignored, and html-proofer does not read onclick anyway. Dropping | url_encode, going back to twitter.com/home?status=, sharer.php → share.php, or a wrong /assets/img/ prefix all stay green; only a Liquid syntax error fails the build.

      - name: Check share-button URLs
        run: |
          f=_site/blog/2025-12-18-openam-vs-keycloak.html
          u='https%3A%2F%2Fwww.openidentityplatform.org%2Fblog%2F2025-12-18-openam-vs-keycloak'
          grep -qF "https://www.facebook.com/sharer/sharer.php?u=$u'" "$f"
          grep -qF "https://twitter.com/intent/tweet?url=$u'" "$f"
          grep -qF "https://www.pinterest.com/pin/create/button/?url=$u&media=https%3A%2F%2Fwww.openidentityplatform.org%2Fassets%2Fimg%2Fopenam-og.png&description=OpenAM+vs+Keycloak'" "$f"

Pin: each grep -qF fails the step under Actions' bash -e unless its URL is rendered exactly this way, which kills the url_encode, endpoint and image-prefix mutants.

[vharseko]

Missing openidm-og.png — left to #244, which adds assets/img/openidm-og.png (your second option) and fixes Pinterest, og:image and the JSON-LD image on these six posts at once. Switching them to openidm-logo.png would go the other way: #246 moves all 20 OpenIDM posts onto openidm-og.png, and the logo is a ~700×172 strip rather than a 1024×512 card. The PR description now names #244.

LinkedIn URL — done in da7fb51: it goes through site.url | append: pageurl | url_encode like the other three.

noopener — done in the same commit: all four buttons call window.open(url, '_blank', 'noopener'). In the build, all 513 rendered window.open(…) calls carry it.

CI check of the share URLs — not in this PR. The proposed step pins one post's title and image, so editing that post would fail the build without anything being wrong with the buttons. The same kind of check was suggested for the head meta in #239 and was not added there either; if we want checks on rendered HTML, I'd rather open one issue that covers both than add them PR by PR.