Activate debug log

Turning on debug mode and displaying the errors on frontend is one ugly business. It’s neither easy to use nor aesthetically pleasing. And it’s a big no-no if your site is live. So, what the professional does is logs the errors, especially if you don’t have access to the main web server logs.

To enable the debug mode logs in WordPress, you add the following lines to your wp-config.php.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

View the logs in real time

The WordPress debug log location is wp-content/debug.log. It saves all errors, warnings and notices in there. Now you can see the issues in real time as they happen by using this tail Linux command:

tail -f wp-content/debug.log

Custom logs

Debug logging is very handy when you build your own stuff. When you have things you need to dig deep into actions and filters,especially AJAX ones, there is no direct way to display them in the screen, so you log them like a PRO.

error_log( $var_to_debug );

It will log the whatever you pass to the function to same debug.log file. As a results, you won’t lose a single hair out of debugging despair.

error_log() only logs strings, so if you want to debug an array or object, you’ll have to run it through print_r() first and then return it to error_log(). Like this:

error_log( print_r( $var_to_debug, true ) );

Stop debugging like an amateur and start doing it like a PRO!

Include the function below in your WordPress project. You can add it to your functions.php file in your theme or any file in a custom plugin you’re building.

The function will return the found post ID, if a post with the given slug is found, or otherwise false.

function post_slug_exists( $post_name ) {
	global $wpdb;
	if ( $p = $wpdb->get_row( "SELECT ID, post_name FROM {$wpdb->prefix}posts WHERE post_name = '" . $post_name . "'" ) ) {
		return $p->ID;
	} else {
		return false;
	}
}

Once the function is included, you can use it to check whether a post with a particular slug exists in the database. In my case, I needed to delete the original post before syncing the same post again.

if ( $pid = post_slug_exists( $post->post_name ) ) {
    // Delete this line and do your thing
    wp_delete_post( $pid, true );
}

Keep building!

To find this out I came up with this SQL query then I ran in phpMyAdmin:

SELECT parent.ID, parent.post_title, count(children.post_parent) AS children_count 
  FROM wp_posts as parent
LEFT OUTER
  JOIN wp_posts as children
    ON children.post_parent = parent.ID && children.post_type = 'revision'
  WHERE parent.post_parent = 0
GROUP
    BY parent.ID
ORDER BY children_count DESC
LIMIT 50

Of course, the first thing I did after I found this out was limiting the revisions in WP by putting this line in wp-config.php

define('WP_POST_REVISIONS', 2);

I highly recommend doing this for content-heavy WordPress sites.

Assigning an author

To assign a single author to a post or a list of posts running them through a loop, the core code would look like this.

// Prepare data
$p = array(
    'ID'          => $post_id,
    'post_author' => $auth_id
);

// Save data
wp_update_post( $p );

This code will update the author with the given $auth_id value, which is the desired user ID in WordPress.

Assigning co-authors

After the first tests with the above script, I discovered that it was not of much help because we were using the Co-Authors Plus plugin, which did not update its data when post authors was updated programmatically. So, I had to figure out how to accomplish this for co-authors instead.

After doing some digging on the plugin codebase, I discovered that they expose an object as global by the name of $coauthors_plus which we can call from our function. The core code will look like this:

// Prepare data
$coauthors = array($auth_username);

// Save data
$coauthors_plus->add_coauthors($post_id, $coauthors);

Running add_coauthors() method takes care of all the necessary steps to assign the co-authors. We can pass one or more co-authors at the same time as an array, but this time we don’t pass the user IDs, but their usernames instead. This is how this plugin saves the co-authors data.

These are the ways to programmatically assign authors and co-authors in WordPress. Please let me know in the comments if you found this helpful or need further explanation on this subject. Keep learning!

Before you think of polluting your theme files with those nasty conditionals, think again. What we will be using to achieve this is a custom function that we are going to hook into WordPress through the the_permalink and the the_permalink_rss filters. The first one will take care of the user-facing website and the other will handle RSS readers, so that we can have a consistent experience everywhere. This filters allow us to make the change in just once place, instead of making a mess of all our theme files.

Check the end result below:

