Advantages of Headless Drupal + Static FrontĮventually I decided that I want to have a static front - running on a static engine, and the outputs of it can be hosted for free - either on some CDN, Github’s static pages, Netlify or even Amazon’s S3 Bucket. Also I don’t want to constantly run updates locally and then deploy those (that’s why I got hacked in first place).Īlso, other than CMS’s vulnerabilities, there are also PHP’s vulnerabilities, Apache/Nginx’s vulnerabilities, ssh vulnerabilities - so you’d have to update the operating system itself and all the packages, then restart nginx, php-fpm, mysql and hope for the best. However, to me, these options are way overkill - I don’t want to pay extra for Pantheon, nor I want to write a CircleCI (or Github Actions) script or a crontab + shell script. Normally you want to test things first on your local environment and then replicate things on production. something simpler but riskier would be - to have a cronjob that just runs updates directly on production - but you never know what will happen.
have proper Core Updates and Contributed Module Updates, maybe even run tests and if all goes well to deploy to production.
use a CI tool, like CircleCI or Github Actions - you can have regular tasks that run daily, i.e.
use something like Pantheon - it comes with automatic core updates, however this still leaves room for contributed modules or plugins if you’re using Wordpress, which can also act as an attack vector.In modern days, there are ways one can automate this process, in example:
0 kommentar(er)
