It seems like a no-brainer, but it isn’t included in WordPress.  A lot of things WordPress does, we take for granted, but there are basic things it doesn’t do that one wonders “why?!”

If you are a publishing blog (imagine that) and you have over 10 categories, you can easily get lost and waste a lot of time selecting the proper category for your post.  This adds up to wasted time for your and your publishing team.  After all, isn’t the website supposed to make life easier so all the professionals on your team, like content writers, can focus more on the high-quality content they write than waste time on an interface that doesn’t have a simple option to filter out the list easily?

I have seen workflows where there are over 300 categories for all the posts and writers, bloggers, and editors spend a lot of time scrolling this list.  Do you have this same issue?  Well, then this is a plug-in is just right for you!  Just go into WordPress to your Plugin manager and select “Add New” and search “Post Category Filter” by Javier Villanueva and install then activate it.

You will here a collective sigh of relief from your editors, bloggers, and writers.  You’ll look like a genius, all thanks to this nifty little timesaver.  To learn more, just visit the plug-in page at:  https://wordpress.org/plugins/admin-category-filter/

I have it installed on over 5 websites and have not encountered an issue with it.  A special thanks to Mr. Villanueva for publishing a great plug-in that saves so many people time, which also translates into saving companies money, doesn’t it?!


I’ve experimented a lot with different WordPress caching systems and would LOVE to hear from other developers who use WordPress what caching systems they recommend. Though it has its limitations, out of the box I have had the most luck and have seen the best improvements site wide with the least angst and issues with “WP Fastest Cache”.

It’s a fast and easy install that seems to work with a lot of different server flavors, unlike some other heavier and even higher rated and more downloaded caching plug-ins.  Some I’m sure are worth it, if you can get them to work, but I ran into all sorts of conflicts and troubleshooting and tracking down the issue could take hours, perhaps days.  Who has time for that?!  Just work already!

wp-fastest-cache-screenshot

In 5 minutes after installing this WordPress caching system, I saw faster page load times. I wish it could be even faster, but in this particular case, I am on a shared host so WP Fastest Cache is allowing me to hold off on needing to expand to a faster server by making my existing sites more economical.

Other caching plug-ins looked like they would work but ended up clashing with a theme or other plug-ins or started throwing 500 Server Errors, crashing the server with memory leaks, etc.  It was a nightmare on a VPS, caching works so much nicer on dedicated servers, so I’d suggest trying different solutions out.  Still, I can’t say enough good things about this particular one, it is well designed and works well with other plug-ins in the WordPress environment and I’ve deployed it on over 20 websites in the past year without an issue.

No, I am not a paid spokesman for that company, it’s just a well designed product and I hope your discovery of it will make YOUR life a little better!


If you just want to redirect an individual page, set the rewrite rules below by replacing “page1” with the page your want to redirect to, in this case it is “new-page1”. The “page1” on the left can be COMPLETELY DIFFERENT than the destination file, by the way!

Do you see the pattern? Notice the (.*) wildcard, which represents a section of the page URL that can contain any characters as long as it is AFTER “page1” and the “$1” at the end of the new destination URL is the correlating reference to this wildcard text which essentially just carries the contents of text within this wildcard to its new place in the new URL on the right. Confused yet?!



RewriteEngine On
RewriteRule ^page1(.*) http://%{SERVER_NAME}/new-page1$1 [R,L]



These are snippets for your .htaccess file, comments are after the # hash tags and explain what each snippet does.

Replace “yoursite.com” with your actual website, of course!


# www on all URLs.
RewriteCond %{HTTP_HOST} ^yoursite.com [NC]
RewriteRule ^(.*)$ http://www.yoursite.com/\ [L,R=301]
 
# Switch to HTTPS version of the site.
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
 
# Ensure all web addresses have a trailing slash.
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://www.yoursite.com/\/ [L,R=301]

The “L” in the square brackets tells the server if your rule is fulfilled with a match that is the “Last” directive to follow. The “R” stands for “Redirect” and allows you the option of defining what kind of redirect, typically, this is a 301 Permanent Move.


Be careful when editing and saving an “.htaccess” file on your site, it is very fickle and one small misspelling will throw a “Server 500 Error” which is never pleasant. You may be apprehensive to go online and use an “.htaccess password generator”, so here’s a way to make your server secure without going on a website that records your IP address and the username and password unencrypted. Doesn’t sound very safe. Though there is a tool available on this site to do just that, I can assure you we don’t record any input here, but that doesn’t mean someone else isn’t snooping during your session online, though.

So here’s a simple PHP snippet to generate the proper password. It is highly recommended that the “.htpasswd” file containing the username and password are stored OUTSIDE of your web root folder in a folder above so normal public visits and crawlers are more apt to have difficulty infiltrating and finding the proper file.

< ?php
// Password to be encrypted for a .htpasswd file
$straight_pwd= 'my password';

// Encrypt
$password = crypt($straight_pwd, base64_encode($straight_pwd));

echo $password;

?>

To set up any folder or your entire site with a log-in provides many benefits, one major benefit is that it locks down any development environment from outside snooping and search engine crawling. It also adds another level of security for sensitive areas of your website. So, each folder can have a different log-in, or the log-in requirement can be removed by customizing .htaccess wherever you need this unique security.


AuthType Basic
AuthName "Password Protected Area"
AuthUserFile /path/to/.htpasswd
Require valid-user

By the way, you don’t have to use the file name “.htpasswd”, as a matter of fact, you should use something that isn’t so common or obvious to help obfuscate where you are actually hiding the passwords to begin with. Also, don’t forget to include the settings in your .htaccess file to protect snoopers from being able to view your .htaccess file if this isn’t activated or default on your web host.

Usually in code the pipe, “|” stands for “”or”.

#Deny access to all files ending with .htaccess,.custom-private or .config

Order allow,deny