function ns_overwrite_permalink($permalink)
{
    if( $custom = get_post_meta(get_the_ID(), 'overwrite_permalink', true) ) {
        $permalink = $custom;
    }
    return $permalink;
}
add_filter('the_permalink', 'ns_overwrite_permalink');
add_filter('the_permalink_rss', 'ns_overwrite_permalink');

This code goes into the functions.php file and no other change is needed anywhere. Such is the power of WordPress hooks, so learn to leverage them.

The gist of the difference between actions and filters is:
Actions modify functionality; filters modify data.

WordPress makes heavy use of actions and filters for its own core functionality. Thus, we can use actions and filters to modify WordPress default functionality  or add our own on top of it. WordPress ships with an extensive lists of actions and filters that we, as developers, need to accustom ourselves with.

Usage

To employ actions and filters we need to use these two functions: add_action() and add_filter(). Both of them take four same arguments. The first two arguments are required and the two others are not and we won’t find ourselves using them a lot.

We hook custom functionality into WordPress like this:

add_action( 'hook_name', 'our_custom_action', [priority], [accepted_args] );

We use custom filters to transform data passed through WordPress like this:

add_filter( 'hook_name', 'our_custom_filter', [priority], [accepted_args] );

Actions

Actions are triggered at specific times during the request. In front-end it can be the time when the header or footer is loaded, giving us the ability to put our scripts at those sections. In back-end it can be the time when a post is published so that we can email our subscribers to notify them that a new post is published on our blog.

In the example action below the function changes default WordPress functionality by modifying the default image link type. By default it is set to Media File and we want it to default to None so we can save a couple of clicks when we insert images into a post. We hook this functionality in the admin_init action, which runs before any other hook when a user accesses the admin area.

function wpl_image_link_type() {
	$image_set = get_option( 'image_default_link_type' );

	if ( $image_set != 'none' ) {
		update_option( 'image_default_link_type', 'none' );
	}
}
add_action( 'admin_init', 'wpl_image_link_type' );

In such a fashion we run every action to modify WordPress default functionality or to add extra functionality to it.

Filters

Filters are functions which modify data that WordPress passes through them before showing that data to the user or inserting it into the database. Filters take in data and modify it and then return it so other filters can continue to process it.

In the example filter below, it default data by modifying the classes added to body by default through the body_class() function. Through this filter we append a class name to the list of default classes. Our theme relays on this class for showing the right color scheme based on what the user has saved in theme Customizer, i.e. either light or dark.

function wpl_body_class( $classes ) {
	// light or dark color scheme
	$classes[] = get_theme_mod( 'color-scheme', 'light' );

	return $classes;
}
add_filter( 'body_class', 'wpl_body_class' );

This is the way to filter data in WordPress. It’s very similar in structure to actions.

Custom Actions and Filters

Up to now we have talked about how we can use actions and filters that ship with WordPress. However, WordPress allows us to create our own actions and filters through plugins and themes. Custom actions and filters are helpful to make our themes and plugins extendible through child themes or other plugins without needing the edit the source files.

Custom actions and filters are created and called in the same way that core WordPress hooks are, through do_action() and apply_filters().

In the sample custom action hook below we want to add extra elements after the post content, we can add an action hook in our appropriate theme file like this:

do_action('after_content');

To hook into that action, so that we can, for example, show author bios or other elements like ads, we will have to run something like this:

function wpl_author_byline() {
	get_template_part( 'parts/author', 'byline' );
}
add_action( 'after_content', 'wpl_author_byline' );

On the other hand, for our custom filter hook, let’s say we want to add more color schemes to our default ones, dark and light that we talked above. In this case we want the default list of colors schemes to be extendible through a child theme. We will have have to create a custom filter hook like this:

function wpl_color_schemes() {
	$color_schemes = [ 
		'light' => 'Light',
		'dark' => 'Dark'
	];

	return apply_filters( 'wpl_schemes_filter', $color_schemes );
}

To hook into this filter and expend the list with more color schemes, we run something like this:

function wpl_add_color_schemes( $color_schemes ) {
	$color_schemes['yellow'] = 'Yellow';
	$color_schemes['blueish'] = 'Blueish';

	return $color_schemes;
}
add_filter( 'wpl_schemes_filter', 'wpl_add_color_schemes' );

The end result will be that on our Customizer now will show four color schemes rather then the original two.

Custom hooks into our themes or plugins make our code extensible so that we, or others, can modify and extend.

