The workshop was a great way for many to get started with WordPress development. Micah and Aaron went over from the basics of development through child-theming. I stepped up to help others get started, since we were all installing mamp to get a local wordpress install setup. Even with the famous 5 minute install it was taking most people a long time to get setup, though we can blame the wifi for most of the issues I believe. We then cloned Micah’s child theme demo from github into our theme dir and he get started through the demo. Follow along by reading his blog post length commit messages. It was great to help out! I even learned a few tricks about some WordPress hooks, the loop and template hierarchy.
I’ll share one tip many might not have realized when dealing with child themes. The difference between get_template_directory_uri and get_stylesheet_directory_uri.
There needs to be a cultural change in how we approach building for the web. Yes, some of the tools we choose are part of the problem, but the bigger problem is that performance still isn’t being recognised as the most important factor in how people feel about websites (and by extension, the web). This isn’t just a developer issue. It’s a design issue. It’s a UX issue. It’s a business issue. Performance is everybody’s collective responsibility.
Great read if you haven’t yet read it yet:
Frank Chimero : What screens want : http://frankchimero.com/what-screens-want/
web and interaction design are just as much children of filmmaking as they are of graphic design. Maybe even more so. After all, we both work on screens, and manage time, movement, and most importantly, change.
So what does all of this mean? I think the grain of screens has been there since the beginning. It’s not tied to an aesthetic. Screens don’t care what the horses look like. They just want them to move. They want the horses to change.
Designing for screens is managing that change. To put a finer head on it, the grain of screens is something I call flux—
Movement, change, and animation are a lot more than ways to delight users: they are a functional method for design.
These examples are essentially animated wireframes, but extra detail isn’t needed. Designing how things change and move is enough for us to understand what they are and the relationships between them. You don’t need the heavy-handed metaphor, because the information is baked into the element’s behavior, not its aesthetics.
A designer’s work is not only about how the things look, but also their behaviors in response to interaction, and the adjustments they make between their fixed states. In fact, designing the way elements adapt and morph in the in-between moments is half of your work as a designer. You’re crafting the interstitials.
We’ve been more aware of this interstitial work in the past few years because of responsive design’s popularity and its resistance to fixed states. It’s a step in the right direction, but it has made work crazy frustrating.
Please read the full article: http://frankchimero.com/what-screens-want/
Generally-speaking, the conversations have always circled around features: There are those that believe every feature you could ever imagine should be included like text color, font selector, and more. On the flip-side, there are those that feel WordPress themes should be finite and extra features should only be added when it’s niche specific.
He says the the main problem is theme bloat, but I think it’s more about the lock-in effect some themes have on users. If they customize it or add content via functionality provided by the theme, then if they switch they no longer have access to it (although the content does persist in the database, there’s just no longer an interface to accessing it).
If users are stuck in your theme because it’s the only way they know how to show their content then it becomes problematic. I’m curious as to how often users are going around changing themes though. Are they changing themes for more/different functionality or for a new look? I find myself changing a theme every couple years or so to update the site, but that’s usually in a whole redesign phase and not just switching around for fun. Should theme switching be more frequent?
I also see it from the user perspective. They just want to purchase/install a theme and be running, they may not have the patience or expertise to 1) find the right plugin 2) install it and set it up, so they’d prefer it be in the theme as a package deal.
Partly, I don’t see it a problem including CPT info in a theme, because that’s where you have to style it anyways, right? Users want their post types, but they also want the templates and styles and functionality/integration with the site that go along with them, and I think a theme is the easiest place to keep all that for the developers as well as the users. Plugin shouldn’t have all the styles for the CPT content and can’t have the template files because then if they switch the theme the styles conflict with the new theme. They may end up having to learn CSS to switch the theme anyways. The users are going to want their data displayed properly as well as it be accessible on their site. So if a new theme would not properly display or integrate the CPT data, then why have it included at all.
Eric does offer some alternative solutions:
Offer a Support License purchase option that allows users to follow tutorials for their own customization.
Offer free downloadable plugins that work exclusively with your premium theme that adds easy functionality.
Offer tiered theme versions–beginner, advanced and developer.
I like the idea of including a plugin to add functionality, but I’d suggest that rather than making it exclusive, make it work with any theme, just make sure your theme supports it (along with other popular plugins).
There is talk about making extra theme functionality ‘opt-out’ for those experienced enough to do so. Set a variable in the functions.php file or even comment out a block of code to remove some customization options to it can be done via a plugin. This, although more work, seems like a good option. Providing the features by plugin makes sense, but asking beginner users to do that extra work seems like unnecessary friction.
Also, it’d be nice if WP had a built in UI for custom post types and custom taxonomies and even custom fields and meta boxes in core. Lay users could then easily create content types and manage data. WordPress would be a tool to create your own custom CMS. Theme developers could create post types as well and then WP would be smart enough to detect data in a CPT table and include the needed UI. Then the users could create/manage content types so if they installed a theme that created a custom post type, since it was now in the database, it would stay even if the theme changed. There are many rabbit holes here, but I feel like I’m onto something and would be excited to see WordPress go this direction.
David Desandro / metafizzy, maker of masonry and isotope of which I’m a big fan and user of has been busy with a new project called Packery.
Packery, looks to be a child of Masonry. As you would expect it seems to be pushing things much further and addressing a few pain points of masonry. He’s boasting in this blog post that it will optionally support grid layouts, and give you the option to go grid-less for a more haphazard looking layout. It will allow filling holes and adding elements on the fly, but most impressively… We’ll have drag and drop support (including touch support and multitouch support)! You drag an item around the grid (or non grid) and watch live as elements reposition to embrace the newly placed item! Very cool and I can’t wait to play with it.
True developers strive to be DRY (Don’t Repeat Yourself) in code as well as workflow and process. Previously, I somehow ended up doing in many of my projects things that plugins could also do.
It’s great to code your own sometimes and if you have specific needs that aren’t addressed by something out there already then sometimes it’s required. I think there is a lot to be said for the state of the plugin community lately. There are plugins to offer solutions many needs beyond what WP core was built to handle.
I’ve found that many times plugins are better then rolling my own solution. Not because I’m a horrible developer (I hope not at least), but because there is real power in numbers.
First off, plugins benefit form the community or users and developers involved in making them work and making them popular. Choose plugins that have a good base of users so when the author or WordPress ships updates, there are many people reporting/testing compatibility issues.
There is a community of people thinking about how to solve recurring needs and many minds working together on something are smarter than one. This is how I’ve come to terms with paying for plugins for an open source and free platform.
It’s worth the expense in the time I save on projects. (Disclaimer: However, I don’t think we should be using a screwdriver as a hammer simply because we can make it work. If you end up hacking plugins to get what you need out of it, then you may be better off building your own.)
This past year, I resorted to using plugins for a lot of the basic functionality I found myself using over and over again on many sites. I’ve been pleasantly impressed. Here are my top 3 plugins of the year:
BackupBuddy by iThemes. Backuping up a site is pretty much essential for anyone who does web work professionally. Not only for security but also for moving sites.
As a developer I’m constantly moving a site from a dev environment to a production environment and vice versa. It was the bain of existence at times, because with WP, moving the site is more than just copying files via ftp. It includes the database and config files and settings in the database too.
BackupBuddy, has helped this become a fairly simple process that lets me export the whole site (database and all) into a zip file and then I can easily place the site on a new domain or environment.
The huge win for me is that I’m spending less time managing databases and more time building websites. Although I generally tend towards open solutions, this one has been worth the money spent many times over. (Even when they had an update that broke my database, it still saved me time in the end).
I mainly use this tool to schedule and automate my backups and save them remote locations either weekly or daily and to move my site between dev and production environments for testing and deploying.
Gravity Forms by RocketGenius. Forms are a part of every website I’ve built lately. I used to use CF7 and still am a big fan, but I ended up trying this form plugin out once and have been very impressed with the UX and UI. It has many features and is tastefully integrated into WordPress.
Some of my favorite features are that it saves the form submissions into my database and I can send complex notifications about the submission. It also has many field types built in. so if I need to capture someones email and shipping address, there are fields that will validate as such automatically!
True, I could write my own script to do this, but why spend unneeded hours to reinvent the wheel, and test the wheel and maintain the wheel.
There are many many plugins offered to enhance the gravity form as well, you can integrate easily with MailChimp, Paypal and WordPress itself (for creating user accounts or even content).
I’ve used gravity forms as a simple contact form, as a job application form, as a donate form, newsletter signup form and more. It’s nice to be able to rely on one plugin for all this. The support forum has always been helpful as well.
3. Advanced Custom Fields
Best for last in my list is Advanced Custom Fields by Australian, Elliot Codon. The plugin site lists many add-on plugins that extend the functionality. Hopefully you’ve heard of custom fields in WordPress already, and if not, they are extra data about the post (or whatever type of content you create with custom post types).
You can add an external link, a price, an address or anything you can think of. This isn’t too hard to do in a theme or plugin on your own and has been documented and tutorial-ized many times explaining how to create fields and saving them to the database and grabbing them from the databse… but it does get tedious.
And then there are all the different types of data you may want to store that you end up having to reprogram every time. Text and numeric values are simple enough, but what about a date, an address, an image or a relationship.
This plugin makes it not only easy, but fun to create custom fields. It adds easy functions for php to grab the data you need at the template level and the UI is entirely seamless with WP. There are many options for conditionally including or requiring the custom fields in the post edit screen etc.
I think this plugin truly transforms WordPress into an open minded CMS with style. Mad props for it not being added to the list of premium plugins (although some add-ons are for sale). I’d vote for this being added to WP Core and won’t likely work on another custom field project without it.
In all, it’s been a great year to be working with WordPress and it’s only getting better! I’m excited for the number of plugins that are getting better all the time geared towards easing the process of building sites. Equally exciting is the plugin repository at wordpress.org and the recent updates of being able to write reviews for plugins, I think this is a huge step towards letting the cream of the crop rise to the top allowing users and developers alike to find (and support) the best plugins out there.
What plugins have you found that don’t just save you an hour or add a bit of functionality, but that transform your workflow and help you live the DRY mantra?