Loading...

Follow Digging Into WordPress | Take your WordPress sk.. on Feedspot

Continue with Google
Continue with Facebook
or

Valid

It's been a BUSY year! So far most of my work is focusing on WordPress plugins. Recently announced Disable Gutenberg and Gutenberg Custom Fields plugins. And now I am pleased to announce 5 more plugins designed to improve your WordPress workflow: Disable Responsive Images, Disable WP REST API, Enable Database Tools, WP Cron HTTP Auth, and the BEST for last: Contact Form X. Please check ‘em out, and THANKS for your generous attention.

Direct link to article | View post at DigWP.com

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Gutenberg soon will be added to the WordPress core. This is great news for some, not so great for others. With 99.9999% (estimate) of all WordPress sites currently setup to work without Gutenberg, the massive changes barreling down the pike are going to affect literally millions of websites. And as swell as the whole "Gutenberg" experience may seem, the simple truth is that a vast majority of site owners will not be prepared when it finally hits. Nor will many small business have time or budget to test and update client sites to accommodate ol’ Gut’.

Note! To help save time, I may refer to Gutenberg as G7G or g7g throughout this article (e.g., in code snippets). Just faster than typing it all out :)
*You* have the power..

If that sounds like your situation, you basically have two options:

  1. Buck up and fork out your time and money to test and update all existing client sites for Gutenberg.
  2. OR, simply disable Gutenberg until you are ready for it.

From the WP peeps I've heard from, only a handful are full on-board ready to sacrifice whatever amount of time and money it takes to implement and support Gutenberg. Most folks I've heard from, however, are confused and/or just plain unaware of the huge changes in store for them and their WordPress-powered sites. Let alone have the resources to retroactively implement G7G support.

So for folks in that second camp, where it's just not feasible to immediately drop everything and re-learn how to develop with WordPress using JavaScript, this post explains numerous ways to disable Gutenberg, including disabling Gutenberg via plugin, and then also a bunch of methods to disable Gutenberg programmatically, just FYI.

Disable Gutenberg via Plugin

The easiest way to disable Gutenberg is to install my free plugin, Disable Gutenberg. It is a simple plugin focused on one thing: disabling Gutenberg and restoring the default classic WP Editor screen. Just enable the plugin, choose your options and done. Options include:

  • Disable Gutenberg completely (all post types)
  • Disable Gutenberg only on specific post types
  • Disable Gutenberg for specific user roles

So it's flexible yet simple, and super easy to use. Check out the documentation for more details.

Disable Gutenberg via Code

Fortunately, there are numerous ways to disable Gutenberg programmatically. Let's look at each of them.

Disable Gutenberg Completely

To completely disable Gutenberg (aka G7G), add the following line via functions.php or custom plugin:

add_filter('gutenberg_can_edit_post_type', '__return_false');

That's the recommended way of disabling Gutenberg. It simply returns a value of false to Gutenberg's gutenberg_can_edit_post_type filter, which then disables G7G for all post types (i.e., completely). To disable only on specific post types, check out the next technique.

Disable Gutenberg for Custom Post Types

The Gutenberg editor is active only on WP posts where it is enabled. By default, this includes WP Posts and Pages. Other posts types can be disabled using the same filter, gutenberg_can_edit_post_type. For example:

function digwp_disable_gutenberg($is_enabled, $post_type) {
	
	if ($post_type === 'book') return false; // change book to your post type
	
	return $is_enabled;
	
}
add_filter('gutenberg_can_edit_post_type', 'digwp_disable_gutenberg');

Here we are disabling Gutenberg only for the book post type. So it will only affect books and no other post types. To disable for a different post type, replace book with the name of your post type.

Disable when registering post types

It's also possible to disable G7G when registering your Custom Post Types. This method only makes sense for CPTs that do not make use of the post editor, as it basically disables the editor panel entirely. To do so, simply omit editor from the supports parameter when registering your post type. Here is an example:

$args = array(
	'label'    => __('Books'),
	'labels'   => $labels,
	'supports' => array(
		'author',
		'custom-fields',
		// 'editor', // <-- do not add this param
		'title',
		'thumbnail'
	),
	'has_archive' => false,
	'hierarchical' => false
);
register_post_type('books', $args);

Because we excluded the editor parameter, the books post type will not include the post editor, and thus will not include any Gutenberg stuff.

Disable when registering post types (via REST API)

Another way to disable Gutenberg when registering custom post types is to disable REST for your post type. This can be done by setting the show_in_rest parameter to false, for example:

$args = array(
	'label'        => __('Books'),
	'labels'       => $labels,
	'show_in_rest' => false, // set to false to disable G7G
	'supports'     => array(
		'author',
		'custom-fields',
		'editor', // works even when editor is supported
		'title',
		'thumbnail'
	),
	'has_archive' => false,
	'hierarchical' => false
);
register_post_type('books', $args);

