I knew it would distract me. Here are two working prototypes of a six-image overlay display. The first (index.php) uses server-side PHP only, the second (index2.php) uses AJAX to update the display. These were written solely for new browsers, and have only been tested on MacOS Safari. They are proofs of concept only: I have made NO EFFORT to defend them against security threats, so DO NOT SERVE THESE FILES ON ANY WEB SERVER UNATTENDED. Remove them when you're through playing.
The six image overlaying is far more stable than I anticipated, but I specifically locked the image sizes to prevent resizing, and only tested on the latest browser. As I often remind customers,
• More than half of web pages are viewed on mobile phones, more than half of mobile phones are Android phones, and more than half of Android phones run OS/software combinations that are several years old.
• Microsoft has decided to retire the rendering engine in its current web browser (Edge) in favor of Chrome. Why? because they couldn't convince enough MS users to stop using Chrome, Firefox, or Internet Explorer to justify its development expense. We run sites that still have sizable IE usage stats, even though it was "End-Of-Lifed" over three years ago.
Working with any web technology means that at some point, you have to choose which potential audience you need to leave behind.
If you have a web server configured to process PHP on files with the .php engine, you should be able to run these pages by dropping these files and the imagery folder into the web root. For the record, it took about four hours for me to put these together - longer than usual because I had to create sample art and have never tried to create an AJAX page without the built-in support of my preferred CMS, Joomla.
As I suspected, the project itself isn't difficult, and wouldn't be a horrible learning experience for anyone who has picked up the basic skills needed ( HTML, CSS, PHP and Javascript / jQuery ). However, laying the groundwork necessary to make it into a safe and secure web site on a live web server is a significant amount of work, best done by someone very familiar with the threats a public site faces. This is why I still believe it would be best developed as an extension for an existing, hardened CMS system, which handles many of those challenges for you.
View attachment 33880
For the record, I wouldn't wish WordPress on anybody. While its codebase is stable, it has long sacrificed code quality in favor of backward compatibility, which means it bends over backwards to avoid more recent improvements in application design, particularly when it comes to third-party plugins and extensions. Now, it IS the most widely used CMS package out there, but that also makes it the world's biggest target. Flaws are discovered (though dutifully repaired) frequently. When an exploit appears, it is made available for sale on hacker sites within hours, and is often weaponized within a day into an automated script so that miscreants with no skills can use it. If you choose to run a Wordpress site on your own server instead of wordpress.com (where they monitor - and often handle - such problems for you), update the software as frequently as you can - automatically, if possible.
We use Joomla because they chose to recreate their codebase using modern coding standards a few years ago, and it is much better designed for extension and consistency than any other CMS we've encountered. It also presents a much smaller and less enticing target on the internet than WP. I can maintain fifty Joomla sites with less effort than running a single Wordpress instance securely. In a little over ten years, we've only had one major security event. Joomla also supports the very best-written, most easily extendable online store software we've found: Hikashop. It's a smallish provider, but their developer support is second to none.