Brad’s article really steals the show here. He’s really delivered a quality step-by-step of how to get a WordPress plugin off the ground and running.
So, rather than just echo what he’s done (since you don’t want to read the same article twice), I really want to emphasize the elements of what he and I are doing that are either a serious stretch for me, or really compatible with my background as a front-end developer.
What’s your function()?
My first gut feeling about digging into Brad’s article is that it’s full of FUNCTIONS. When I work on themes, I’m looking at php includes, echos, returns, if, else… I kinda can map my way through based on how obvious the language is. But because we’re building a plugin, not just tweaking what others have done, this thing has to actually DO something. It has to FUNCTION.
So, as we’re going through Brad’s code I see that he knows exactly why this function and that action needs to happen — and I DON’T. I know I’m a newbie, but man — I really feel like a guppy in the Pacific right now.
To get through this feeling of impishness, I asked myself:
“Why in the world did I agree to do this?”
What I’ve been motivated by for the past few weeks as Brad and I talked about FooDocs, was all the things it would DO for FooPlugins. I’m really excited to have a plugin that solves a lot of different problems that I’ve seen in other documentation plugins, or Table of Contents plugins. Most documentation plugins we’ve looked into have been basically just a fancy table of contents. Documentation needs to be a bit more than that. It’s kind of a combination of hierarchical posts, combined with a TOC, combined with syntax highlighting, combined with wiki-type features.
Ya, it’s going to rock.
And that’s what I need to focus on to get through hesitancy, or impishness. Well… I also need time. That’s true. Digging into new languages and new techniques takes soo much research and slow reading, trial and error.
So that’s my advice to you: Focus on your motivation, and make time, probably late evening time.
The Awesomeness
The other thing that stuck out to me about walking through Brad’s article is that with just a few lines of code I see the thing sitting in the WordPress backend — with MY name on it. It’s like magic!
Of course it doesn’t really DO anything yet, but it’s there. It’s like building your first template. When you see it as an option in the backend, with your name as the author — it kinda rocks.
I Can Do Some things Already
Luckily, FooDocs is going to be primarily Custom Post Type driven, and I as a front-end developer have done my share of custom post types the BAD way. Meaning, in the functions.php file. I also had the mis-pleasure of seeing exactly why it’s bad when my first client wanted a new theme, we activate it and a ton of their old content was gone (well… not REALLY gone, we got it back, but it was scary as S*&^ for a while there). If you think CPT’s belong in the functions.php file, go to Syed’s awesome write-up on the discussion, and come back here when you’re ready to build a CPT based plugin.
Brad has a great CPT generator at his themergency site that he mentioned. What I’ve been using for the past while is GenerateWP.com. It’s incredible. I made a couple decisions about how I would incorporate the CPT that I think are important. I really don’t think we’re going to support adding comments or trackbacks to FooDocs. So I left those off. I left off Page Attributes. I can think of ways that they might come in handy, but currently I think the Post Formats are all we’ll need. So here’s what my GWP options panel looked like.
So… I already hit my first snag. I activated Brad’s code and it worked fine and didn’t trow any errors. When I activated mine, generated from GWP, I get:
Warning: array_merge(): Argument #2 is not an array in C:xampphtdocspluginwp-includespost.php on line 1382
Troubleshooting already
I know I can just copy Brad’s code and be on my way. I’m also sure I could just ASK Brad why his method worked and mine didn’t. But if I did either of those things, I wouldn’t LEARN anything. I typically create CPT’s from GWP, so I want to know why my traditional method works fine in the functions.php file, but not here when I’m registering CPT’s for a plugin.
So, I isolated the $labels and the $args that were additional from Brad’s code, and line by line commented them out (with “//” of course, since it’s php, not CSS/HTML). Here’s a couple screenshots of the side-by-side.
After the commenting out, and replacing values that were different, I discovered that the culprit was the capabilities call. But the reason that was the problem was because I had ONLY copied over the $labels and $args arrays because that was all Brad’s had. The code from GWP had defined custom capabilities and custom rewrite rules that I neglected to include. Once it was all in there, I was good to go. This means plugging in the code from GWP is just as good as the route Brad did, but just make sure to copy it ALL over.
I also discovered that since I didn’t specify a menu_icon, it simply didn’t place one there at all. Brad’s has the default pin icon. Once I removed the whole menu_icon line then I had the pin too. But I don’t like the pin, so this WordPress Support post set my in the direction of calling one of the images from the wp-admin/images folder.
Lastly, once I thought I had cleared the woods, the plugin activated no problem, and threw no errors, I went to my FooDocs menu and low and behold… I could only add categories, not items.
UG!
But I already had a good guess at what the problem was. My custom capabilities, and I was right. Once I copied over Brad’s capability code I was in business.
I’m Committed
I gotta say: it was quite a bit of work just to get that little bit done. But, it’s there! Progress is good, even if it’s incremental. But, I have to say, it felt nice to really push this “commit” button and actually have a little framework on my GitHub repo. See you next week!
