Creating Your Own Plugin for Customizing WordPress (WPReading Meetup)

At the Reading WordPress Meetup, on November 20th, 2018, I demonstrated how to code your own plugin for WordPress. This was a high level discussion, focused largely on the Q&A.

Here is the GitHub repository for the demo plugin I created.

What is a plugin?

  • Extra code, in addition to the theme, that is run after WordPress is loaded.
  • Plugins are stored in the /wp-content/plugins/ folder of your WordPress site.
  • Plugins must have a php file and a valid plugin header comment.
  • Only plugins activated from the plugin menu of the WordPress dashboard will run.

Why code your own?

  • Because you are a badass.
  • Because you need to tweak something specific to your site.
  • Because someone like Jason gave you custom code to patch your site.

Why not use functions.php in a theme or child theme? (Or edit a plugin or edit WordPress core.)

  • If you edit a theme or another plugin or WordPress core… that edit will be overwritten when the theme, plugin, or WP core is updated.
  • If you have your own child theme, you can put the code there. It’s less likely to be updated. However, your code stops running when you change your theme. Or maybe you don’t want a child theme.

Demos

  • Changing the excerpt length of archives.
  • Removing unused profile fields.
  • Setting a sitewide banner for Memberlite theme.

Other Demos?

  • WooCommerce
  • Ninja Forms
  • Paid Memberships Pro
  • Custom APIs
Creating Your Own Plugin for Customizing WordPress (WPReading Meetup) was last updated on November 20, 2018. Bookmark the permalink.

Heartbeat API for WordPress

As part of the JavaScript chapter for our upcoming book Building Web Apps with WordPress, I got a chance to research and work with the Heartbeat API that is new to WordPress 3.6.

It’s a cool little piece of functionality that will help out developers building asynchronous apps on top of WordPress.

At first, I didn’t see the need for it. (It’s not too hard for developers to create their own script to poll the server every few seconds.) But I soon realized why an API like this would be useful. If  you have 5 different plugins all with their own server polling, you are going to have 5 different hits to your server every 15 seconds. However, if they all piggyback on the Heartbeat API, those polling requests are going to be bundled so you are only hitting your server 1 time every 15 seconds. There are other benefits, but that’s the big one to me.

For people trying to get started with the Heartbeat API, I put together this nice little minimal example that you can use as a starting point. The script below simply sends the message “marco” from the client and then detects this on the server and sends back “polo”. The messages are logged in the JavaScript console (so if you inspect elements and click on the console tab in Chrome you will see them). You should be able to easily tweak this to send requests like “how many members are logged in?” and send back a number, etc.

Let me know if you have any questions about the API and I’ll try to address them.

Heartbeat API for WordPress was last updated on August 7, 2013. Bookmark the permalink.

Don’t Break The Code

Last Saturday at WordCamp Philly, I ran a session on “Building a Plugin in One Night”. Together, with about 50+ attendees, we brainstormed ideas for a new WordPress plugin that I could code that night.

The brainstorming went great, coming up with some good ideas… like plugins to:

  • Help first responders after a disaster (Big Idea!)
  • Add VIM (a Linux editor) shortcut commands to the Visual Editor
  • Disable the Visual Editor on a per-post basis (The Winner)
  • Allow users to create pages from the front end
  • Add easy donations
  • Log into WordPress via Google+ (Brian did it!)
  • Add syntax highlighting to the Visual Editor (Chris did it!)

The concept that the audience voted for me to work on was a way to disable the Visual Editor tab on a per-post basis. The motivation for this is the fact that the autoformatting of the Visual tab will sometimes break a complicated (or not so complicated) HTML structure ruining your code. Folks wanted a way to say, “Hey, WordPress, back off on this page/post.”

And someone (you introduced yourself to me later, but I forget your name) came up with a kick ass name: Don’t Break the Code. It explains the purpose and also harkens back to my days at Haverford College, which has a strong social/academic honor code.

I had hoped for something a little more mainstream. Only a developer or power user will really appreciate a plugin to disable the Visual tab, but that’s okay. The effort would be appreciated.

Turns out there are already a few plugins that either disable the Visual tab or remove other filters to keep WordPress from breaking code. The started trickling in after the presentation wrapped:

… and probably a few more. So we weren’t blazing new ground.

Still, some good ideas came up during the session that could improve the experience of using a plugin like this. Like:

  • Put the checkbox to disable the editor in the screen options area so it doesn’t clutter up the editor
  • Only allow admins to disable the editor. Other roles will see what the admin chose.
  • Allow admins to add a note RE why the Visual Editor is disable.
  • Remove other filters (like wpautop) to lower interference even more.

I spent the spare time I had during that day and then after the after party from midnight to 5:30am the next morning looking through the code in the existing plugins and piecing together the best pieces of them. I liked how “Disable Visual Editor WYSIWYG” just grayed out and struckthrough the Visual tab instead of removing it directly. I liked how Raw HTML put things in the screen options space and also how they allowed for disabling the other filters.

Anyway, the plugin released that morning on GitHub and then later at the Dev Day to the WP repository. You can grab it here:

Don’t Break the Code WordPress Plugin

So far it allows admins to disable the Visual Tab just like we said. I improved on the DVE WYSIWYG plugin by disabling via Ajax for a better user experience (you don’t have to click update for it to take affect). And after trying to copy Raw HTML’s method of placing things in the screen options, decided to scratch that and just code it myself using some tutorials I found online.

It works nicely. I plan to add checkboxes for disabling other filters similar to Raw HTML and also want to include that “add a notice” functionality somehow. I was going to incorporate the syntax highlighting, but that works really well as a stand alone plugin. Chris’s code had some problems on my setup that I hope to look into and patch for him.

Let me know what you think of Don’t Break the Code. If you want to contribute, you can fork and patch via GitHub here.

Thanks!

Don’t Break The Code was last updated on November 10, 2011. Bookmark the permalink.

Fix for WP Page Tree Plugin in WP 3+

The WP Page Tree plugin is a nice plugin. It shows a tree view of pages in your WP site… but it’s been broken since about version 3 or so.

I’m sure there are other tree view plugins that work well, but I liked that one. And it is actually an easy fix to get it working in WordPress versions 3+.

The issue was that the links generated in the tree view pointed to the old admin URLs for editing pages (page.php?action=edit&post=#). The new more generalized URLs for editing pages is (post.php?post=#&action=edit).

So, what you want to do is find line 404 in wppagetree.php (of version 2.8 of the plugin) and change page.php to post.php. That’s it. The whole block of code around there should look like:

if ($public) {
	// Create our own link to edit page for this ID
	$out .= "" . $pageTitle . "";
}
else {
	$out .= "" . $pageTitle . " #";
}

Or download this zip here which has version 2.8 of the plugin plus that one fix. I may upload it to the WP directory sometime, but then I’d have to maintain. Feel free to do it for me. 😉

Download: page-tree-fixed.zip

Fix for WP Page Tree Plugin in WP 3+ was last updated on June 2, 2011. Bookmark the permalink.