21–30 of 66 posts
Earlier quoted context omitted.
Re: caching, wp-supercache works pretty good too.
My only concern there is that `wp-supercache` is a plugin, so you're still having to spin up php and work through the WordPress core just to get to the point where you can serve the files out of that cache. It's likely better than no cache, but an external cache will be much more efficient under load.
The problem I have with wordpress - and any php project for that matter - is that I'm afraid of the code. I've done some template editing for WP and it already scarred me enough. But maybe I just prefer writing and working in my own familiar codebases instead of spending a small amount of time in that of others, a curse that a lot of PHP developers have (the "I'll write my own framework / cms" curse)
Consider though that when its template system was "invented" there wasn't much else available and people back then used to mix code and html all the time (both PHP and ASP developers). In their attempt to keep it backwards compatible we still have to suffer through the template system.
A few free safety and performance tips when dealing with wordpress: - Whitelist IPs for access to your wp_admin and wp_login. - If you have the skills to automate WordPress updates yourself, remove all write access (except for the uploads folder) from the user WordPress is running as (i.e. www-data). It's all just unzip and untar over the structure of the directory anyways. - If you remove write access, you might as…
May I add a very general tip for web servers? Mount /tmp on its own volume and set the noexec mount flag. I've seen too many old php apps fall due to files uploaded and executed from /tmp. Bulletin boards, blogs, but this was all 8 years ago.
nodev,noexec,nosuid
Years ago, like you, I saw an out-of-date web app get hit by an exploit but was "saved" because of some of those mount options.
I'm a big fan of SELinux on public-facing servers too (especially web servers, for the same reason), but that's an argument for another day.
More tips always welcome :)
I'm not sure if it's me, but when ever I see WordPress in a news article, the first association is always with 'Mass Hacks'...
It's a much safer platform these days... ...most of the sites with really important data have long since migrated away. Haha
Earlier quoted context omitted.
My only concern there is that `wp-supercache` is a plugin, so you're still having to spin up php and work through the WordPress core just to get to the point where you can serve the files out of that cache. It's likely better than no cache, but an external cache will be much more efficient under load.
It can use mod rewrite to avoid most of that.
What's the benefit over a straight use of mod_cache or mod_file_cache then?
Earlier quoted context omitted.
May I add a very general tip for web servers? Mount /tmp on its own volume and set the noexec mount flag. I've seen too many old php apps fall due to files uploaded and executed from /tmp. Bulletin boards, blogs, but this was all 8 years ago.
nodev,noexec,nosuid is how I've mounted /tmp (and several others) for going on two decades. I've never been a fan of installers creating a single partition by default and I wish they didn't do it. Years ago, like you, I saw an out-of-date web app get hit by an exploit but was "saved" because of some of those mount options. I'm a big fan of SELinux on public-facing servers too (especially web servers, for the same rea…
Edit: Also a big fan of SElinux, high five!
Then I had my first major vuln and spend my week-end fighting fires. Then I had my first encounter with encoding mess ups... an add-on going wild...
Fond memories...
And then the community management and plugin/theme ecosystem. For example, Drupal may have a more programmer-approved API, but (at least when I worked with it back in 2011) it was a hundred times more complex to make a custom content-editing form in Drupal than in WordPress. Again, product over technology.
Earlier quoted context omitted.
It can use mod rewrite to avoid most of that.
I see, write the static files down a directory and have Apache serve them. What's the benefit over a straight use of mod_cache or mod_file_cache then?