So even if your post type supports the post editor, it's still possible to disable Gutenberg by disabling the REST API, because Gutenberg requires the REST API in order to work.

For more information about registering post types, check the WP Codex.

Disable Gutenberg for Meta Boxes

Some of my plugins make heavy use of meta boxes, and it's gonna require significant time to rework everything. Fortunately, there is a way to disable the Gutenberg editor on any screens that make use of your meta box:

__block_editor_compatible_meta_box

We can pass that as an argument when adding the meta box, for example:

add_meta_box('metabox_id', 'Metabox Title', 'metabox_callback', null, 'advanced', 'default', array('__block_editor_compatible_meta_box' => false));

Notice in the seventh parameter, $callback_args, we are passing the __block_editor_compatible_meta_box argument as an array item. For more details about adding meta boxes, visit the WP Codex.

The "old" way..

This method is not recommended, but worth mentioning as it sheds light on what's possible. Simply add the following line to your site's wp-config.php file, just before the line that says, "That's all, stop editing":

$_GET['classic-editor'] = true;

After doing this, Gutenberg will be disabled and the Classic Editor screen enabled on all "Edit" screens. But again, this is an older way of disabling Gutenberg. Please use one of the previous methods instead.

Note about Custom Fields

If you are working with Custom Fields and the Gutenberg editor, you will notice that the "Custom Fields" meta box is not displayed on G7G screens by default.

To help with this, I wrote a plugin that restores display of the Custom Fields meta box: Custom Fields for Gutenberg. A lot of my plugins use custom fields, so this plugin ensures that users will be able to see them on Gutenberg-enabled screens. Thank you, me! :)

Bonus!

The above solution is straightforward enough, however you may want to go a bit further and hide the "Try Gutenberg" nag across admin screens. To do so, you can install the Dismiss Gutenberg Nag plugin.

Disclaimer

Gutenberg technology is constantly changing. So be sure to test the above code methods with the latest version of WP/G7G before implementing on a live site. And of course, the Disable Gutenberg plugin will be kept up-to-date and always current with latest G7G functionality. Cheers people.


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Gutenberg is coming soon to your WordPress, whether you like it or not. Debate and drama aside, it's time that we start looking for practical ways to adapt current WordPress sites to the many imminent changes brought to us by G7G. One of these changes involves Custom Fields. Currently, and hopefully this will change in a future update, Custom Fields are not displayed on Gutenberg-enabled screens. Which is kind of a bummer, considering the millions of websites, plugins, and themes that make good use of them.

So to help out with this, I've written a simple plugin that brings back the Custom Fields meta box, so that your custom fields are displayed on WP Posts, Pages, and any capable Custom Post Type.

What it does

Currently, Custom Fields for Gutenberg does one thing and does it well: displays the Custom Fields meta box on any Gutenberg-enabled screen. Just activate and done. The plugin also includes some default options to disable custom-field display on any particular post type(s). And you can specify any custom fields that should not be included in the Custom Fields meta box. Plus some other options to fine-tune how the custom fields are displayed.

Features
  • Easy to use
  • Clean code
  • Built with the WordPress API
  • Lightweight, fast and flexible
  • Works great with other WordPress plugins
  • Plugin options configurable via settings screen
  • Focused on flexibility, performance, and security
  • One-click restore plugin default options
  • Translation ready
Options
  • Specify the post types that should display custom fields
  • Exclude custom fields that are protected/hidden
  • Exclude custom fields with empty values
  • Exclude specific custom fields by name
Download

Learn more, check out screenshots, and download for FREE at the WP Plugin Directory: Custom Fields for Gutenberg »


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

I've been working on updating my collection of WordPress plugins for the imminent Gutenberg update. So far it has not required much time to learn, and the API is straightforward. It will however take significantly longer to integrate Gutenberg support into 20+ plugins. To help keep things organized, I will be posting tips and snippets here at DigWP.com. Blocks are the foundation of all things Gutenberg, so this first post is all about block recipes. Some of these code snippets are far less useful than others, hopefully they will be useful to others.

Note! To help save time, I refer to Gutenberg as G7G or g7g throughout this article (e.g., in code snippets).

Basic block with style

Displays a static block with some padding and basic styles. Includes i18n support.

const { __ } = window.wp.i18n;
var el = wp.element.createElement,
	registerBlockType = wp.blocks.registerBlockType,
    blockStyle = { backgroundColor: 'red', color: 'white', padding: '20px' };

registerBlockType('g7g-blocks/block-01', {
	title: __('Pancakes'),
	icon: 'universal-access-alt',
	category: 'common',
	edit: function() {
		return el('p', { style: blockStyle }, __('For Breakfast'));
	},
	save: function() {
		return el('p', { style: blockStyle }, __('For Dinner'));
	},
});
Block to add inline style

