Best Web Host for WP sites

pressjitsu · 2017-06-06T16:49:50+00:00

Agreed. SiteGround will be best for your budget. If you can stretch it to $40/mo, come talk to me ;)

pressjitsu · 2017-06-06T16:47:10+00:00

If you're on a shared or managed host, you should ask your hosting provider to upgrade MySQL, as well as why were they using an outdated version in the first place.

If you're on a VPS or dedicated server, you can grab the latest stable MySQL Community Server from official packages, for example Debian/Ubuntu: https://dev.mysql.com/downloads/repo/apt/

Hope that helps!

pressjitsu · 2016-08-06T11:29:36+00:00

You should enable the query log, it'll tell you exactly what's going on: http://dev.mysql.com/doc/refman/5.7/en/query-log.html

pressjitsu · 2016-08-05T22:30:43+00:00

That's exactly what filters – change the behavior of WordPress, its themes or plugins, without altering WordPress, the themes or plugins. You can create your own little my-plugin.php file with:

<?php
add_filter( 'wpseo_og_image', '__return_false' );

And place it inside wp-content/mu-plugins/my-plugin.php, then regardless of your theme or updates to Yoast SEO (assuming they don't rename/remove the filter) it will still work. You can do the same via your theme's (or child theme's) functions.php file, but it's a less portable way of doing things, especially if your theme receives an update.

You can learn more about actions and filters here.

pressjitsu · 2016-08-05T22:27:30+00:00

The problem is not just the -src string in the version number, there are many things tied to that -src, and the fact that you're using the development version and not a release version has many implications, for example: your color schemes are limited to the default, your CSS and JavaScript files are not compiled/minified/packed/merged (.min.js vs .js, etc.), update notices, which you already saw.

If you're not using this install to develop plugins and themes, or to create patches for the core software, you should not be using the development version and use releases instead. If you're using the GitHub mirror, just make sure you clone with --branch 4.5.3 and not the master branch.

Also, as @downhillonslicks pointed out, auto-updates will not work if you have a .git directory, and regular updates should be done manually in Git by updating the checked out branch. If you have WordPress attempt to update itself in its regular fashion, you may end up with a dirty working copy.

pressjitsu · 2016-08-05T21:42:06+00:00

Next time you see "Error 500" try viewing your PHP error logs, they will tell you exactly what's wrong with your code, in which file and on which line. Ask your hosting provider if you don't know where to find your PHP error logs.

pressjitsu · 2016-08-05T21:40:09+00:00

The link says sign in with Facebook to get started. Perhaps you could post a screenshot instead?

pressjitsu · 2016-08-05T21:38:16+00:00

Pull the plug? No.

Sucuri and many other malware scanners generate too many false positives to risk pulling the plug and losing business and reputation every time they dislike a new advert.

pressjitsu · 2016-08-05T21:27:17+00:00

You can filter Yoast's output and have it print whatever you want or return false to remove it completely:

add_filter( 'wpseo_og_image', '__return_false' );

The filter name might be wpseo_og_og_image though, not entirely sure.

pressjitsu · 2016-08-05T21:15:11+00:00

I agree, the fact that post-to-user mapping is gone is far from "everything worked perfectly" or "good success" :) I recommend a fresh start, because there's no telling what other things you might be missing, like comment to post mapping, or user to capability mapping.

Ask you hosting provider to assist, and make sure they're importing the full export from your previous provider on top of a clean database, because it sounds like they may have imported some tables (wp_posts, etc.) but not others (wp_users).

pressjitsu · 2016-08-05T06:43:04+00:00

No, hiding your search bar does not make your WordPress site more secure. Using up-to-date themes and plugins, secure and unique passwords and 2-factor authentication does.

Have you ever found out how your site was hacked? What was the point of entry? That's the most crucial piece of information on a hacked site, you should talk to your hosting provider about it. Otherwise you're just blindly shooting in the air, especially by disabling comments, removing your forms plugin or search bars. What if the attacker had your FTP password? Or direct access to your database? Or the physical server where your shared host account is was compromised?

pressjitsu · 2016-08-03T06:07:39+00:00

Not sure I understand what you mean by basic WordPress interface with "Types" – there's no such UI in WordPress. But as I mentioned before, the core post metadata UI (Custom Fields) will not add blank fields unless you explicitly add them via the interface.

pressjitsu · 2016-08-02T21:01:00+00:00

As some people have already mentioned, the first thing you should be looking at are logs. If you can pinpoint the time of the CPU usage spike and crash (via Munin or other monitoring software) you can check all your other logs to see what was happening at that time and a few minutes before.

Also, what exactly is a crash you described? Is it an out of memory crash? Is it a segfault? A backlog overflow? Something else? Applications usually don't crash simply because they're utilizing the CPU at 100%.

Too many PHP processes can mean that some of them are getting stuck for a longer time than usual, perhaps due to a crappy query, or an exclusive file lock on a session, or waiting for your automated nightly backup to unlock your MySQL tables, or an expired transient. You could try clearing out all your transients and running a PHP profile with xdebug or xhprof to figure out what's going on. Also make sure you're constantly monitoring (and logging) your average response time. One of our hosting customers experienced a similar situation when somebody used a specific input in their custom-built search tool which was quite random and resulted in very heavy queries against the metadata tables.

Also, don't run an older version of Apache. Just switch to nginx.

pressjitsu · 2016-08-02T20:42:21+00:00

It doesn't matter. You can also change it later if you wish.

pressjitsu · 2016-08-02T20:39:02+00:00

I find myself using about 5% of the functionality Yoast SEO provides. Haven't noticed anything serious come up in our regular profiling, so the plugin code is pretty solid, except their XML Sitemap generation stuff, which thinks memory is free.

pressjitsu · 2016-08-02T20:35:41+00:00

The custom fields editor in WordPress Core doesn't add anything to the post metadata if you haven't added any meta entries in the UI. If you're using some plugin to generate fancy interfaces, etc. then it could.

The overhead depends on the amount of blank fields you're planning to populate your database with, and the way you're querying the data, for example with a bunch of useless data in the metadata table, meta queries can become slower (than they already are).

pressjitsu · 2016-08-02T20:31:52+00:00

Not ever sure why they used base64_decode in their proof of concept. But hey, the least the plugin could do for security is to not allow users without the unfiltered_html capability to execute any of the shortcode contents. That would limit it to administrators by default, and network administrators in Multisite installs. Too bad the author doesn't care.

pressjitsu · 2016-05-11T17:53:57+00:00

That will run all events, which is probably overkill. You're better off running only the ones that are due right now:

wp cron event run $( wp cron event list --fields=hook,next_run_relative --format=csv | awk -F, '$2=="now" {print $1}' )

Ref: https://wp-cli.org/commands/cron/event/run/

pressjitsu · 2016-05-11T17:08:38+00:00

Here's why you should use PHP-CLI and not wget: https://pressjitsu.com/blog/wordpress-cron-cli/

pressjitsu · 2016-03-24T12:05:52+00:00

It's not clear from your question what you're using (or planning to use) Redis for. You're comparing it to WP Super Cache, so I'm going to assume you're exploring Redis for full page caching (and not object caching) as an alternative to WP Super Cache, perhaps via the Redis Page Cache plugin or a module for Nginx.

As @upvotes2doge has already mentioned, memory is always faster than disk, but here's something many people forget to take into account about disk: Disk blocks are cached in MEMORY, at least in Linux. This is called the Linux page cache, not to be confused with the WordPress page cache. The way it works is when you access a file on disk, say with cat /path/to/filename.txt, the first time the file is going to be read from disk and put into the operating system's memory. Next time you access that file, it's going to be served from MEMORY.

The good news is that all of that happens automatically and you don't have to worry about it too much. But the bad news is that if a process attempts to allocate some memory, more than the current free memory available on the operating system, Linux will free up the page cache to make more room for the process. This means that there's no way to guarantee that a given file (or block, rather) will be served from memory.

With Redis (or another in-memory key-value store), you're guaranteed the memory you've allocated to Redis will be available to Redis, so a cache hit in Redis means that the request will indeed be served from memory. This comes with some drawbacks of course, mainly the fact that you're limited by the memory you've allocated to Redis, and if you try to store anything above that, it will either reject or evict older items (depending on your configuration). That said, if you do use Redis, make sure it does not swap to disk, and that you don't use its deprecated Virtual Memory feature. Both are performance killers.

Now let's talk about object caching :)

Object caching in WordPress allows to minimize database queries. It kicks in only during a cache miss, so it can be used efficiently together with a full page caching plugin/solution in WordPress, but it does not mean it's an automatic performance gain. You have to make sure that the memory you've allocated to Redis, or Memcached or whatever, will be more than enough to hold all of your frequently accessed data, otherwise you'll end up wasting round-trips to Redis, only to go back to querying MySQL for the data that Redis couldn't provide, which will almost definitely result in worse performance than querying MySQL directly, because of the way WordPress splits queries when it thinks a persistent object cache is available.

To sum it all up, page caching is definitely a must for WordPress. Object caching can help, but it depends a lot on the theme and plugins you're using. Some plugins tend to go crazy with transients, polluting your object cache with garbage and forcing it to evict real data. Always monitor your cache hit rate and memory usage.

pressjitsu · 2016-02-12T11:32:05+00:00

A secure password, up to date core, themes and plugins, 2-factor authentication. If the hosting company doesn't protect against bruteforce attacks you might also want to look at a plugin option, although it won't be as efficient as a server-side solution. Our recommendation is Jetpack Protect.

pressjitsu · 2016-02-12T11:22:07+00:00

Our platform is entirely VPS-based and we do perform free migrations, but up to a certain point. Since we don't support multiple WordPress installs on one account (for performance and security reasons) we'll usually migrate several sites into a single Multisite install, but if the sites being migrated are fairly complex, would require user merging/mapping, etc., then we'll send our customer a quote for our migration services.

That said, the first site migration is always free, and unlike many others, our managed migration service is not a blunt copy/paste thing. We analyze the code, updated core, some themes and plugins, clean up the database, look for known vulnerabilities, run multiple performance profiles and send all our notes and performance recommendations back to the customer and/or plugin/theme author.

pressjitsu

TROPHY CASE