An overview into the process used to launch and manage WordPress VIP hosted websites, insight into when VIP is a good fit and challenges to expect.
From the inception of WordPress VIP I’ve wondered what it was like to work on a VIP-hosted project. The hosting platform is notorious for being strict on code and process. On occasion, 3.7 DESIGNS would start a project that seemed like a good fit for the platform, but inevitably the projects would never get off the ground. Last year we finally landed a project that was a good fit for WordPress VIP. Over the past four months we’ve engaged with the VIP team launching the project into a closed beta a few weeks ago. The fuzzy details of what’s required to host a VIP site are now vivid. I’ve developed better coding habits as a result. As the VIP platform continues to grow (especially with “WordPress VIP Go” rolling out–more on this later) I suspect more developers will be in my position—entering into a VIP project with a vague understanding of how things will unfold.
This post aims to detail both my experience and lessons learned while working with the VIP platform and team. I hope this will help you decide if VIP is a good fit and leaves you better prepared if it is. First, some very general background on the project.
The primary driver to use VIP was the need for an
Tips and insights for WordCamp (or other conference) organizers after two years of lead organizing and two years of co-organizing.
I am writing this a few days after WordCamp Ann Arbor 2015. This was the second WordCamp where I was a lead organizer and the fourth WordCamp to which I provided overall assistance. Based on the feedback we have received thus far, WordCamp was a success. Attendees learned and networked, sponsors were able to support WordPress and get in front of the community, and speakers shared their knowledge and expertise. Since this is the fourth WordCamp I have helped run, I have a clear idea about the most important factors for the camp’s success and what things could have been done to make the next WordCamp even better.
Rather than keep the lessons learned inside my head, I figured others might find them valuable, thus this blog post. I’ve organized this guide based on the order of importance, meaning the most important lessons appear first. Without further ado…
You can pull off a WordCamp in two months, but who wants to attend a rushed camp? If you can’t start early, set a date for next year.
I’m writing this post less than one week after our last WordCamp and we’ve already started scouting locations and begun the application process.
Last year, we waited a few months before starting
Many first WordPress interactions start with a common question, "Are you a designer or a developer?" These two categories get most of the respect and attention, ignoring an under represented but massively important group in the WordPress ecosystem. The WordPress assembler is often overlooked and doesn't have a title that speaks to their skill.
Having recently returned from WordCamp US, I find myself wondering if we’re not paying enough respect to an important part of our community. Having met lots of new people, I noticed that how one uses WordPress comes up within the first few minutes of conversation. Many of those I met responded by saying they were a designer, developer, blogger or end-user. There was a group however that would struggle to describe what they were, often citing that while they weren’t a designer or developer they provided business with WordPress solutions or consulting. I see two problems with this situation. First, the group often seemed embarrassed to admit they weren’t didn’t design or develop. Second, they had no idea what to call themselves.
More than Instruction Followers
This group has loosely been referred to as the “WordPress Assembler,” which is an adequate but less than stellar title. From my perspective, it has a slightly negative connotation. It describes a process rather than a skill. You might as well call them “WordPress Instruction Followers.”
But let’s address the first problem. People who know how to solve complex problems without cracking open Photoshop (or Sketch) or writing a line
A simple tutorial on how to restrict access to a custom post type using roles in WordPress. It shows how to use custom capabilities and add those capabilities to specific roles. It is a bit older, but I found it pretty helpful today.
Custom post types extend the capabilities of WordPress in terms of what types of content can be published and managed, but these days at 3.7 we find ourselves working on projects that need more granular permissions related to custom post types. The most common situation I’ve run into is a particular user (or group of users) needs the ability to manage specific custom post types but shouldn’t have the ability to alter the rest of the site. For example, you may have someone in an organization that needs to manage job listings (a custom post type) but shouldn’t be allowed to edit posts or pages.
For this example, I’ll base the situation off our project management plugin Panorama. Many of our customers need users to manage projects, but don’t want them to have access to any other types of content. There are some good tutorials out there, but many of them are a few years dated and I found a slightly updated approach was necessary to make this work.
What We’re Aiming For
In the case of Panorama, we wanted our “projects” custom post type to be managed by Editors, Administrators and a new role of “Project Managers.” Project Managers
Does your website plan start with budget, timeline and features? If so, you're focusing on tactics when you should be thinking about strategy. In this article we cover the most effective way to plan a website redesign including the three key elements you need to focus on first.
There is no greater factor in website success than the planning phase. You might be tempted to start planning with consideration to time, budget, and functionality, but doing so is putting the cart in front of the horse. Before you can figure out what you need to spend, how long it will take and what features the website needs you first need to decide what success looks like. Surprisingly enough, this critical aspect of planning is the most neglected. Your plan can only be successful through an understanding of all involved players; specifically, the needs of your stakeholders and target audience. The needs of these two groups should dictate what features are needed, which will inherently inform subsequent budget, timing, and other key considerations.
We’ve established understanding stakeholders and target audiences comes first. What is the best way to get started? I recommend looking at stakeholder needs first–let’s dive right in.
Stakeholders and Objectives
There are certain outcomes you expect from your website whether you’ve clearly identified them or not. Some common examples include acquiring new leads, increasing sales, building awareness, or reducing support overhead. Your website
Some thoughts on the value of custom solutions for business workflows and if WordPress is a viable platform to use.
WordPress was originally built for blogging. Eventually it evolved into a content management system. Now, many say its future is an application framework. It’s now quick and easy to assemble rich functionality using structured data, user management, and integrations with other platforms. There have been many discussions about using WordPress for consumer targeted applications, but little about internal tools for business which begs the question, “is WordPress not a suitable fit”? Or is the topic infrequently discussed? I have my own thoughts about it, but first let’s see if it’s worth building an internal application at all.
Why build a business application at all?
Before considering if WordPress is a good fit we must consider if you need a custom application for your business in the first place. After ten years of working with all shapes and sizes of businesses, I’ve learned that everyone has a unique approach to what they do. Two companies providing the same type of product or service might have commonalities in outcome but their process leading up to the end result is dramatically different.
There is a myriad of existing tools that handle core
WordPress gives us a lot of control over scripts and styles through the wp_enqueue_scripts action, but sites with a lot of assets require reusing the same wp_enqueue_script and wp_enqueue_style functions. Thinking through a less repetitive way of handling the enqueuing of assets.
WordPress has several handy functions for granular control over external assets. Specifically wp_enqueue_script(), wp_register_script(), wp_enqueue_style(), wp_register_style(). These functions allow us to register assets so they’re available and can be added to the page where applicable. While these functions give a fair amount of control, if you have a complex site you can end up repeating the same four functions over and over again. This not only contributes to visual clutter it increases the likelihood of making a mistake like a misplaced argument or typo.
Realizing this at 3.7 DESIGNS, we started looking for a better way to handle asset registering and enqueuing. What we came up with is as follows.
Rather than repeating wp_register_ and wp_enqueue_ for each individual asset, we decided defining all the assets once via a multidimensional array would cut down on needless repetition and code bloat.
Each asset is defined using a nested array with keys for the relevant arguments passed into wp_enqueue__ and wp_register_. Let’s look and see what’s required to register a script.
We need a handle, file path, an array of dependencies, an optional version number,
Getting design feedback can be a painful and frustrating process. Typically frustrations stem from what happens before any design actually starts. This post discusses ways to tease out the most important elements of a website and establish expertise before you start designing, reducing headaches down the road.
The design phase used to be the most time consuming part of our project but now it’s the smoothest. Where we once sought buy-in along the way with wireframes, style tiles, and finally two finished design concepts we now only deliver a single, fully fleshed out concept. While internally designing with the same tools, we’ve honed our outward facing process so we only need to show the client our single, best idea. We rarely receive significant revision feedback, despite lack of client buy-in leading up to the delivered concept. Clients feel that we’ve delivered solutions that fit their needs and need little, if any, adjusting.
How is this done consistently? Our design discovery process. By the time we’re done performing design research, we have a complete understanding of the organization and their needs for the project at hand. Furthermore, we’ve structured the process to convey both expertise and intention. We make it clear that every design decision is based on experience and thought which builds trust and limits feedback born out of personal preferences or emotion.
So what’s our secret sauce? Read on and I’ll tell you more about our design