This dynamic block accepts CSS styles and displays them inline on the frontend. Includes i18n support.

const { __ } = window.wp.i18n;

var el = wp.element.createElement,
	registerBlockType = wp.blocks.registerBlockType,
	Editable          = wp.blocks.Editable,
	createBlock       = wp.blocks.createBlock;

registerBlockType('g7g-blocks/block-02', {
	title: __('Style'),
	icon: 'art',
	category: 'formatting',
	keywords: ['css', 'inline', 'style'],
	attributes: {
		content: {
			source: 'text',
			selector: '.wp-block-g7g-blocks-block-02',
		},
	},
	supports: {
		html: !1,
		customClassName: !1,
	},
	edit: function(props) {
		var content = props.attributes.content;
		function onChangeContent(style) {
			props.setAttributes({
				content: style.target.value
			})
		}
		return el('textarea', {
			className: props.className,
			onChange: onChangeContent,
			value: content,
			placeholder: __('Add style (do not include <style> tags)')
		})
	},
	save: function(props) {
		var content = props.attributes.content;
		return el('style', {
			dangerouslySetInnerHTML: {
				__html: content
			}
		})
	}
});

Along with that, I used the following CSS:

.wp-block-g7g-blocks-block-02 { width: 100%; height: 200px; }
Block to display notes

This block displays a note on the frontend. Includes i18n support.

const { __ } = window.wp.i18n;

var el = wp.element.createElement,
	registerBlockType = wp.blocks.registerBlockType;

registerBlockType('g7g-blocks/block-03', {
	title: __('Note Block'),
	icon: 'admin-post',
	category: 'common',
	attributes: {
		type: {
			type: 'string',
			default: 'important',
		},
		message: {
			type: 'string',
			source: 'html',
		},
	},
	edit: function(props) {
		var className = props.className;
		var type = props.attributes.type;
		var message = props.attributes.message;
		function updateMessage(event) {
			props.setAttributes({ message: event.target.value });
		}
		return el('p', {
			className: className +' note-'+ type 
		}, 
		el('textarea', { 
			value: message, 
			onChange: updateMessage 
		}));
	},
	save: function(props) {
		var type = props.attributes.type;
		var message = props.attributes.message;
		return el('p', { 
			className: 'note-' + type 
		}, message);
	},
});

Also applied these styles:

.wp-block-g7g-blocks-block-03 textarea { width: 100%; height: 200px; }
.wp-block-g7g-blocks-block-03.note-important { color: red; }
Block to display latest post

This block displays the latest post. Modified to include i18n support and other tweaks.

const { __ } = window.wp.i18n;

var el = wp.element.createElement,
	registerBlockType = wp.blocks.registerBlockType,
	withAPIData = wp.components.withAPIData;

registerBlockType('g7g-blocks/block-04', {
	title:    __('Latest Post'),
	icon:     'megaphone',
	category: 'widgets',
	
	edit: withAPIData(function() {
		return {
			posts: '/wp/v2/posts?per_page=1'
		};
	})(function(props) {
		if (!props.posts.data) {
			return __('Loading...');
		}
		if (props.posts.data.length === 0) {
			return __('No posts.');
		}
		var className = props.className;
		var post = props.posts.data[0];
		
		return el('a', { 
			className: className, 
			href: post.link 
		}, post.title.rendered);
	}),
	
	save: function() {
		// render via PHP
		return null;
	},
});

Notice near the end of the block code, where it says, "render via PHP"? That's where this next snippet comes into play. Add this code to via plugin or theme functions.php:

function g7g_render_block_latest_post($attribites) {
	
	$recent_posts = wp_get_recent_posts(array('numberposts' => 1, 'post_status' => 'publish'));
	
	if (count($recent_posts) === 0) return __('No posts');
	
	$post = $recent_posts[0];
	$post_id = $post['ID'];
	
	return sprintf(
		'<a  href="%1$s">%2$s</a>',
		esc_url(get_permalink($post_id)),
		esc_html(get_the_title($post_id))
	);
	
}

function g7g_load_blocks() {
	
	register_block_type('g7g-blocks/block-04', array('render_callback' => 'g7g_render_block_latest_post'));
	
}
add_action('init', 'g7g_load_blocks');

Note that last function, g7g_load_blocks() is a workaround for the error: "PHP Fatal error: Uncaught Error: Call to undefined function register_block_type". So at some point whenever that is fixed, we can just call register_block_type() directly without the workaround.

Block that uses rich-text field

This block displays a Rich Text Editor, so the user can include HTML content along with any text. I.e., formatted text. Includes i18n support.

const { __ } = window.wp.i18n;

var el = wp.element.createElement,
	registerBlockType = wp.blocks.registerBlockType,
	RichText = wp.blocks.RichText;
	
