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.

[subyssurendran666]

I was just checking how complex it is to migrate dynamic content to static HTML using JavaScript. Since web APIs are needed to enable interaction between the front-end and back-end, I have a question: Is Java installed on the download.eclipse.org and archive.eclipse.org servers? If so, we could set up APIs using Java Servlets.

@HannesWell @opcoach

[HannesWell]

Is Java installed on the download.eclipse.org and archive.eclipse.org servers? If so, we could set up APIs using Java Servlets.

At the moment Java is indeed installed at the download-server, however I strongly recommend to not rely use it as we want move away from using that java-installation. In the end the download server should only host and provide static data.

A possible to solve this entire problem is using html+java-script and implement any dynamics at the client using JS, if that's actually necessary.
We could also create the site-content in markdown and use a java-script renderer that renders the markdown to html at the client site. This way the preprocessing at the server is much simpler. This is currently done for the Eclipse N&N entries:

• https://github.com/eclipse-platform/www.eclipse.org-eclipse/tree/master/markdown

In the end the page itself doesn't a lot of dynamics as it actually only changes when some test-results arrive or the build is marked as unstable (or again as stable). So in the main build we could for example generate the site-content that lists the all the produced artifacts:

• https://download.eclipse.org/eclipse/downloads/drops4/R-4.35-202502280140/

When a test-setup completes the corresponding job could update the corresponding line in the tests results table and generate the new (static) content and pushes it to the server.

In general the generated output could either be static html or just markdown that is then rendered to HTML at the client as mentioned above. And to generate the static content we could just use a Java script, i.e. a single source java program (not the Java-Script language here) that is executed as part of the build and assembles the static output files.

This way the server would just contain static content, which is changed by build-jobs if the site-content should change.
And we would only use technologies that are hopefully lasting long and are relatively well understood by Java-developers and relatively easy to test locally.

[subyssurendran666]

I have a few doubts regarding how the PHP files are generated. In the Releng repository, I couldn't find a file named index.php, which is responsible for rendering the release page for each build (e.g., 4.36RC2).

However, I got a basic understanding that the index.template.php might be used to generate the actual index.php during the build process. It seems like Jenkins transforms this template into the final index.php.

Similarly, I assume buildproperties.phpHoldForLocalTests is used to generate the buildproperties.php.

@HannesWell @opcoach @akurtakov — Could someone please confirm if my understanding is correct or help clarify this process?

[akurtakov]

Your best start is https://github.com/search?q=repo%3Aeclipse-platform%2Feclipse.platform.releng.aggregator%20index.template.php&type=code . Following from these search results will point you to the exact usage.

[HannesWell]

Instead of trying to understand the existing PHP files one by one, one could also just start by rebuilding the current pages with the approach described in my other answer (#2715 (reply in thread)) and rebuild every page (or at least only the parts that are still relevant). Of course one should not completely ignore the existing sources, but I think it's also not the best approach trying to convert the current PHP code exactly into something else.

One could just start for example with the R-4.35 page and the overview page:

• https://download.eclipse.org/eclipse/downloads/drops4/R-4.35-202502280140/
• https://download.eclipse.org/eclipse/downloads/

and rebuild them in the static way I described.

And if you want to see the actual file-system structure at the download-server, you can use this handy view:

• https://download.eclipse.org/justj/?file=eclipse/downloads/drops4/R-4.35-202502280140

However, I got a basic understanding that the index.template.php might be used to generate the actual index.php during the build process. It seems like Jenkins transforms this template into the final index.php.

It could be this job that does this:

• https://ci.eclipse.org/releng/job/Releng/job/updateIndex/