I’m happy to be contributing to the WordPress community as a speaker at WordCamp Atlanta 2018.
I submitted a few topics and have been selected to speak about development process for teams. Here’s the short description:
Overview of some processes used at an agency level. Version control, code standards, database migrations, environment aware config files and automated deployments. From local development setup to multiple environments, version control to automated deployments, content migration to modular mentalities. With some how-to talk and some how-not-to talk, we’ll discuss some ways to “soup up” our process to work for us when it comes to web development and WordPress.
Let me know if there are any topics you’d like to hear me cover and I’ll do my best to work it in.
I’ve also been asked to help out during the developer workshop day. Details are still to be ironed out, but it will be an introduction for newer developers and help them get up to speed on development best practices. It will also be a specific look at the development updates on WordPress 5.0, more specifically the Gutenberg editor.
After contributing to the presentations at the Atlanta meetup about Gutenberg I’m excited to again help out in preparing the community for the new editor experience.
Presenting at WordCamp Atlanta is exciting for me because I’m from Atlanta and it is the first WordCamp I attended back in 2012, it was also my first time speaking! Six years have passed- the industry has changed and I have learned a lot in the past 6 years! I have learned so much about working within WordPress and have led multiple teams in different agencies. I’ve invented and iterated on process and workflows for myself as well as the team. I’m excited for the opportunity to take a step back and detail some of these procedures I’ve found most helpful.
I’m pleased to announce that I’ll be speaking at WPCampus! It’s the conference “Where WordPress Meets Higher Education”. My presentation is titled ‘The Modular Web For WordPress’.
WPCampus 2016 is the inaugural conference for the WPCampus community, a gathering of web professionals, educators and people dedicated to the confluence of WordPress in higher education. The concept for WPCampus is an education focused, non-profit event which will allow people to share and learn about WordPress in the world of higher education. So if you’re into WordPress and/or higher education and/or the web in general, it’s the place for you come July. Get a ticket to a wealth of knowledge and ideas.
I will be presenting on a topic that I’ve thought a lot about and have become pretty passionate about. I’ll discuss Modular Web Development and specifically how to integrate a modular development mindset into a WordPress development workflow.
Here is the official session description:
WordPress the CMS, meets the Modular Web. We need to stop thinking about a website as a collection of pages and templates, but as a set of modules and a system to manage them. Modules, like Legos, are interchangeable and can be combined fairly quickly to create an infinite number of results all while both showing variety and remaining consistent. With this modular paradigm shift, our workflows improve, our websites improve and our very well-being improves. Let’s explore how to use WordPress to manage site content using modules. We’ll see what this does for our development process and programming as well for our content management via the admin. We’ll discuss how to build and maintain a module library, and use it for every site you build. These principles have been immensely helpful in each team or project where I’ve put them into practice, so we’ll even take a look at a few examples and point out where to learn more.
While this may not be a topic specific to higher education, I think it very relevant in that having a smart process helps projects be more flexible, more on time and more on budget. I’m happy to be able to contribute to WordPress in education as well as WordPress ideas in general. I will be speaking on Friday, July 15th (I’ll try to update this with a time once it’s decided and announced). As I said, tickets (early bird even) are available now so go get yours. And if you’re interested check out my other presentations.
Here’s my presentation for the Atlanta WordPress Users Group to continuing their discussion on theming. The meetup gives you a first hand look at modifying your Theme’s look and feel. We’ll be showing you how to make typical changes to existing themes. We will not be showing you how to create your own theme from scratch, though we will have a meetup later in the year to do that.
During this meetup we discussed:
• What is CSS and why do we use it?
• What are ‘typical’ modifications to themes and how to make them
• Using ‘inspect element’ and/or ‘firebug’ to find and test
The presentation overviews the internet, teaches us how to spell HTML and other web programming “languages” that come together to form a WordPress website, like HTML, CSS & PHP. We even discussed web development tools like FTP clients and which text editors to use. We went over what makes up a wordpress theme and then the concept of child themes. Discussed the process of creating your own child theme with just a couple files and that you can create a child theme for any theme out there. We demoed how to view source and dissect any website, but more importantly, how to inspect elements on your site and live-edit the css for any element. Then to write these CSS rules to our theme to lock in the edits in your child theme.
If you have any further questions that you would specifically like reviewed, leave them in the comments below and I’ll respond.
We created a child theme for twentysixteen
We created our own child theme and discussed the benefit to creating a child theme over other ways to modify a WP theme. Our twentysixteen child theme did wonders for the look:
We explored the code to create our own WordPress child theme
Here are the code snippets for review
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
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.
I needed to write this up about going responsive in response after reading Where to Start (by Trent Walton of Paravel) about getting started with responsive web design. Thanks for sharing your thoughts Trent, I agree whole heartedly. In my experience it is the same. I wanted to share his post and also add my commentary for the parts that I really think Trent is spot on. Some dynamite points.
Longer On-Ramps Have Benefits
I believe Trent is talking about the on-ramp of beginning to create responsive sites. But when I first read the headline about the benefits of a lengthy on-ramp I was thinking about the ‘pre-design’ work that goes into a website. All that work that comes before design and has always been super beneficial to proceed thoughtfully with content strategies, sketching, architecture, wireframes and prototypes. This ‘on-ramp’ stage is even more important in RWD. The time well spent upfront before getting into designs and especially programming really really pays off. Think through all scenarios and purposes and requirements of the site before you hit the ground running. Or else you may get to the finish line realizing you forgot the baton. This is so important concerning responsive from the beginning, when making wireframes for example, we really must think about the available space to render the content.
Design
It’s no longer for prescribing exactly what a site should look like. Instead, it’s used for quick layout exploration and asset creation. As for which view/layout size one should start with, I don’t think it matters. Remember, a single photoshop comp will only express a sliver of the layout potential a fully-flexible responsive site has. It’s impossible to accurately assess a responsive layout in .JPG form.
Yes! Agencies (and clients alike, but I feel that the agencies and developers need to lead the way) need to move past the relic ideal of pixel perfect websites. Not that they should look bad, but they should not all look the same. The nature of the web is to be flexible, right? Let’s embrace progressive enhancements and move on when old browsers don’t see it as nice as current browsers.
CSS
All my values are relative (em, rem, etc.) and based on the 100% 16px base, so I can move code around without losing proportion.
Yes, Again! We need to be relative and fluid all the time. We’ve all picked up some bad habits along the way, but RWD can be seen as a good excuse to remove these.
Breakpoints should always be dictated by our content. Not by `insert popular device of the day`. We should be starting to learn that we shouldn’t rely on any specific device or measurement, because they change all the time. Let’s FORGET device resolutions at the media query stage. These dimensions should be thought out earlier and influence our content strategy. Nothing wrong with using 480 as a breakpoint if it makes sense for your content, but don’t force a square peg into a circle hole. Who knows, next year all these circle holes may become triangles (or spheres) and then we’re stuck shoehorning the square we started with again or starting over. Weird analogy, but I’m just going to let it be.
Regarding Grids, I agree here too. It seems that when using a grid for Responsive Web Design I feel constrained to the grid more than I should. Plus I think it takes the fun out of the process of laying out the content as prescribed. I love the idea of ‘content coreography’ too. It really adds to the sense the required craftsmanship by the developers/designers behind the site well done RWD. It also makes me think of site creators as the directors who layout and present data and lead the story telling of the site.
I’ve said it before, but I’m constantly excited by the web design industry because as it is such a young field, we are still making up the rules and discovering as a community what processes are best. At the same time, the technology driving the field is changing so fast that just when we start to settle into a routine it all gets flipped on it’s head and we’re reconsidering everything again.
Please read Trent’s full article as I’m sure it’s packed with good nuggets for you too.
When making the transition to building responsive websites, the hardest part can be getting started.
I get my fair share of questions about how to choose a direction and chart out the first few steps from industry comrades and potential clients. It can seem daunting, so I thought I’d attempt to sum up a few of my own current thoughts on the matter.
Getting into some mobile app development for Android and I was unprepared for the keystore file that is required to be included in the apk file. Using PhoneGap Build to compile my app the interface requires a keystore file uploaded.
After some digging on google it seems that the most common way to create a keystore file is by using some Java IDE like Eclipse, but the whole reason I was using build phonegap was because I didn’t want to fool with one of those. I finally pieced together what I needed with a few posts and wanted to put it all together to help at least myself in the future.
Luckily with a mac apparently you can do this with terminal! Following a couple tutorials, I managed to create a proper file, and going through a few steps to set the expiration or validity and the alias.
To create a keystore on mac OSX, first, open terminal. We’ll type keytool and then there are some commands to type and our keystore file will be created. -genkey (generates the key), -v turns on verbose mode so full details will be output, -keystore tells it what to name the actual file (it actually saves to the root directory, I’m sure there’s a way to specify location somewhere) and you type the filename (including the .keystore file extension). Once you enter this in you are prompted to fill out your name and company name and info like city, state and country. Then it verifies everything and you must type ‘yes’. Then it will prompt twice for a password, remember this it is how you will update/rebuild your app.
keytool -genkey -v -keystore file_name.keystore
This got me going but I had to do some back and forth to know some other requirements specifically for android marketplace and working with PhoneGap. PhoneGap Build was asking for the alias when I uploaded the keystore file to build my project, but I hadn’t set one. I had no idea what it would be and after trying my name and company and even filename I had to do some more digging. We can in fact set the alias name when I create the key with the -alias command. It doesn’t matter what this is, you just have to remember it. I think of it like the username to my previously entered password. The default is set to mykey, so you don’t really need to set it. This got me through the Build process with PhoneGap, and then I set up my app on the android marketplace (after paying the $25 license fee). Once I uploaded my first apk file I was getting errors regarding the keystore again. The marketplace was telling me that the validity was not large enough. The validity (or expiration) of the key by default is set to 90 days, but the marketplace requires at least 10000 days… quite a difference, no? So to set validity we add the -validity command followed by the value of 10000. Once i did this round I re-uploaded the keystore to PhoneGap, rebuilt the app and resubmitted to the Android Marketplace and it was accepted! Wow.
I hope that helped someone. I’m surprised that the PhoneGap doesn’t aleviate some of the pain in this process. Since the whole point of using Build PhoneGap is so that I don’t have to set up an IDE or get complicated. A simple online keystore gen process would go a long way, and better yet if they automated it somehow!
Did I miss any steps? Are there better ways to do this? (I sure hope so) Share a comment.
Also, check out the app I made from web technologies html, css and javascript with the help of PhoneGap. It’s a quiz that tests and teaches users facial recognition of leaders at church. It’s called LDSQuiz and shows images of modern day prophets and apostles and asks you to identify them by name.
Style Tiles are about designing a system or guide to style a website rather than full comps and mockups. They really come in handy when talking about Responsive Web Design since it frees the designer from having to think about different layouts (as much, it should already be addressed in the wireframe stage). The designer can then focus on thinking about styling the elements and setting rules for a system that will be followed throughout the rest of the site. I really like the thought that style tiles are for when mood boards are too vague and design comps are too precise. Though, It really makes me think about designing a style guide rather than designing a webpage. Then the developers building the website can follow the guide dictated by these style tiles and make simple future-friendly/object oriented/SMACSS/modular css (or sass/less if you prefer). This also leans towards the late trend of moving more of the web design process into the browser.
Ethan Marcotte refers to static comps during the responsive design process as a “catalog of assumptions” Style Tiles are the perfect complement to that catalog, whether it be in place of comps or to reinforce visual themes. Style Tiles don’t imply dimensions nor device; only that the design will be digital.
In addition to Style Tiles, “Component Style Guides” can help with carrying a particular style through specific functionality without designing full web “pages.” These guides are very helpful for responsive designs across a wide number of devices and for implementing design systems for a CMS platform.
Develop a design system rather than designing fixed-width pages.
I’m constantly excited by the web design industry because as it is such a young field, we are still making up the rules and discovering as a community what process are best. At the same time, the technology driving the field is changing so fast that just when we start to settle into a routine it all gets shook up and flipped on it’s head.
How do you see style tiles benefiting your process? Have you used style tiles in a project?
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:
1. BackupBuddy
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.
Screenshot of starting the migration/import process with backupbuddy. You do a complete backup, load this php file onto your new site and follow the prompts. They’ve made it surprisingly painless.
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.
2. GravityForms
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.
Here is the back end of gravity forms. This is where you set up or edit your form. Notice the fields you can select from the right to add to any form as fast as you can drag and drop.
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.
Here’s the interface when adding custom fields. You can easily choose the type of data you need and there are multiple options to configure to your situation.
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.
Progress
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?
I'm liking Ryan's initiative to make PhoneGap Build documentation and workflow updated, bug-free and more streamlined. I've been using PhoneGap and phoneGap Build more and more and I've really been enjoying how simple it makes the process. I'm all for making it better still and think it will be hugely useful!
I needed to write this up about going responsive in response after reading Where to Start (by Trent Walton of Paravel) about getting started with responsive web design. Thanks for sharing your thoughts Trent, I agree whole heartedly. In my experience it is the same. I wanted to share his post and also add my commentary for the parts that I really think Trent is spot on. Some dynamite points.