registerBlockType('g7g-blocks/block-05', {
	title: __('Message'),
	icon: 'universal-access-alt',
	category: 'common',
	attributes: {
		content: {
			type: 'array',
			source: 'children',
			selector: 'p',
		}
	},
	edit: function(props) {
		var content = props.attributes.content;
		function onChangeContent(newContent) {
			props.setAttributes({ content: newContent });
		}
		return el(RichText, {
				tagName: 'p',
				className: props.className,
				onChange: onChangeContent,
				value: content,
				isSelected: props.isSelected,
			}
		);
	},
	save: function(props) {
		return el('p', { 
			className: props.className 
			}, props.attributes.content
		);
	},
});

Also added the following bit of CSS:

.wp-block-g7g-blocks-block-05 textarea { width: 100%; height: 200px; }
Blocks, Blocks, Blocks

More Gutenberg blocks on the way.. in fact, in about a month or two, the Web literally will be drowning in Gutenberg block tutorials. I absolutely 1000% guarantee it ;)


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Announcing my latest WordPress security plugin, Banhammer! It makes monitoring site traffic and banning unwanted guests waay too much fun. Navigate logged requests via slick Ajax UI, and enable sound effects for banning and warning bad users and bots. Check out the video on YouTube and download Banhammer from the WP Plugin Directory.

Direct link to article | View post at DigWP.com

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

There has been lots of discussion about the new WordPress "Gutenberg" project. Some people love it, some hate it, and most WP users probably have no idea about it. And that's too bad, because it means many changes will be required for thousands of WordPress plugins and themes. We're talking about MANY collective work hours to make it happen, even in a best-case rollout scenario.

The debate

Anyone who is in any of the Facebook WordPress groups knows about the debate over Gutenberg. Also on Twitter and other social media channels. For those who may be unfamiliar with the drama, you can get a good idea by browsing through the Plugin Reviews for Gutenberg. Currently, it looks like Gutenberg fans are outnumbered by about 2 to 1:

Should this plugin be added to the WP core? Do plugin ratings mean anything?
My take

So this post is to ask what your thoughts are, and to share my own opinion, which can be summed up quite succinctly:

Leave Gutenberg as a plugin.

Why? Because there is no real need to add Gutenberg to core. But there are many good reasons for NOT adding to core and leaving Gutenberg as a plugin:

  • There are better content-building plugins available
  • Lets users decide if a visual content builder is necessary
  • Lets users decide which content builder is best for their needs
  • Doesn't break thousands of WordPress sites, plugins, and themes
  • Doesn't push countless hours of needless work onto developers & users
  • Enables Gutenberg fans to use the functionality without forcing it on everyone else (win-win)

Basically, Gutenberg should take advantage of WP's great extensibility and let users decide for themselves. That's exactly what plugins are for; in fact, thanks to the extensibility of WordPress, users already enjoy a wide variety of incredible content-building plugins. Leaving Gutenberg as a plugin means that everyone wins :)

My advice

IF they absolutely are dead set on forcing Gutenberg into core no matter what the cost, then I recommend the following four golden rules:

  1. Make Gutenberg optional
  2. Don't remove metaboxes
  3. Don't remove custom fields
  4. Don't remove the plain-text editor

Basically, replace the RTE if you think it needs it; but don't mess with existing functionality. Waaay too much is built on it. Don't force more needless work on millions of WordPress developers and users. No feature is worth such massive potential disruption for so many people. Talking high stakes here, folks.

Your thoughts?

What do YOU think about Gutenberg? Do you think it should be added into the WP core, or left as a plugin? Or abandoned altogether in favor of something better? Share your thoughts (but be nice!) in the comments below.

Update

It looks like they're dead set on forcing Gutenberg into core. They recently sent out a lengthy "4.9 update" email trying to explain and justify their plans, for example:

The first iteration of Gutenberg introduces a new editor design featuring content blocks that can be directly manipulated. Even though the initial version aims to replace only the writing screen, future iterations planned for next year go into page templates and, ultimately, full site customization.

LOL! As if all of that hasn't been possible for years now, using one of the many great drag-n-drop, content-building plugins. Like installing a plugin is too much to ask of WP users? It takes like what, a few clicks..?

Also..

Despite what the Gutenberg devs and others have been saying, it sounds like they DO plan on removing custom fields, meta boxes, and shortcodes entirely, as suggested by this statement (also from the 4.9-update email):

[Gutenberg is] a big change, and various paths will support existing WordPress functionality (such as shortcodes or meta-boxes) to help their transition.

I don't know about you, but to me, that sounds like they are saying that shortcodes and meta boxes eventually will be removed. Which is the opposite of what many of us have been told by team Gutenberg. The ol’ bait & switch..

