Proposal: deprecate PHP for download/archive pages

[subyssurendran666]

This discussion is based on this issue.

Since PHP support for the download and archive pages will be deprecated by the end of 2025, this discussion focuses on how to address that situation. A mechanism will definitely be needed to handle it, and JavaScript could be a viable solution, potentially using a front-end library or framework like React or Angular.

If we proceed with the JavaScript approach (or any other approach), will the code be maintained in the Releng repository itself? Additionally, if web APIs are needed (it’s unclear if the current download/archive pages rely on PHP-based APIs), what would be the best alternative? Should we consider Node.js or another scripting language?

Note: After reviewing some of the webpages under download.eclipse.org, it seems that an implementation based solely on HTML and CSS would not suffice.

I’m eagerly awaiting suggestions and opinions from the community members.
@BeckerWdf @HannesWell @merks @akurtakov @laeubi @vogella @MohananRahul @mickaelistria @gireeshpunathil @mpalat

[gireeshpunathil]

what are the features in the page for which HTML & CSS are insufficient?

I agree that javascript is a great choice: popular, supported by all browsers, well maintained.

[subyssurendran666]

what are the features in the page for which HTML & CSS are insufficient?

For example, consider the download page of Eclipse 4.34. Here, much of the information is processed using PHP. Some of the information is parsed from external files, such as XML, while other information is processed based on the values obtained from the URL.

In the archive website, plugins are organized into their respective folders, and the information is displayed on the web pages. This functionality is implemented using PHP.

[nburnwal09]

For scripting language, we can alternately use Python with Flask which is easy and flexible and can easily parse XML with libraries like lxml. Or we can use Django for more feature-rich framework.

[HannesWell]

An alternative of course would be to try generate everything "offline" as much as possible but then these generators need to be maintained, the files must be uploaded regular and so on.

As the general recommendation of the EF-webmasters is to generate static HTML using Hugo, I think generating everything online is the way to go:

• https://gitlab.eclipse.org/eclipsefdn/it/webdev/hugo-eclipsefdn-website-boilerplate
• https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1934

I have a little bit of experience with Hugo and while I'm in general not a big fan of it, the fact that it generates the resulting static HTML from markdown is appealing to me.
Also generating the static html offline is relatively similar to what's done currently where the php files are assembled and filled with values from the current I/Y-build in Jenkins. Very simplified we would just have to render that php into static html on the build server.

Because when looking e.g. at the download-page of R-4.34, the content is actually static only presenting the download-able artifacts or logs in a nicer format. But all backing data are immutable and co-located (directly or indirectly) to the php files. So generating static html is definitively possible.

The only dynamics comes from the fact that for I/Y-builds the test result page is updated as soon as the tests for a specific configuration have concluded. But for that we can simply regenerate the static HTML page with the new results in the corresponding update job that is triggered by the test-job once it has finished.

I agree. We should consider any learning curve involved in maintaining/developing new things and also consider the long-term viability of what's being used. Today's cool dejour technology, is next year's crappy legacy technology ready for the garbage bin...

I fully agree with that. Another thing that I would highly appreciate is that the new solution should be relatively simple to understand or learn for ordinary Java developers without a (strong) web background like most of the devs of Eclipse are. Because in the end we usually have to maintain it our-self. Ideally the required tech-stack is simple to set up, e.g. like for HUGO, just download an executable and add it to path and you are done (personally I would like to avoid downloading the internet the second-time on my computer with Node.js or alike).

For now I think Hugo would be an ok-ish solution, hoping that it's supported for long enough or if its supports end the EF-staff will help us to find a new solution easily as we have followed their advice. Alternatively we could create the raw HTML file structure manually and just fill the voids using simple bash-scripts or java-classes.

[mickaelistria]

Using hugo requires some development. Since we already have the .php files, can't we just use those to statically generate .html files? eg just calling php -f testResults.php > testResults.html could work.

[subyssurendran666]

Using hugo requires some development. Since we already have the .php files, can't we just use those to statically generate .html files? eg just calling php -f testResults.php > testResults.html could work.

A question for @HannesWell : Is EF planning to deprecate both PHP-FPM and PHP-CLI? If PHP-CLI remains available, @mickaelistria 's suggestion would be simple and effective.

I

An alternative of course would be to try generate everything "offline" as much as possible but then these generators need to be maintained, the files must be uploaded regular and so on.

As the general recommendation of the EF-webmasters is to generate static HTML using Hugo, I think generating everything online is the way to go:

• https://gitlab.eclipse.org/eclipsefdn/it/webdev/hugo-eclipsefdn-website-boilerplate
• https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1934

I have a little bit of experience with Hugo and while I'm in general not a big fan of it, the fact that it generates the resulting static HTML from markdown is appealing to me. Also generating the static html offline is relatively similar to what's done currently where the php files are assembled and filled with values from the current I/Y-build in Jenkins. Very simplified we would just have to render that php into static html on the build server.

Because when looking e.g. at the download-page of R-4.34, the content is actually static only presenting the download-able artifacts or logs in a nicer format. But all backing data are immutable and co-located (directly or indirectly) to the php files. So generating static html is definitively possible.

The only dynamics comes from the fact that for I/Y-builds the test result page is updated as soon as the tests for a specific configuration have concluded. But for that we can simply regenerate the static HTML page with the new results in the corresponding update job that is triggered by the test-job once it has finished.

I agree. We should consider any learning curve involved in maintaining/developing new things and also consider the long-term viability of what's being used. Today's cool dejour technology, is next year's crappy legacy technology ready for the garbage bin...

I fully agree with that. Another thing that I would highly appreciate is that the new solution should be relatively simple to understand or learn for ordinary Java developers without a (strong) web background like most of the devs of Eclipse are. Because in the end we usually have to maintain it our-self. Ideally the required tech-stack is simple to set up, e.g. like for HUGO, just download an executable and add it to path and you are done (personally I would like to avoid downloading the internet the second-time on my computer with Node.js or alike).

For now I think Hugo would be an ok-ish solution, hoping that it's supported for long enough or if its supports end the EF-staff will help us to find a new solution easily as we have followed their advice. Alternatively we could create the raw HTML file structure manually and just fill the voids using simple bash-scripts or java-classes.

If EF is recommending proceeding with Hugo, then it gets my thumbs-up.

[mickaelistria]

When we run build, we're free to include any software we want (through docker image), so even if it's not in by default, then php-cli could still be added to the build pipeline.

[HannesWell]

When we run build, we're free to include any software we want (through docker image), so even if it's not in by default, then php-cli could still be added to the build pipeline.

Yes that should work, although I don't know in detail what has to be done to add the required tools to a docker-image or even better to just download them into an existing image.

Using hugo requires some development. Since we already have the .php files, can't we just use those to statically generate .html files? eg just calling php -f testResults.php > testResults.html could work.

That sounds like a small change for our current situation. But since overall the creation of the static html is then more than convoluted (in German one could say "von hinten durch die Brust ins Auge" literally translated 'from behind through the chest into the eye').
On the long run we should still find a solution that generates static HTML more directly.

Maybe we could even just caputre the current HTML rendered from php can replace some required voids with a script or java-code from the corresponding results.

[MohananRahul]

Seems to be duplicate of #2656.