Repository navigation
Conversation
|
Thank you for the PR and again for all the work in the previous PRs! Building everything together already looks very complete and almost indistinguishable from the previous state. Some issues on the current state:
Could you please also resolve the merge conflicts? They should mostly be trivial. |
|
Since a new Hugo release is available, let's see: how easy is it to update? |
|
Bumped the versions (also for GO while we at it ) in 95a5610 , other than that nothing interesting caught my eye in the new release. |
There was a problem hiding this comment.
First of all, this port is AMAZING, so well done @MuhammadAashirAslam!
Building this is so easy now and live editting is now actually a reality.
That said, is it possible to live edit files in the included modules? It would be a pretty big downer if this wasn't possible.
I tested the version locally and found some things which I commented on the files. Most important here is that the modules file needs some kind of autogeneration. Currently this is unmaintainable.
The sidebar still has links to the old URLs, so they trigger a redirect and thus a stutter. They should link to the new location.
The sidebar is not really needed. We should still port that to the menus. Maybe in another PR.
We have some weird links that lead to strange behaviour when navigating the website as they are located in multiple places at the same time: The quickstart and the current events.
This looks super weird, we need some solution here.
For the current events: @MakisH maybe the cleanest is to redirect to the entry. Current events could be always visible links above the sidebar, when they exist.
I think the Quickstart needs to decide if it wants to be /tutorial/quickstart/ or /quickstart/.
The community sections don't have section pages yet as they are empty.
Also the minisymposia section is called "Other events", we should maybe fix this @MakisH.
Also the README reads weird. Lines are broken at 80 chars. Could you break on sentence ends. This makes it easier to read.
Thankyou 🤗
Yes it is possible , you just have to point the modules to your local directory of the module with hugo serve . Example , if i have open foam and the precice website folder in the same directory i can do this. HUGO_MODULE_REPLACEMENTS="github.com/precice/openfoam-adapter -> $(pwd)/../openfoam-adapter" hugo serverFor more you can just add more paths with a separation of a comma HUGO_MODULE_REPLACEMENTS="github.com/precice/openfoam-adapter -> $(pwd)/../openfoam-adapter, github.com/precice/tutorials -> $(pwd)/../tutorials" hugo server
This is a problem i have tried python scripts but they have some drawbacks and occasionally i hit the github too many requests error in the workflow . I will work on this a bit more and start with the tutorials as they require the most changing (adding new tutorials ) while other modules aren't changed that much.
Done 6750fd7
Looking in to this
Done 5af53c3 |
Haha. This is not really easy to use. Could you provide a python wrapper for the modules that builds this override, sets it as an env and then runs hugo with the remaining arguments?
That would be super helpful!
Ah. From experience, I can tell that poking at git repos is often easiest with a local shallow clone. You can create a temporary directory in memory: tempfile.TemporaryDirectory |
|
As far as I can tell, the only thing missing now is generating the modules file. I see this as a hard requirement. The local hugo #987 is a nice to have. |
|
FYI, I am waiting for settling on @fsimonis' review comments before I continue with my review. The main point currently seems to be the missing @MuhammadAashirAslam please let me know once I can have another look. After merging this and #987, I will proceed with migrating the library-specific documentation pages to the library repository. |
|
I have the feeling that it will come around and bite us later, but I am ok with a non-autogenerated modules file. #990 adds a script for autogenerating the massive tutorials-part, so we have something to work with. I did another review and noticed that we use npm to install algoliasearch and provide a custom launcher. |
The reason we didn't use the official Algolia CLI is that the CLI is only a transport/API tool (algolia objects import)—it expects pre-structured JSON/NDJSON records and cannot parse HTML. In Jekyll, jekyll-algolia handled the heavy lifting of parsing the rendered HTML DOM. Hugo has no built-in DOM parser and can only export raw page HTML blobs . In index.algolia.json. tools/algolia-index.mjs (via Cheerio) reproduces the jekyll-algolia like extraction and chunking pipeline before uploading. If we used the Algolia CLI, we would still need an HTML extraction script to generate the NDJSON records beforehand . |
Co-authored-by: Gerasimos Chourdakis <gerasimos.chourdakis@ipvs.uni-stuttgart.de>
Also update content with recent changes. Co-authored-by: Gerasimos Chourdakis <gerasimos.chourdakis@ipvs.uni-stuttgart.de>
Also: remove obsolete doxygen assets, update CI workflows
Co-authored-by: Frédéric Simonis <simonisfrederic@gmail.com>
Co-authored-by: Frédéric Simonis <simonisfrederic@gmail.com>
- Re-enable news banner and fix typo - Update number of citations - Fix URLs in HTML maps
- Configure double dollar math delimiters as inline in Goldmark passthrough - Remove failing LaTeX align example
There was a problem hiding this comment.
I cleaned-up the history, removing merge commits and squashing some related commits together. I added the Hugo: prefix in the commit messages, so that I can do a simple merge and maintain an overview with smaller commits (especially retaining the links to the PRs in the early commits).
I once again checked the rendering of the most relevant pages locally and had another look at the files structure. All good.
P.S.: As stated earlier, the build CI workflow does not start because it has been renamed. All other checks pass.
This PR completes the migration of the preCICE website from Jekyll to Hugo.
Summary of Changes
1. Directory Structure & Asset Migration
images/,css/,js/) into Hugo's standardstatic/directory (static/images/,static/css/,static/js/,static/assets/data/).content/tree (content/docs/,content/community/,content/tutorials/,content/about.md).2. Architecture & Dependency Management
config/_default/module.toml,go.mod,go.sum). Imported adapter and tutorial repositories are now fetched and pinned as Hugo modules.config/_default/hugo.toml,module.toml,params.toml).3. Layouts, Partials & Shortcodes
layouts/andlayouts/partials/).{{< warning >}},{{< note >}},{{< tip >}},{{< pagebreak >}}, etc.).aliasesto ensure zero broken bookmarks or external links.4. Search Integration (Algolia)
tools/algolia-index.mjs).public/algolia.jsonduring the production build, which the CLI validates (schema check, record size limits) and uploads using atomic index replacement.5. Offline PDF Generation
tools/pdf-docs.sh).config/pdf/,layouts/partials/pdf/) to build the consolidated offline PDF directly from the Hugo content tree.6. GitHub Actions & Automation Workflows
build.yml: Streamlined CI to test both standard website generation and Algolia dry-run indexing.update-submodules.yml: Modernized to update Hugo module revisions (tools/sync_hugo_modules.py), supporting both daily schedules andrepository_dispatchtriggers from external repositories.update-discourse-data.yml: Scheduled sync for Discourse forum topics, announcements, and FAQs.update-algolia.yml: Automated search index publishing on releases/pushes.7. Documentation & Contributor Setup
README.mdwith streamlined local development instructions (hugo server) and contributing checks (pre-commit).content/docs/docs-meta/) covering site architecture, adding imported repositories, search indexing, and PDF generation.Testing & Verification
hugo server).hugo --gc --minify --cleanDestinationDir --environment production).npm --prefix tools run algolia:index -- --dry-run)../tools/pdf-docs.sh).