Even more telling is the fact that the 4.9 update email does not link to the Gutenberg plugin page (you know, the one with mostly bad reviews).. instead they link to the new Gutenberg documentation, so it's all good. You can marvel at the "greatness" of it all:

https://wordpress.org/gutenberg/

As if the entire community is pulling together to make it happen. It feels more like WordPress is being hijacked by a few overzealous developers, for whom 25% market share just isn't "enough". Gotta completely reinvent the wheel and "fix" something that works perfectly fine for millions of users.

More to come..

I'll continue to update this post with more news as it becomes available. Currently it sounds a lot like shenanigans and crafty maneuvering, especially with the apparent back-peddling on promises made regarding meta boxes, custom fields, shortcodes, which thousands upon thousands of WordPress plugins make use of.

And if you think it's not happening, or won't affect you, here is another gem from the 4.9 update email:

When will Gutenberg be in core? The plan is to release Gutenberg in WordPress 5.0 early next year, so now is a great time to test and get ready for it.

This ominous warning is then followed by an invitation to help, along with a link to the Gutenberg Github page.


Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

On certain server setups, WordPress is vulnerable to an email interception attack. Basically WP uses the $_SERVER['SERVER_NAME'] variable for the "From" header in email notifications. On certain systems this can be exploited by an attacker to gain access to your site. This issue has been known about since WP 2.3, but nothing has been done about it. So I decided to write a plugin to fix it up.

Direct link to article | View post at DigWP.com

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

With each passing day, strong security becomes more important. This article explains some ways to keep WordPress secure while improving the overall security of your WordPress-powered site. Most of the tips provided here are practice-based security steps that require no plugins or hacks. The idea here is that you don't need to make changes to any code, or modify WordPress in any way in order to maintain strong security. These are security steps that most any WordPress user can use to help protect their site and keep WordPress safe and secure.

Table of Contents Introduction

The motivation for this article is the idea that WordPress itself is secure. When vulnerabilities are discovered, the WordPress team fixes them up and pushes out a new version asap. In my experience, most security issues are introduced by external factors, such as user inexperience, insecure servers, and badly coded 3rd-party plugins and themes. Much of the advice given in this article is aimed at reducing risk by controlling these and other external factors.

Keep in mind that security is not a set-it-and-forget it kind of thing. There is no such thing as a perfectly secured site. If your site is online, there is risk. Thus, good security is not about trying to eliminate risk, but rather results from reducing risk as much as possible. As stated in the WordPress Codex1:

Fundamentally, security is not about perfectly secure systems. Such a thing might well be impractical, or impossible to find and/or maintain.

Risk elimination is not a one-size-fits-all, click-a-button-and-done type of affair. Rather, risk reduction happens in layers. Everything counts. From server software to form validation and everything in between, every layer of protection works together toward a site's overall level of security.

So with that in mind, here are some tips that will help you to keep your WordPress-powered site as secure as possible. And for even more security tips, check out the security guide over at makeawebsitehub.com.

Do Nothing

If you're running WordPress on a well-secured server, and you are 100% sure about any themes and plugins that you're using, then you're pretty much good to go security-wise. I have sites hosted on VPS servers for which I take zero additional security steps outside of common best practices.

But good security also depends on how you're using WordPress, which is what most of this article is about.

Use SFTP not FTP

If you're still using regular ’ol FTP, you should switch to SFTP as soon as possible. In a nutshell, FTP sends your credentials and data in clear text, which means your password and connection information is not encrypted2. If you are transferring your files via FTP, anyone listening on the network can grab your data and use it to exploit your site. Using SFTP is just like using FTP, but with SFTP all of your credentials and data are encrypted, which protects them from would-be attackers.

Ask your web host if you are unsure about SFTP support — they should be more than happy to help. Likewise with your current FTP setup, check the documentation to see how to change things over to use SFTP as your file-transfer protocol.

Use SSL/HTTPS

This is the same basic idea as using SFTP instead of FTP. If your site is using the HTTP protocol, all transmitted information is sent without encryption. So all comments, logins, purchases, and other transactions are sent and received unencrypted over the network.

This means that an attacker could intercept passwords and other sensitive data in order to exploit your site and its users. This is one reason why Google and other big players are pushing hard for everyone to switch over to HTTPS. With HTTPS, all transmitted data is encrypted, which helps to protect against interception and exploitation.

Of course, switching from HTTP to HTTPS requires more effort than switching from FTP to SFTP. To set up HTTPS for your site, you need an SSL certificate, which must be implemented properly on your server (which can be easier said than done). If you do decide to upgrade to SSL/HTTPS, make sure to do so for all pages on your site, otherwise known as "always-on" SSL.

For help making the transition, check out Chris Coyier's write up over at CSS-Tricks. After implementing SSL, test your pages for proper functionality and security using an online SSL checker.

Secure Hosting

