The Photonics Spotlight > 2023-05-25

The RP Photonics Website Got a New Technical Basis

A sophisticated website like ours – containing resources like the RP Photonics Encyclopedia and the RP Photonics Buyer's Guide – is based on a complicated technical system. From time to time, such a system needs some reworking, and that has now been the case for our website – specifically, for all pages except those buyer's guide pages which are automatically generated by our supplier database system (e.g., pages listing suppliers for a certain product such as ultrafast lasers). In particular, that applies to all encyclopedia pages and to the three blogs: The Photonics Spotlight, The RP Photonics Software News and the The RP Photonics Marketing News, apart from many pages describing our software, consulting services etc. Some users may be interested to look a little behind the scenes, and I am happy to reveal what I have done in the last couple of weeks.

The Content Management System

There are numerous Content Management Systems (CMS) out there, but I have been very reluctant to commit to any one of those, since you make yourself quite dependent on it and may later on face serious limitations. In our case, we need plenty of pages which contain some kind of automatically processed content. To give you just one example:

• The encyclopedia contains pages listing all articles starting with a certain keyword (see, e.g., the one for A).
• It must also list referrals to articles, i.e., allowing you to start out with some other terms, differing from the title of the corresponding article we have. For example, you may search for “absolute phase” and are then referred to the article on carrier–envelope offset which explains that term.
• Further, I need to automatically insert references to certain articles on related topics, since that is a great chance for users to become aware of valuable additional articles.

One more example would be the integration with the buyer's guide – in particular, connecting encyclopedia articles with supplier lists and vice versa.

You can imagine that with such kinds of additional requirements, one can easily run into a situation where one hits serious limitations of the chosen CMS, and will eventually have to live without certain nice features, or realize them in a rather awkward way.

For such reasons, I decided to again largely develop my own solution, using only two basic third-party tools:

• For editing pages, we are now using Obsidian. This is actually a note-taking software, but an excellent one. Last year, I discovered that, and first started to use it for the large volume of notes on all sorts of topics – for example, on software development, general company issues, and even on private things such as everything related to our house. Apart from the great convenience of Obsidian's features, e.g. allowing one to easily reorganize notes as required, and the easy further extensibility using plugins, I like very much its openness and robustness concerning the file structure. Each note is simply a plain text file in Markdown format, which is easy to access and process with other software (e.g., some scripts); it is no problem to let some scripts amend or modify the Markdown files even while Obsidian is running! Similarly, the simultaneous use by multiple people is no problem.

• A website requires HTML files, and these need to be made from the Markdown files. So I have one note page in Obsidian for each HTML web page, and generate the latter using a sophisticated self-made Python script – which, by the way, can effortlessly be called with a single keystroke from Obsidian. For elementary websites, a publicly available Python module named Python-Markdown would mostly do the required conversion to HTML, but in our case, a lot more sophisticated processing is required – for which some self-made Python code is a quite ideal tool. You get done a lot with relatively compact code, which is at the same time nice to read and relatively easy to understand.

By the way, that system still generates essentially static web pages, in contrast to other systems using a database on the web server for the content. I very much prefer static pages for such applications, mostly because they are much easier to process. When a user requests a page, its presentation will not first require a database lookup and a lot of further processing on the server. Rather, most processing is done already on my PC before uploading the page, and the web server has an easy job. I use that principle even for the buyer's guide pages, although those really need a database – but on my PC, not on the web server. Users appreciate very much that our system offers far shorter loading times than the pages of many of our competitors. That's just one of many aspects where we reach better user experience.

Since the essential code conversion is all home-made, I can resolve any issue myself as soon as I can identify it, and can add further features with no limitations. That's so much nicer than waiting for others to fix certain things which annoy you and/or your readers.

Of course, you can only go that way if you have sufficient expertise and experience in house. For many other companies, that way would therefore not be a viable option. But I find it very valuable to have learned all the required technical stuff – HTML with CSS, some JavaScript/jQuery and PHP, Python and Delphi, design and usability aspects, web security issues, etc. Hard work indeed, but very worthwhile.

Benefits for Us and for the Users

I briefly summarize the key benefits achieved with our new website system:

• For us, it is now considerably more convenient to create new pages and edit existing content. That is particularly relevant since my new colleague will increasingly need to work on web pages.
• An indirect benefit for our users is that if it becomes easier for us, we can generate more and better content within our limited time.
• There are also some direct benefits – in particular, the much improved typesetting of equations, now using MathJax. Look, for example, at the encyclopedia article on the delayed nonlinear response. I am excited to now have so much better-looking equations, which are at the same time way more convenient for us to make.
• Not relying on a common CMS, and even avoiding the use of a database system like MySQL, also has security advantages. I see that our web server is regularly bombarded with requests from automated code aiming to exploit certain vulnerabilities of common CMS like WordPress. These all have no chance whatsoever to hurt us. And, by the way, the website is also made rather secure for our users – which is confirmed by the Mozilla Observatory, giving our website the excellent grade A⁺. (Compare that with some competitors of us!) You find more on that topic in an article from 2021. (This aspect is actually not new: our previous website had those security advantages already for several years, some of them even from start in 2004.)

Only, we might still have a few so far overlooked issues caused by the transition to the new system. (If you notice anything not working perfectly, please tell me!) But I assume it is nothing serious.

Well Invested Time

Of course, it takes substantial time to work out the concept for a new website system and to implement it. It made me very busy for several weeks. But for a website helping the whole photonics community, and being the basis of essentially all our business, this was surely very appropriately spent time.

This article is a posting of the Photonics Spotlight, authored by Dr. Rüdiger Paschotta. You may link to this page and cite it, because its location is permanent. See also the RP Photonics Encyclopedia.

Note that you can also receive the articles in the form of a newsletter or with an RSS feed.