I am using Git a lot these days. Git is arguably the best version control software out there especially for collaborative projects.
Love this simple and well illustrated guide to some github basics: http://rogerdudler.github.io/git-guide/
I made the move from Coda to Sublime Text this week.
After only a week, I really, really like Sublime Text – it’s fast, pretty and customizable with a wide range of plugins available via the Package Manager.
I came across an old Coda plugin that I did some work on years ago that is now available on Sublime Text; the plugin helps to tidy and format your code to meet WordPress coding standards.
The plugin is available here – https://github.com/welovewordpress/SublimePhpTidy
It is pretty cool to see something you did a few years ago being picked up by someone else, improved upon and ported to a new editor that you happen to move to :).
SVN externals allow to include (nest) a remote SVN repository into another SVN repository. They are a great way to keep the latest code from another repository without having to do much.
One thing you will need to do is tell svn what revision of this remote SVN repository to load. To do that, do the following.
You turn on WordPress debugging only to find the log full of deprecated notices that make the log difficult to parse. Bummer.
You could spend time going through each deprecated notice and updating the offending piece of code. Or you could ask WordPress to ignore these deprecated notices (at least in the short term) by doing the following;
If you are developing a plugin on WordPress, you will need to debug your code as you go.
To enable debugging, go to your wp-config.php file.
Find the line…
Replace the line above with the following…
// Turns WordPress debugging on define('WP_DEBUG', true); // Tells WordPress to log everything to the /wp-content/debug.log file define('WP_DEBUG_LOG', true); // Doesn't force the PHP 'display_errors' variable to be on define('WP_DEBUG_DISPLAY', false); // Hides errors from being displayed on-screen @ini_set('display_errors', 0);
Now you all warnings and errors will show up in the /wp-content/debug.log file, including WordPress warnings of deprecated functions.
You can write directly to this log from your plugin using the
//output some debug string error_log( 'this works yo' ); //output some array/object error_log( print_r( $some_obj_or_array, 1 ) );
Kudos to this post. It has some good plugin development tips, including how to enable debugging on WordPress.
Do not use
remove_filter(). It is possible it will break other hooks which can have unintended consequences. This post gives a really good alternative approach using static variables.
Worth to know for wordpress plugin authors: Making your plugin to safely unregister or remove a hook (filter or action) is not possible with the wordpress plugin API. Why? you might ask yourself. Even the name of the remove_filter() function suggests it and the codex documentation does say so as well.
But: It does not work, because this function does not work as intended. And beyond your own hooks, it has the potential to hinder the blog from working properly as it has the potential to remove other hooks then the specified one.
Does not is not exactly right, it does, but only sometimes. That’s specifically a bummer if you write plugins yourself, because you can not safely rely on it. For example, if running your plugin makes use of PHP 5.2 or greater it works. But it does not if it’s running on PHP 4 or PHP 5 lower…
View original post 1,582 more words