Perhaps the most important of all security tips is to host your sites on a secure server. The server is the foundation of your website, so make sure that your web host is reputable and provides stable, secure servers.

Especially with web hosting, you get what you pay for, so avoid "cheap" hosting at all costs. If you can afford it, get anything better than "shared" hosting. Shared hosting means that you are sharing the server space with other users. So if another site on the server is hacked, then all sites on the server may be compromised. Like living in a bad part of town.

Contrast that scenario with dedicated hosting, where the entire server is dedicated to your sites. That enables you to be as secure as you want to be, without worrying about what your neighbors are doing (or not doing). Likewise with VPS hosting, the security of your sites is not dependent on the security of your neighbors.

Some things to look for in a good web host:

  • Solid reputation as secure, reliable, supportive, responsive, etc.
  • Provides a properly configured server
  • Provides current versions of software (Apache/Nginx, PHP, MySQL, etc.)
  • Provides reliable methods for backing up and restoring your data
  • Happy to discuss all details regarding service, security, features, et al

Unfortunately finding a good web host these days is easier said than done, but it is of critical importance nonetheless. Taking the time to do your own research and find the best possible web host is one of the best security investments that you can make for your site.

Strong Passwords

Everyone on the Web should be using strong passwords. Unfortunately, there are many folks who have yet discover the joys of getting hacked. Seriously, people. Tell your friends. Spread the word. Strong passwords are mission-critical. You've got to use strong passwords and change them regularly.

One of my pastimes is watching network traffic. One thing I see more of every day is brute-force hacking attempts. And 99% of it is aimed right at your site's login page. They want in. They want to exploit your site. Fortunately it's trivial to deny them access: use ultra-strong passwords for everything. That includes not only your WordPress password, but also credentials for things like email, database connections, SFTP, and anything else that requires authentication. As stated in the WP Codex1:

Hackers thrive on predictability. They predict that many peoples passwords are in fact ‘password’, or that their username is probably their real name or some default value such as ‘admin’. Be unpredictable.

As a complete bonus, WordPress now features a built-in password-strength meter on every user's Profile screen. This makes strong passwords a no-brainer for all of your users. Here are some additional tips for rocking strong passwords:

  • Keep it long, random, and alphanumeric
  • Never share your password with anyone
  • If you do let others use your passwords for tech support or whatever, change the passwords afterward
  • Use an online password generator to generate strong passwords

And if you want to super-secure the WordPress login page, you can implement two-factor authentication.

Stay Current

This also should be drilled into everyone's skull at this point: stay current with the latest version of WordPress. Doing so is made dead-simple, with features like one-click and auto-updates — there really is no excuse for lagging behind on the updates. This goes not only for the WordPress core files, but also for all plugins and themes that are installed on your site (whether active or not, it's always best practice to keep ’em updated).

In addition to keeping all of the software up-to-date, it's wise to keep an eye on the latest WP development news for important heads up on general security, zero-day threats, and other breaking issues.

Clean Up Rogue Files

Good security involves limiting liability as much as possible. Keeping loose, unused files on your server unnecessarily increases the liability of your site. Take a few moments to examine your directory structure and remove any files that are not required. To give you a better idea, you should remove things like:

  • Development-only files (like for testing, version control, etc.)
  • Unused (inactive) themes
  • Unused (inactive) plugins
  • Unused PHP scripts
  • Unused JavaScript files
  • Sensitive information and/or notes
  • Any other loose files that are not required

If you must keep such files on the server, you should protect them against unwanted access. Here are two alternate .htaccess techniques for securing any file on the server:

via mod_rewrite

RewriteRule /filename\.ext - [F,L]

via mod_alias

RedirectMatch 403 /filename\.ext

To use either of these techniques, change the filename to match the name of your file, and ext to match the file extension. Then add to your site's root .htaccess file and upload to your server. Test by requesting the file in your browser. Using either method should return a “403 - Forbidden” error.

Keep Good Backups

This is another no-brainer for most people, but there are some who have yet to suffer catastrophic data-loss and learn the lesson on their own. Keeping good backups of your site is essential to avoid losing critical data and getting back up to speed if and when something bad happens. And there is a lot of bad that can happen these days. Having a current set of tested, working backups enables you to get back on track without losing any precious data. And always keep multiple copies of your backup files. Remember, good backups are:

  • Kept secure
  • Well-tested
  • Current

Further, understand that you need to back up not just your database, but your files as well. Basically you need to keep backups that will enable you to reconstruct your entire site to its current state at a moments notice. If that sounds like you, then you're good to go in this department. If not, then you may want to check out some of the useful backup plugins available in the WordPress Plugin Directory.

Stick with Trusted Sources