Keep learning

Actions and filters are a powerful tool at the hand of the developer and a great way to modify default WordPress functionality and to extend it. I  hope this article has taught you something new and valuable for your everyday work.

Page: https://wplancer.com/about/
Post: https://wplancer.com/2015/09/post-slug-here/

There are two ways to get the slug in WordPress inside the loop. The first way is to access the $post object that is available inside the loop.

$slug =  $post->post_name;

The second way is to pass the whole permalink to the basename function, which will automatically process the URL and give us only the slug.

$slug = basename(get_permalink());

Use the way that makes most sense to you to get the post slug in WordPress. Keep building!

Out of that frustration I set out to find a script that would use Git to determine which files I had edited, since this is what Git does best, and upload those to the server through FTP. I used a bash script for some times. But that script was a bit sloppy and not very user friendly. I searched again for something written in PHP and I found a great little script that worked great. I used it for a long time as-is. Then I needed it to support Git submodules, which it did not, and so I added that functionality and made many more improvements. Now again I needed it to support nested submodules, or in other words, submodules inside submodules, and now it it has that functionality in place too.

So, it seemed a great time to make that little script public. I’ve named it PHPloy, and it does very well what it says. It is a little PHP script that allows you to deploy files through FTP to a server. It makes use of Git to know which files it should upload and which one it should delete. It is a real time-saver.

How it works

PHPloy is very easy to use. After you have committed your changes in Git and have configured your server(s) in deploy.ini, all you have to do is run:

phploy

If you want to specify a server, you run:

phploy -s staging

Or the long form:

phploy --server staging

There is a lot more fun stuff that you can check in the project page in Github.

Behind the scene

PHPloy stores a file called .revision on the server. This file contains the hash of the commit that you have deployed to that server. When you run PHPloy, it downloads that file and compares the commit reference in it with the commit you are trying to deploy to find out which files to upload.

Grab it

Head over to PHPloy’s Github page to download it and learn more how to use it.

The main difference of Git and Subversion is that Subversion is centralized; everything happens in a repository on a server, thus you have to be online in order to do anything with SVN at all. On the other hand, Git is decentralized. You have a full copy of what is in the server and can do anything with it offline, and push changes to the server whenever you want. There are also other differences on how they handle tracking of changes, but that’s not the point of this post.

Installation

To install Subversion or otherwise SVN on your computer, if you are running Ubuntu as me, all you have to do is  run this command on the terminal:

sudo apt-get install subversion

That’s it for installing.

Connect to SVN

Now, to start working with it, it means that someone has set up SVN on a server somewhere and you are given an SVN repository URL that you can checkout, which means you fetch the repository contents and meta-data to your local machine. To do that you run:

svn checkout svn://example.com/repopath/reponame

Depending on whether or not the server has you ssh public key, you might be prompted for a username and password. Just enter those to continue.

Check status

The point of version control systems is that it keeps track of your work. After you have made some changes to the files you got from the server and added new files and deleted others, to check what files you have changed you you have to enter your working directory by running cd reponame and then run:

svn status

To actually see what content you have added or deleted on those files your run:

svn diff

Commit Changes

To send the changes you have done to the repository, all you have to do is run:

svn commit -m 'What did you change and why message'

As I told you above, you cannot run this command if you are not connected to the Internet. Remember, SVN is centralized — everything has to happen on the server.

Fetch Changes

To get changes other fellow developers might have done to the files, you run:

svn update

It bring your working copy up-to-date with the repository on the server.

That was it for Subersion at this time. I hope this article was of some help to you.

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

If you develop websites, like me, or write software of any kind, you should be using a version control system, and Git seems to lead the herd and I personally use it and I recommend it to anybody. This little tutorial is going to teach you how to set up Git on a computer running Ubuntu.

1. Installation

To install git run the following command on terminal:

sudo apt-get install git

2. Configuration

Git uses a name and email to label and identify your commits properly. Git your name, so that it can properly label the commits you make. Git saves your email address into the commits you make.

You configure your name by running this command on terminal:

git config --global user.name "Your Name"

And your email by running this command:

git config --global user.email "your_email@example.com"

Please keep in mind that the quotation marks (“”) are needed.

And with this you are ready to Git to the real world. Yes, it is that easy.