WordPress Multisite Certified by Bitnami and Automattic
Bitnami by VMware | 6.6.2-10-r12 on Debian 12Linux/Unix, Debian 12 - 64-bit Amazon Machine Image (AMI)
Troubles with redirects and bad UI/UX
I still have a trouble to make it NOT to redirect to the main domain when I open an additional site.
UI/UX of Sites is somehow inconvenient.
Otherwise, thank you for this useful work.
- Leave a Comment |
- Mark review as helpful
Is this AMI really the problem?
Note: This review exceeds the suggested 300 word limit by ~130 words. If that bothers you, skip the explanation, the first paragraph and conclusion found at the end summarize the problem.
I don't accept the reviews claiming this does not work. I think blaming the AMI misses the point. Blame, if any, should be directed at code developed by 3rd parties not Bitnami or WordPress.
Explanation:
I tried this AMI in a staging environment and quickly reverted back to my saved version of a previous Bitnami AMI running PHP 5.6, I don't believe the AMI is at fault. I gave it 3 stars because I wish Bitnami offered another WP multi-site AMI with PHP 5.6. On the other hand, enabling people to continue avoiding PHP 7, especially with a WP site, isn't necessarily good practice.
A better solution would be to downgrade to PHP 5.6 yourself after installing the AMI. I suspect for many people that might prove too difficult and defeat the purpose of using a readymade AMI solution.
If anyone has experience where a site works with PHP 7 in another environment but doesn't work with this AMI, I would very much like to hear about it.
I would skip Bitnami altogether and install a stack on a generic EC2 Linux instance then install WP multi-site. However, I tend to like Bitnami's application solutions. The structure they implement, although often annoying, provides better security than I want to spend time implementing if starting from scratch.
This AMI would probably be getting 4 and 5 star reviews if users ran WordPress by itself. But who does that?
There are virtually always 3rd party themes and plugins involved. When I reverted to an older version, mentioned above, I was working with a site I inherited that depended on numerous (an understatement) plugins of questionable quality. There wasn't time or money available to debug so much code to resolve PHP 7 issues. The site contains code that is so poorly written that it won't run on PHP 5.6 either when debug is turned on; so many notices and warnings are generated that the page output cannot be rendered in a browser. Granted, debug should NOT be on in a production environment but, the ability to enable it in a dev environment would be nice.
Summary:
PHP 7 has been a long time in the making. WordPress core developers have been preparing for it and WP runs fine, and much faster, by itself with this AMI but frequently themes and/or plugins do not because they were developed using PHP 5.6, or older, and are often poorly written to begin with. Theme/plugin developers state what version of WP they have tested against but usually don't mention, or even consider, whether PHP 7 is supported.