This one’s easy. Install only reputable themes and plugins from trusted sources, and stay away from "shared" or "pirated" versions of themes and plugins. It's just too easy for evildoers to slip bad code into their pirated warez. Sure, on the surface everything may look fine, and the plugin or theme may otherwise function normally. But beneath the hood, malicious code can do bad things without your knowledge. Don't be a victim. Always get your plugins, themes, and scripts from trusted sources.

Use Quality Plugins

As discussed in our recent poll, it's not so much the number of plugins as it is the quality of plugins that you run on your site. When looking for plugins, look for signs of quality, such as:

  • Current with latest WordPress
  • Positive ratings and feedback
  • Signs of active support
  • Number of other users
  • Updated recently

And so forth. Keeping an eye out for signals of quality and reliability will help you choose the best possible themes and plugins for your site. And that will help keep your site secure.

Know what You're Doing

This goes not just for using WordPress, but for any online work in general. There's a lot involved, a lot of moving parts, a lot that can happen. It's important to educate yourself as much as possible to gain an understanding about how things work, what they do and so forth.

Likewise with WordPress, it's key to understand how to use and get the most out of the software. Doing so will help you make educated decisions and get the most out of WordPress with the least amount of effort. And of course, understanding is a precursor to good security.

Know where You're Doing It

I am amazed at how cavalier some people are about working online via any wi-fi connection they can find. They just walk into any shop, connect to the local free wi-fi and get to work. Why is this a bad idea? Because you never know who is lurking on the same unencrypted network looking for victims.

Never log in, make purchases, or do anything other than browse when working off an unknown or insecure wi-fi signal. Otherwise it's just too easy for attackers to hijack the signal and steal your information. And you would have no idea until it was too late. Unless you've taken explicit steps to secure your connection, stick to trusted networks for all work and business related activity.

Don't Hack the Core

Plain and simple: do not hack any WordPress core files. Doing so on production sites is a recipe for disaster. Same is true for plugins and themes — do not modify their core files. Instead, if you want to change default functionality, do so via prescribed channels, such as:

  • Modify or customize core functionality via plugin
  • Modify or customize theme appearance or functionality via child theme
  • Make changes to your theme via functions.php

Also important to good security: when making changes via any of these methods make sure to use the WP API whenever possible.

Ensure Proper File Permissions

If your server is configured correctly, all WordPress files and folders should be created with proper permissions. The general rule is that the permission level of files should be set at 644 and folders set at 755. Of course, it's not always that simple, various configurations are possible3. If upon examination you discover that file and folder permissions are not correct (or don't look quite right), consult the WP Codex and ask your web host for help.

Disable Error Display

During development, displaying errors on the front-end of your site is perectly fine. But during production, when your site is live online, displaying information about errors is a bad idea. Doing so could reveal sensitive information about your server configuration, PHP setup, and any potential vulnerabilities. Broadcasting that kind of information for the entire world to see is just not a good move. Why risk it?

Instead, once development is complete and you're ready to go live, take a moment to disable error display on your site. WordPress errors are easy to disable by opening wp-config.php and adding the following line:

define('WP_DEBUG', false);

If a similar line already exists with a value of true, just change it to false and you're good to go. Likewise you want to make sure that display of PHP-generated errors is disabled. Here are some articles that explain how to do so:

If in doubt about PHP errors, ask your developer or web host for more infos.

Keep Spammers at Bay

One thing you don't want is a bunch of spammers leaving comments on your posts. Spam comments send a signal that your site may be of poor quality, neglected, and possibly insecure. SEO implications aside, such signals tend to repel legitimate visitors and attract malicious behavior. To help control spam, you can install a plugin (there are many), or just use WordPress’ built-in spam-control features. Eliminating spam helps improve your site's reputation, ranking, value, and security.

Run a Clean Machine

Another critical security step is to make sure that your local machine and devices are free of spyware, viruses, and any other malware. Even if your server and site are squeaky clean and super secure, it's all for nothing if you're working from an infected machine. As stated at the WordPress Codex1:

No amount of security in WordPress or on your web server will make the slightest difference if there is a keylogger on your computer.

A complete discussion on this topic is beyond the scope of this article, but there is much information available online. Hopefully you already are familiar with the importance of running a clean machine; if not, take the time to read up and protect your computers and devices from security vulnerabilities. This includes doing things such as:

  • Connecting to the Web via secure router
  • Running behind a trusted, reliable firewall
  • Staying current with all software and updates
  • Don't allow access to untrusted networks or devices
  • Stay aways from shady sites, pirated warez and so forth

Of course, there is much more to the art of securing your personal work environment (computer and devices). Unless you're already savvy, do the research and take proper steps to secure your work setup.

Monitoring and Logging

