So you are writing your grand WordPress plugin and you have a custom post type which the user uses, so far so good. You write your single-awesome.php file to allow WordPress to show a view for your custom type and put it into your theme, but wait a second I want my view to be portable! What are my options?
One option is to give up and go along, write a bunch of single-awesome.php files for every major theme (and there are a lot) and on a client basis. However, this is clunky, time consuming and impractical. As the creator of a plug-in, not a theme, you are responsible to have your plugin work, mostly, as is.
There is a better option and that is to include the template files in your theme and to write a add_filter hook to catch whenever a single-*.php template is called and handle your custom post types appropriately. Kenneth Newman at unfocus.com put together a nice post, with code examples, about doing just this. Luckily the code allows for the active theme to override the plugin, which is a good idea considering your template will not fit for all the possible themes out there.
However, we can hand some control of the templates colors, fonts, etc over to the user using a settings page. Currently I am working on an elegant way to do just that and make using my plugin as easy as possible for those who need to use it. Follow up post coming soon
More after the jump.
Here is the Reload-JS source code. It is simple and it doesn’t really do anything special. Most of the code has been used previously and is very popular for live loading. It accomplishes its task by using a recursive set of callbacks and has a few ways to call it.
You see Reload will automatically append the js if you don’t already have it attached. This is a nice feature to make nice simple calls like above. Reload allows you to set your primary library location and then takes care of it too. This makes loading multiple libraries pretty nice. However, what if you need to use a different host for one of your libraries? No worries! just make sure you use http:// and Reload will detect that it shouldn’t append your default library location to your URL (absolute URL handling).
Reload also has the ability to load from a variable it holds called libs. This can be risky, if multiple people try to use it and is not suggested unless you are sure no one else is using Reload.
Recently I have taken to doing more web development, even though I truly enjoy music and electronics. I have taken to doing web-based projects because I find them engaging, I enjoy the end results and the web is an essential skill. I have completed two projects thus far, Shears of Elegance and Ideagerie, and my favorite was the later. Why? Because it was an art project.
Throughout most of my life I have been dedicated to music and composition. I value the arts and when my friend, Kaity Reilly, asked me to develop her website, Ideagerie I jumped all over it. The good thing about working with a friend on a project is that the communications are less strained and there is less of a begrudging acceptance of the clients choice. Also artists are less particular about browser compatibility (if it doesn’t work in IE3 they don’t care much, so long as it gets out to a decent audience) and more willing to let you experiment on the backend, they will let you use what they are unfamiliar with. These sort of partnerships should be approached as being exploratory for both parties involved.
For Ideagerie I decided to use Sinatra and Ruby as my main workhorses and deployed on Heroku. This ended up being perfect for what the artist wanted. The git based updates allowed me to update the site swiftly and sink my teeth into development right away. By using Heroku I was also able to engage the artist in the process as they were able to see the updates almost immediately. Of course this is possible through more traditional means, but Heroku is more or less free for low-level use and you can swiftly update everything with a few git commands. Also, the artist I worked with liked to engage themselves in parts of the process, which is a unique opportunity to teach and receive new ideas.
Working with an artist is not all fun and games though. There will be constant disagreements over certain things, especially efficiency. Just because you naturally code efficiency doesn’t mean that the artist desires efficiency. In fact, there are times when the artist might just want to dump everything onto one page and remove pagination completely. Also, they tend to be particular about presentation. As my friend said, “The site [Ideagerie] does not need to be an Apple quality marketing campaign, but it does need to look like a person made it” (Kaity Reilly). Kaity also told me that, “the presentation, for me, is the most important part,” at a point where I was obsessing over efficiency/database issues.
Remember, don’t only work with other engineers or web designers, work with all sorts of people. You will gain more insight that way.
I got this little kit, Terror-Min from SparkFun. and put it together today. I had a little trouble with the soldering iron at first, but eventually I got the whole situation sorted out (I had to file of a little bit of oxidation on the tip… I might need to buy a better tip for my iron). I made a few mistakes while soldering, but it didn’t effect the fact that the circuit works. I am pretty proud of myself.