Migrate website to Next.js rebuild (history-preserving)

[rudra-iitm]

Migrate the OpenPrinting website to the Next.js rebuild

This PR replaces the current Jekyll site with the new Next.js + Tailwind + Framer Motion rebuild, while preserving the complete existing Git history. It is opened as a draft for maintainer review — it does not change master or any repo settings on its own.

History preservation (most important)

This is a merge of two previously-unrelated histories, not a force-push:

Parent	Lineage	Commits
1	master — 7 years of OpenPrinting site history	891
2	redesign — the Next.js rewrite	70

• The working tree of the merge equals the redesign tree exactly (no leftover Jekyll files).
• No history was rewritten and no commits were dropped. Every author, timestamp, and commit on both sides remains reachable via git log. Authors such as Michael R Sweet, Till Kamppeter, Zdenek Dohnal, dependabot, etc. are fully preserved on the first-parent history.
• git log --first-parent continues to show the original master timeline, with this merge on top.

What changed in config for production

• Base path (config/site.config.ts): defaults to "" (domain root). This is the org root Pages site (https://openprinting.github.io/), so a project-style /openprinting.github.io prefix would 404 every asset/CSS/JS/link. ?? "" keeps an explicit NEXT_PUBLIC_BASE_PATH override possible for sub-path previews.
• Repo owner set to OpenPrinting so repo slug, links, and Giscus mapping target this repository.
• Giscus: repoId now points at this repo. This repo has no "Blog Comments" discussion category, so comments currently map to General. ⚠️ A maintainer may prefer to create a dedicated Announcements-type "Blog Comments" category and update categoryId in config/site.config.ts.
• Workflows: build.yml / deploy.yml now trigger on master (was main).

⚠️ Required at merge time (repo admin only)

GitHub Pages for this repo is currently the legacy Jekyll builder (build_type: legacy, source master/root). This PR's tree is Next.js, not Jekyll. Before/when this lands on master, Pages "Build and deployment → Source" must be switched to "GitHub Actions" (the included deploy.yml builds the static export and publishes it). Otherwise Pages will try to Jekyll-build a Next.js tree and the live site will break. There is no custom domain (cname: null), so no CNAME handling is needed.

Validation performed locally

• ✅ tsc --noEmit typecheck
• ✅ next lint (no warnings/errors)
• ✅ RSS generation — links are correct root URLs (https://openprinting.github.io/...)
• ✅ Search index generation — root-relative paths, no double prefix
• ⏳ Full next build runs the Foomatic prebuild which needs Linux-only system packages — it runs in CI (build.yml) on this PR.

Rollback

Trivial and safe: master is untouched. If anything is wrong, close the PR (and, if already merged, the merge can be reverted; the legacy Pages source can be restored). No history is lost either way.

[rudra-iitm]

@tillkamppeter All review comments have now been addressed, and everything is working as expected. I have also added a new OpenPrinting news article announcing the new website.

Could we please consider merging this PR before adding any further feature requests? The scope of this PR has already grown significantly, and continuing to add new changes is making it increasingly difficult to review, maintain, and manage effectively.

Any additional feature requests can be handled in separate issues or follow-up PRs after this one is merged.

[tillkamppeter]

Looks all, great, also thanks for making the announcement of your work, the new web site, started as a GSoC 2024 and after that you continuing as mentor/team manager with GSoC candidates, contributing to both the web site and our GSoC selection process ...

It is nearly ready for release, but it still has 2 awkwardnesses:

1. The Foomatic driver list. It has this ugly "Click for more items" interface which I hate on many web sites, where you click, click, click, and do not know where the list ends. You need something near the end and cannot just scroll down. Please use the same mechanism as for the printer list. User chooses how many entries they want to see, including all entries. Then user sees how many pages exist or has everything on one page, for a quick drag on the scroll bar.
2. The Opportunity Open Source site should have a banner which has to do with the Opportunity Open Source, not the OpenPrinting banner.

[rudra-iitm]

Looks all, great, also thanks for making the announcement of your work, the new web site, started as a GSoC 2024 and after that you continuing as mentor/team manager with GSoC candidates, contributing to both the web site and our GSoC selection process ...

It is nearly ready for release, but it still has 2 awkwardnesses:

1. The Foomatic driver list. It has this ugly "Click for more items" interface which I hate on many web sites, where you click, click, click, and do not know where the list ends. You need something near the end and cannot just scroll down. Please use the same mechanism as for the printer list. User chooses how many entries they want to see, including all entries. Then user sees how many pages exist or has everything on one page, for a quick drag on the scroll bar.
2. The Opportunity Open Source site should have a banner which has to do with the Opportunity Open Source, not the OpenPrinting banner.

Resolved

[tillkamppeter]

Thanks you very much.

The driver list is correct now.

For the banner at Opportunity Open Source I had more thought about something like this:

https://www.linkedin.com/company/opportunityopensource/posts/

Especially the OOSC logo which you have used is outdated. The correct logo is the blue/green one you see on LinkedIn.

For extracting the images, right-click the image, then "Save image as ..." or "Open image in new tab"+"Save as ...".

The new logo:

The group photo of OOSC 1.0 in IIT Mandi 2023:

[tillkamppeter]

As we have annual Opportunity Open Source conferences, it also would be great to have an oosc/ directory under which there are all resources of the Opportunity Open Source. This makes maintenance easier. There can also be sub-directories specific to certain editions, like oosc/oosc1.0, oosc/oosc2.0, ... but make sure that things which are for all editions are somewhere under the main and not in one of these subdirectories.

[rudra-iitm]

@tillkamppeter All review comments have now been resolved.

Also, considering the significant time and effort invested by the contributors who helped make this website redesign possible, I have added a Hall of Fame section at the bottom of the homepage to recognize and acknowledge their contributions.

[tillkamppeter]

Here is a photo of Ishpreet Singh, for the Hall of Fame and also for the other page where you mention the site contributors.

[tillkamppeter]

About your announcement post and the Hall of Fame:

First of all, use the real names of the persons also in your announcement post

For you, you have a different avatar when you mention yourself in the announcement and in your author box. Please use the same avatar in both cases and especially use one where your face fills significant part of the area. Avatars are often displayed very small and full-body photos or even environmental portraits give something completely unusable then.

And use the photo of Ishpreet which I have posted in my previous comment. Having the random-pattern default avatar there looks really strange.

Also, the contributors are people, not GitHub accounts, so you should make author box entries for them and use that info when you mention them. Especially do not let the site build pull the contributors data freshly from GitHub. Some change or withdraw their avatar, others even give up their account.

Another point is the Hall of Fame on the front page: With this one you market the persons who have made the OpenPrinting web site more strongly than the people who make OpenPrinting itself. So I think it is better not having such a Hall of Fame on the front page. Better is to have somewhere on the front page a permanent link to your announcement post, so that people could see the authors there without digging through the blog history.

[tillkamppeter]

Another little issue:

In the main directory is a file named yarn.lock which is modified every time when yarn install is run, but the file belongs to the GIT repo. For me it looks like that it is machine-generated (by yarn install) and therefore should not be part of the GIT repo (if so, just do git rm yarn.lock).

As it is now, I always have to do git stash between test runs (git pull; yarn install; yarn dev).

If yarn.lock was actually written by you, but each yarn install run modifies it by adding random tokens or checksums to it, then create a yarn.lock.in for the GIT repo and let the build/install process copy it to yarn.lock in the beginning.

A correct GIT repo does not modify any of the files belonging to the repo during the build, test, and install process. The process can add files, but not modify any file which is under version control.

[rudra-iitm]

Another little issue:

In the main directory is a file named yarn.lock which is modified every time when yarn install is run, but the file belongs to the GIT repo. For me it looks like that it is machine-generated (by yarn install) and therefore should not be part of the GIT repo (if so, just do git rm yarn.lock).

As it is now, I always have to do git stash between test runs (git pull; yarn install; yarn dev).

If yarn.lock was actually written by you, but each yarn install run modifies it by adding random tokens or checksums to it, then create a yarn.lock.in for the GIT repo and let the build/install process copy it to yarn.lock in the beginning.

A correct GIT repo does not modify any of the files belonging to the repo during the build, test, and install process. The process can add files, but not modify any file which is under version control.

Read this article - https://stackoverflow.com/questions/39990017/should-i-commit-the-yarn-lock-file-and-what-is-it-for

[tillkamppeter]

Some small issues:

• Why is the file public/search/static-index.json in the repo? For me it looks like a machine-generated search index file, to be regenerated on each site rebuild (by the CI/CD GitHub workflow which happens after each commit).
• On your announcement blog page you list the contributors, for each one a paragraph starting with the avatar, then the name and then the GitHub link. After that, separated by a long dash you start the text in the same line. and let it flow into the following lines. Due the avatar being larger than the font, the first line is more distant from the others and gets unintentionally highlighted, letting whatever item is in this line, this item being highlighted. Especially with Gaty I see that an item which is not the most important is in that first line. Therefore I suggest to start the description in a new line after the first, just put a newline character instead of the long dash right after the GitHub link. Then the description text stands completely together with uniform line spacing and not highlighting anything without intention.
• I would call the "Hall of Fame" page "This Website's Hall of Fame", as with just "Hall of Fame" some people could overlook that this is about the website developers and not about the open source printing developers.

[tillkamppeter]

Also do not forget to mention in the README.md:

• To mention that the Yarn installer is sometimes called yarn, sometimes yarnpkg
• Installation/Build instructions for Debian/Ubuntu
• Need of yarn build to include Foomatic database
• Need to git stash or at least reset yarn.lock (please add command to reset just this file) before further git actions (git pull, git commit, ...).

[tillkamppeter]

Issues:

• Word breaking at line end: If a long word reaches the line end and does not fit in, it is just broken, not cut at the end of the last fitting syllable and hyphenated, or just no word breaks done. Please check whether in yarn or Node.js you can set hyphenation style/language or suppress breaking words.
• If I go to the display of a PPD file on the old (current) site (URI generated by clicking button for displaying the PPD for the Alps MD-2010 with the ppmtomd driver)

https://openprinting.org/ppd-o-matic.php?driver=ppmtomd&printer=Alps-MD-2010&.submit=Generate+PPD+file&show=1&.cgifields=show&.cgifields=shortgui

and apply the URI to the test copy of the new site via

http://localhost:3000/foomatic/ppd-o-matic.php?driver=ppmtomd&printer=Alps-MD-2010&.submit=Generate+PPD+file&show=1&.cgifields=show&.cgifields=shortgui

I get an error:

Server Error

Error: Page "/[...slug]/page" is missing param "/foomatic/ppd-o-matic.php" in "generateStaticParams()", which is required with "output: export" config.

This error happened while generating the page. Any console logs will be displayed in the terminal window.

DevServer.renderToResponseWithComponentsImpl
node_modules/next/src/server/base-server.ts (1982:17)

Old URLs should work on the new site, just ignoring parameters which do not exist on the new site any more.

[tillkamppeter]

Also a straight PPD download which works with the old site

wget -O old.ppd 'http://www.openprinting.org/ppd-o-matic.php?driver=ppmtomd&printer=Alps-MD-2010'

does not work with the new site:

$ wget -O new.ppd 'http://localhost:3000/foomatic/ppd-o-matic.php?driver=ppmtomd&printer=Alps-MD-2010'
--2026-06-09 12:43:44--  http://localhost:3000/foomatic/ppd-o-matic.php?driver=ppmtomd&printer=Alps-MD-2010
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:3000... connected.
HTTP request sent, awaiting response...  ⨯ [Error: Page "/[...slug]/page" is missing param "/foomatic/ppd-o-matic.php" in "generateStaticParams()", which is required with "output: export" config.] {
  page: '/foomatic/ppd-o-matic.php'
}
500 Internal Server Error
2026-06-09 12:43:44 ERROR 500: Internal Server Error.

 GET /foomatic/ppd-o-matic.php?driver=ppmtomd&printer=Alps-MD-2010 500 in 121ms
$

[tillkamppeter]

Problem seems to be the .php extension. The old site had ppd-o-matic.php, the new has just ppd-o-matic. So ppd-o-matic.php in the URL needs to get mapped to ppd-o-matic, or generally, all .php needs to be filtered from the URL.