Logging and monitoring are your best friends when it comes to troubleshooting errors and investigating security issues. Most servers record detailed access and error logs that contain a wealth of information about every request and error, including valuable data such as date/time, IP address, requested URI, response codes, and much more. Examining access and error logs may be a little overwhelming for the uninitiated, but once you're familiar with the basic syntax of your log files, you can use them to help resolve all sorts of issues. If you're not sure how to access these files, ask your web host.

Going further

Up to this point, we've covered steps that most anyone can do to help keep WordPress secure. Most of the techniques we've seen so far require little to no modification to any files or code. Going much further with security typically requires making changes to your site, its files, code, and so forth.

For security techniques that require making changes to your site, it is important to consider the return on investment. A good example is the practice of protecting the /wp-admin/ directory with .htaccess. Sure it sounds like a good idea, and may even provide some extra bit of security, but the potential for problems with plugins and themes makes it something that you may want to avoid. The headaches just aren't worth it, IMO.

There are many examples like this, where the promised security benefit simply is not worth the potential risk. So my best advice is to stick with techniques that:

  • Are easy to implement
  • Are not overly invasive
  • Introduce no additional risk

With these things in mind, here are some additional security techniques that are aimed at providing additional layers of security with minimal risk, minimal effort, and minimal amount of changes required to your site.

Authentication Keys

Inside of the WordPress wp-config.php file, make sure to add some strong, random security keys to the section, "Authentication Unique Keys and Salts". Adding these authentication keys helps to improve the security of WordPress login routines and is highly recommended.

Note that you can add, change, or edit these keys at any time with no harm done other than invalidating any existing cookies. So basically the worst that can happen if/when you change the keys is that any logged-in users will have to log in again. No biggie.

To generate a strong, random set of salts, visit the official page at https://api.wordpress.org/secret-key/1.1/salt/. Then copy and paste into your configuration file, upload to the server, and done.

Disable Directory Views

Directory views are what happen when..

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

After months of hard work, I am excited to announce the launch of my new video course on developing WordPress plugins. It covers the entire process of building, securing, and optimizing your own plugins, including 50+ ready-to-go demo files, examples, and plugins. The course is focused on developing plugins using the WP API and Standards. Covers basics and gets into advanced topics like HTTP API, REST API, and WP Cron. Truly packed with practical examples and techniques to help you create your own awesome plugins. Check it out at Lynda.com »

Direct link to article | View post at DigWP.com

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In my recent post, DIY WordPress Popular Posts, I share a simple, two-step technique for tracking and displaying popular posts on your WordPress-powered site. That post describes everything needed to fully implement DIY popular posts, but some folks wanted an easier (more convenient) way to display the list of popular posts on the front-end (instead of using template code).

And as a bonus, make it possible to specify the category and number of posts. So in this quick follow-up tutorial, I share a sweet little shortcode that does exactly that: displays a customizable list of popular posts.

Hello, Shortcode

The Popular Posts Shortcode is entirely plug-&-play with no configuration or editing required. Simply add the following code to your theme's functions.php file and you're ready to go. Note that this shortcode requires that DIY Popular Posts is implemented on your site. Here's the secret sauce:

// shortcode: display diy popular posts: [diy_pop_posts num="10" cat="1,2,3"]
function shapeSpace_display_popular_posts($atts) {
	
	extract(shortcode_atts(array(
		'num' => 10,
		'cat' => '',
	), $atts)); 
	
	$temps = explode(',', $cat);
	$array = array();
	foreach ($temps as $temp) $array[] = trim($temp);
	
	$cats = !empty($cat) ? $array : '';
	
	?>
	
	<h3>Popular Posts</h3>
	<ul>
		<?php $popular = new WP_Query(array('posts_per_page' => $num, 'meta_key' => 'popular_posts', 'orderby' => 'meta_value_num', 'order' => 'DESC', 'category__in' => $cats));
		while ($popular->have_posts()) : $popular->the_post(); ?>
		<li><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></li>
		<?php endwhile; wp_reset_postdata(); ?>
	</ul>
	
<?php }
add_shortcode('diy_pop_posts', 'shapeSpace_display_popular_posts');

This code snippet uses the WP API to create a shortcode called [diy_pop_posts] that can be used on any WordPress Post or Page (or CPT). The function uses WP_Query to grab and display a simple unordered list <ul> of all matching popular posts. Bada bing, bada boom.

Shortcode Usage

Once the DIY technique and shortcode are in place, you can display a list of the most popular posts on your site. Here are some examples of shortcode usage:

[diy_pop_posts]                      // displays top 10 popular posts from all categories
[diy_pop_posts num="100"]            // displays top 100 popular posts from all categories
[diy_pop_posts num="5" cat="1,2,3"]  // displays top 5 from categories 1, 2, and 3
[diy_pop_posts cat="1,5"]            // displays top 10 from categories 1 and 5

So it's all pretty straightforward. If you have any questions or suggestions feel free to share in the comments section below, or send via email.


Read Full Article
Visit website

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview