Sorry, guys!
Too little time, too much spam. Since I hardly manage to review comments at all and spam is still constantly increasing, I had no choice but to disable comments in general.
I will try to find a better solution than total blocking, however, I have to set priorities. Thanks for your understanding!
I had implemented my photo blog with Wordpress some years ago, primarily as a practical exercise on how Wordpress and I would fit.
Long story short: We didn’t. And I suppose we won’t. While it is true that Wordpress is fine if you need something quickly, from all recent experience, Drupal is my favorite regarding security, constraints and maintainability. (Also, I can now use an existing Drupal multi-site cluster, which reduces efforts again.)
Last Thursday, our on-premises Confluence turned out to have died without announcement. No more responses, although the apache wrapper (local proxy) and also the shipped Tomcat itself still ran thoroughly. The log files, although excessively detailed, if not bloated (as with any contemporary Java application stack), did not tell too much, actually they said nothing that gave any hint.
The story of HTTP basic auth is actually quite funny. It is definitely the most mature, and probably the most often mistaken authorization, maybe even security approach I know to exist. At least in web terms.
At least in the 5.8.9 on-premises installation of Atlassian’s (otherwise quite handy) Wiki replacement, called Confluence, Windows Domain owners face an issue which at least I would locate somewhere between “strange”, “paranoid overkill” and “counterproductive nagging” although it is most likely but something they have imported with some Java SSL library.
As of Atlassian, setting a custom path for attachments in Jira is considered “a potential security risk”, and thus deprecated. This is not about arguing on whether admins without a sane idea of security concepts should be considered in on-premises application concepts at all (which I do not think, as you may guess). Instead, I will assume that you, like me, half-way know what you are doing and thus explain my workaround for this, as I figure, severe issue. (Honestly, just have virtualization clusters and SAN in mind.
For internal infrastructure tasks, we needed a simple, robust and reliable tool for dynamic DNS updates.
We were not aware of any DDNS provider completely meeting our requirements. Neither did various approaches out in the wild. Also we prefer processing sensitive data on premises anyway. In the end, I decided to refactor a set of legacy tools I once had quickly written (and which soon had become a “persistent interim” for some years).
For many years, I had run a site on Drupal 6. For some reasons, continuing was no option, as was migration (upgrading). By the way I have to thank Drupal 6 for, all in all, forgiving me more than one basic mistake (my first Drupal project ever) and serving pretty stable along some five years. Which is good. Despite this, I am happy that this performance hog now sleeps (almost) for good.
While Drush is a nice and handy CLI tool that especially eases shell and cron integration in advanced *X setups, Drupal’s so-called batch API was once designed to work around problems resulting from the lack of a full root access which was widespread standard with web hosting those days (and often still is).
This can become a problem once you want to build advanced environments with sophisticated workflows. Today’s example is (otherwise great) pathauto module.
When it comes to Twitter integration, you are likely to hit the corresponding module. While the module is actually fine and handily integrates a lot of Twitter’s API functions as well as OAuth 2.0 login to your Drupal site, it lacks well-thought support for a few important standard Drupal APIs, such as token or fields.