Developers who are new to BuddyPress sometimes find BP templates confusing to work with. Common questions include: Why are there so many? Where do I place the files? How can I override the templates in my project?
BP Project Framework is a plugin from the folks at WebDevStudios that provides a boilerplate for new custom BuddyPress projects. Essentially, it adds all the BuddyPress templates you need in the convenience of a plugin.
BuddyPress has included WordPress theme compatibility since version 1.7, which means that you can activate the plugin and it will work with nearly any theme. However, if you want to customize BuddyPress-specific features, you will need to override the BP templates. Ordinarily, you would copy those templates from the BuddyPress plugin folder into your theme folder. BP Project Framework allows you to skip this step by creating a new template stack.
The plugin includes all of the necessary BP templates in the /templates directory and customizing any of those files will override the core templates. You can also place custom JS and CSS in
/templates/js/bp-custom.css respectively. The /inc directory includes files for placing custom actions, filters, template tags, and widgets.
The bp-custom.php file contains example code for easily customizing BuddyPress. If you’re new to BuddyPress development, you’ll want to check out that file to get an overview of some quick customization options.
The advantage of putting BP templates into this plugin over building them into the current theme is that you can easily activate and deactivate the plugin. It also allows you to maintain your templates if you decide to change themes, without having to move the template files.
When you have the BP Project Framework installed, BuddyPress will first look to the plugin for its template files and then will default to BP core if any are missing. Simply activate the plugin and start adding custom code, edit the template markup and add custom CSS and JS. The plugin has no settings, but the development team at WebDevStudios plans to add some new features and options in the future.
You can find BP Project Framework on GitHub. It’s a great resource for new BuddyPress developers who want a quick start for adding custom code and working with BP templates.
A recently published article by WPBeginner explains how to export email address from the comments and import them into a mailing list. While the article advises getting the user’s permission, everything about this practice rubs me the wrong way. If you’re going to do this, please put a big banner near the comments that states your intentions. A quick and easy way to do this is to use the Show Comment Policy plugin by Jimmy Peña. The comment policy text will be displayed above the commenting area.Show Comment Policy Settings
I’m most concerned about sites that export email addresses from existing comments. At least give those people the common courtesy of being notified and provide them the option to opt-out immediately. In fact, it may be against the law in certain countries to outright harvest the email addresses. Better yet, instead of getting involved with this practice, just turn commenting off on the site.
Are you ok with the email address you gave to a site in order to leave a comment, being added to an email list as long as you’re notified?
When you have a question about a WordPress theme, where do you look for more information? Theme developers make use of a myriad of documentation methods, from bundling docs to linking to external resources. If you’ve already created a theme and taken the time to document it, then your next challenge is to make its documentation easy to discover.
When documentation isn’t readily available, users will take to the forums to get answers to common questions that could have easily been outlined in a few quick notes. This increases your support burden and causes delays for users who are trying to customize your theme. Let’s examine a few ways to make theme documentation easier to find.
Themes hosted on WordPress.org tend to enjoy a large audience and have guidelines to protect their large user base. I spoke with Chip Bennett, who heads up the WordPress.org Theme Review team, to find out how WordPress.org recommends documenting themes. These recommendations are helpful even if you’re documenting a commercial theme or one not hosted on WordPress.org.
Where is the best place for a WordPress theme author to place documentation so that their users can easily find it?
Bennett’s advice, as quoted below, includes a combination of four different methods:
Now that we’ve covered where to place theme documentation, what should be included? Bennett recommends that you start with licensing attribution and use documentation to explain setup and anything out of the ordinary.
“Some best practices for theme documentation include explicitly stating the copyright/license attribute for all resources bundled with the theme, explaining any unusual/non-standard setup instructions for the theme, and explaining any non-core-UI theme functionality,” he said. “For inline documentation, I strongly encourage developers to follow the phpDoc standard, which improves readability, and allows for automation of generation of theme documentation.”
Best practices for theme documentation are not unduly strict, in that you can utilize virtually any route you choose, extending beyond the four methods recommended by the Theme Review Team.
“Almost any method of documentation is encouraged,” Bennett said. “Theme developers can certainly bundle help docs with their themes. Some use plain-text readme.txt or readme.md files; others use HTML files, rich-text documents, or even PDFs,” he said.
“The only downside is that there is no standard/easy way for the end user to find/use those documents,” Bennett cautioned. “Again, the Contextual Help API could be useful (it can be used to display rich text/HTML, or to link to a Theme-bundled PDF, for example), as well as the Theme URI.”
Bennett also notes that the way you choose to implement theme features will directly affect how much documentation you need to produce. “Another important best practice is always to incorporate features using the WordPress core implementation, so that fewer such features even need to be documented,” he said.
“For example, when implementing custom header images or custom backgrounds, using the core implementation provides a standard, intuitive UI for the end user. Similarly, when implementing a custom static front page, or a custom blog posts template, properly implementing the Template Hierarchy will avoid the need to provide instructions for a non-standard implementation of those features.”
Bennett offered a few examples of themes that have solid easy-to-find documentation. He developed his Oenology theme with excellent documentation as an intentional goal. The Oenology options page makes use of the contextual help tab to provide additional information on settings, FAQ, a changelog, support, and licensing.
Theme developers can check out Oenology theme files to see how Bennett incorporates documentation into the theme itself. He also recommends Underscores as a well-documented theme.
WordPress.org plugin authors have the option of adding additional documentation to the FAQ and Installation tabs. When I spoke with Bennett, he explained that theme authors do not yet have this capability.
“The Theme Directory is much more limited because, while the Theme and Plugin directories look essentially the same on the front end, they are two entirely different beasts under the hood,” he said. “The infrastructures are different. That said, there will be some changes in the (nearish?) future, that will allow the Theme directory to emulate the same (or similar) functionality, based on a standard readme file format.”
The Theme Review Team will be discussing how improvements can be implemented, but it’s not yet clear what those changes will look like. In the meantime, theme authors can make use of the solid documentation recommendations Bennett outlined.
Good documentation requires a little bit of strategy to find the best way to connect with your users when they need help. Chip Bennett’s tips are useful to all WordPress theme authors, whether you’re creating a custom theme for a client, selling a commercial theme, or supporting a free theme on WordPress.org. A combination of approaches via the readme.txt, inline documentation, contextual help and external docs at the Theme URI will cover all your bases.
Take the time to create high quality documentation and you’ll find that the burden of support will decrease. As a WordPress.org theme author, I’d prefer to spend my time making updates and developing new features and themes. Using WordPress core implementation for features and providing good docs is the best way to free up your time to do more of the fun stuff – creating beautiful themes that users will love.
After using WordPress for seven years in a row, it’s hard to consider switching to another publishing platform. I have my gripes about WordPress and there are plenty of things that can improve the publishing process. However, after testing a few other open source alternatives, I was reminded of how many things I take for granted in WordPress. Here are seven WordPress things I take for granted.
For the longest time, the visual editor in WordPress has been the bane of existence for so many users. It has a reputation for screwing up code snippets and ruining the formatting of text. In the past two years, there have been several improvements to the editor that make it my favorite way to write a post. These are just a few of my favorites, some of which are slated for WordPress 4.0. oEmbed support, oEmbed previews, sticky toolbar, automatic resizing based on the amount and type of content, and the ability to easily edit inserted media.
After using a few different themes, I’ve determined support for visual editor styles to be a killer feature. If executed properly, content within the visual editor looks the same as it does on the frontend of the site. After using a theme that executes this feature properly, it’s hard to use a theme that doesn’t support it.Visual Editor In WordPress 4.0 With oEmbed Previews
As far as I’m concerned, any content management system that doesn’t have an easy way to upgrade within the software is stuck in the past. WordPress 2.7 “Coltrane” introduced the ability to upgrade WordPress with one click. Gone are the days of manually uploading files via FTP. Being able to upgrade plugins, themes, and WordPress with the click of a button is a huge time saver. If you want to fully automate the process, you can configure WordPress to automatically update core, themes, and plugins.
Considered a negative by some, I think the large amount of free themes and plugins to choose from is a huge benefit. It gives users across the world a chance to turn WordPress into their WordPress. Because of the wide assortment of themes and plugins available, the chances of two WordPress installations being exactly the same are slim. Sure, there is a lot to choose from, but I’d rather have too much choice than too little.Plugin Count As Of July 29th, 2014
Despite Akismet not being 100% accurate in determining who spammers are, it’s saved me a lot of time (24 days to be exact) and grief. It’s available for free for non-commercial use and ships with WordPress. There are plenty of alternatives to handle comment spam but I’ve never had a reason to switch. Other content management systems I’ve tested either don’t have an anti spam solution built-in or are tied into the Akismet service. At the time of writing, Akismet has protected the Tavern from 109,288 spam comments with an accuracy rating of 99.19%.Akismet Stats For The Tavern
Being used on over 22% of the web has its perks. If I don’t know how to do something with or in WordPress, the answer is usually a Google search away. Someone has either written a tutorial or knows about a plugin that has the functionality I’m looking for and a lot of the information is free of charge.
The WordPress community is global. People all over the world are helping each other go farther with WordPress. People who don’t know each other are showing up to local area meetups and becoming best friends. I’ve seen first-hand veterans of the community stop what they are doing and provide a helping hand. More often than not, if we see someone struggling with their WordPress website, we do what we can to help them.WCSF Contributor Day
Notice how I didn’t say improving the software. That’s because WordPress is more than just software, it’s like a big tree with several branches. There are a ton of people all over the world helping to make the project better through individual and team contributions. Most are not paid but simply want to improve their favorite part of the project. This includes documentation, organizing meetups, WordCamp planning, improving the core of WordPress, and other initiatives.
Many of the contributions go unnoticed and contributing to WordPress can be a thankless job sometimes. Not every contribution is world-changing; some are more important than others. The bottom line is, every contribution no matter how small, makes a difference.
@wptavern not code related, but the thousands of volunteer hours and personal sacrifices that go into making it great.
— Ryan D. Sullivan (@ryandonsullivan) July 30, 2014
@wptavern The installation and upgrade process. Other pieces of software are an absolute nightmare compared to WordPress.
— Philip Arthur Moore (@philip_arthur) July 30, 2014
@wptavern beautiful hook system, plugin api, theme system, and install system for core, themes and plugins. Next inline would be admin UI
— Jeff Behnke (@validwebs) July 30, 2014
@wptavern Still have to go with CPT's and the ease of creating them.. It really I think what drove WP from "blog" to "CMS"
— RoyBoy789 (@royboy789) July 30, 2014
@wptavern You can type anything into google followed by "WordPress" and someone has already asked (and answered) it
— Jared Novack (@jaredNova) July 30, 2014
@wptavern : Licensing GPLv2+
— VibeThemes (@VibeThemes) July 30, 2014
@wptavern If you can dream it you can do it in WordPress.
— Teri Williams (@teri_williams) July 30, 2014
What aspects of WordPress do you take for granted?
CMS Critic, a popular website covering the content management system market, has switched their website from WordPress to ProcessWire. ProcessWire is a free, PHP based, open source, four-year old, content management system maintained by Ryan Cramer. CMS Critic cites the following reasons for moving away from WordPress:
Their number one reason for leaving WordPress is bloat but their explanation of bloat is different from most I’ve read.
WordPress; like a lot of CMS platforms; relies heavily on plugins for extra functionality over and above the core services. The main issue, however, is that these plugins are not actively vetted out (or tested) by core team members to ensure they use optimized code and are safe for your site. This means that by installing a plugin, you can bring down your whole site and cause yourself mountains of headaches all because you wanted to add some extra functionality.
The bloat they speak of is not from the core of WordPress, but due to the number of plugins they installed. They are the ones responsible for the bloat, not WordPress. While they raise a good point about plugins not being vetted from a code quality stand point, they are vetted to make sure they don’t contain security vulnerabilities and follow the WordPress plugin directory guidelines.
According to CMS Critic, Cramer reviews most of the modules before they end up in the official directory. He gives developers a list of improvements and advice that helps limit the potential of modules conflicting with each other. The review process has helped keep problems stemming from modules to a minimum but I don’t see how it can scale. If the CMS ever reaches the point of receiving 20-50 modules per day, Cramer will need to find help or risk losing precious development time.
As for updates, each plugin and theme installed in WordPress increases the chance you’ll see an upgrade notice each time you login to the backend. Despite upgrades being as easy as clicking a button, having to go through the process every day can become cumbersome. CMS Critic makes a good point in that you can’t tell the difference between a critical update and a bug fix release. As far as the user is concerned, every update is critical.Looks Like I Have A Few Plugins To Update
While most plugins have a changelog where you can see what changes are in the latest release, themes do not. This is something that will be addressed when the WordPress theme directory receives a major overhaul. Even if a change log is available, it’s not always clear to the user if the update requires immediate.
What makes all of this a moot point is the security advice of always run the latest version of WordPress which could be extended to plugins and themes. If you follow that advice, it doesn’t matter whether an update is critical or not. There will likely never be a system in place to determine the importance of an update because it creates another layer of complexity involving a decision that shouldn’t be complex at all.
The development philosophy of “iterate and release often” works fine for services like WordPress.com, but not so much for WordPress, themes, and plugins. Coen Jacobs wrote an excellent post explaining why not all WordPress plugins should iterate quickly and release often.
Of course, it’s a great thing to be able to develop new features at a fast pace, be able to quickly deliver this to your users (or to add an extra layer of complexity: to your customers) and release a couple fix releases in the time between. But it also requires your users to deal with this number of updates, or they might be at risk of falling behind or have potential security issues in their websites.
Update fatigue is a real and should be avoided if possible. The problem is compounded as the number of installed plugins increases. I’d like more plugin developers to come up with a better release strategy instead of sending out an update as soon as they’ve fixed a bug. Beginning with WordPress 3.7, users have the ability to automatically upgrade core, plugins, and themes. However, turning on automatic updates because a plugin is updating too much is a poor reason to use the feature. It’s worth noting that automatic updates are impossible for certain sites to use such as eCommerce or those that use version control to verify updates before they go live.
In order to see what all the fuss is about, I installed ProcessWire on my local server. Installation is easy and didn’t require me to edit a configuration file. Here is what a sites looks like after a fresh install.ProcessWire Fresh Install
The backend of ProcessWire is simple but coming from WordPress, is like being on a new planet. Everything I’m familiar with in terms of creating content is missing. I can create pages but from a background of knowing pages are more for static content, I’m not sure if that’s the optimum method of creating content. There’s no welcome screen, no signs of help if I need it, and it quickly becomes obvious this is created by developers, for developers.The Backend Of ProcessWire
After using the CMS for 30 minutes, I promptly gave up trying to do anything cool with it. ProcessWire has a modules directory to add functionality to the platform but it’s not accessible from within the CMS without the modules manager.
ProcessWire comes with a lot of bundled modules that can be turned on or off. This allows you to specifically determine how much functionality your site has. Over the years, there have been several discussions on whether WordPress should start moving its feature set into separate plugins. This is where I appreciate the decisions, not options philosophy of WordPress. I’d rather be given a strict feature set and then add-on to it with plugins. I couldn’t care less about enabling/disabling core functionality but I understand how this is a great feature for developers.Module Management In ProcessWire
ProcessWire is based on the premise of everything being an API call away. “Underneath, ProcessWire 2 is a purely API-driven content management framework that is fully functional without any sort of admin interface.” WordPress is steadily moving in the same direction, especially once the JSON REST API makes its way into core.
I’m happy to see another GPL licensed project gaining steam and finding a place all its own. The community is active and the main developer has over 8,000 forum posts. They also have a showcase filled with websites using the software. If you’d like to check out ProcessWire for yourself, they have a demo available which shows an already created, public facing website. You can also log in to the backend to see how it looks and functions.
If I were going to switch from WordPress to another publishing system, ProcessWire wouldn’t be my first choice. There are several reasons why. First, I’m not a user within their target market. Second, most of what I want out of a publishing system it doesn’t have out of the box. If it does, it’s not obvious. Last but not least, because of the way ProcessWire functions, it doesn’t have a way to install new themes for the frontend of the site. Great for developers, terrible for users.
Several of the reasons CMS Critic moved from WordPress I think are benefits, not detriments to the project. It’s great that they’ve found a project that is more in line with what they need but with the nature of evolving software, how long will it take before iterations and improvements have them looking for yet another CMS to switch to? In most software projects, end users far outnumber developers. I get the impression that most of the users for ProcessWire are developers. If the project doesn’t decide to cater to end users, I don’t see it ever becoming much more than an addition to a developer’s toy box.
There are plenty of things that need improvement in WordPress, but after using ProcessWire for 30 minutes, I was reminded of how many things I take for granted. More on that in a future post.
What do you think of ProcessWire? Is it something you can see yourself switching to or building client sites with? What parts of ProcessWire can be used as inspiration for future improvements in WordPress?
As the engineer and writer Alex Payne put it, these startups represent “the field offices of a large distributed workforce assembled by venture capitalists and their associate institutions,” doing low-overhead, low-risk R&D for five corporate giants. In such a system, the real disillusionment isn’t the discovery that you’re unlikely to become a billionaire; it’s the realization that your feeling of autonomy is a fantasy, and that the vast majority of you have been set up to fail by design.
Vietnam is getting its first WordCamp on September 6th, 2014. WordCamp Hanoi was born out of the Hanoi WordPress Group, an active local meetup with nearly 300 members. The group connects WordPress enthusiasts in the area for relaxed chats and presentations. As of last month, WordPress is now 100% translated into Vietnamese, and some of the meetup members were active in helping to reach that goal.
WordCamp Hanoi is set to have three presentation tracks to include the business side of WordPress, using WordPress, and developing for WordPress. The call for speakers is open and applications will close on August 11. Organizers are looking for volunteers to help with food, shopping, creating speaker gift bags, designing and organizing badges, and all the other behind-the-scenes magic that powers WordCamps.
The Hanoi WordPress Group has been meeting for the past two years and its members have created a friendly atmosphere for connecting with other local enthusiasts. Philip Arthur Moore, one of the organizers of the event, is hoping that same atmosphere will be part of Vietnam’s first WordCamp. “Our goal this year is to keep the event simple, cozy, small, and familial, something that our group has done a good job of maintaining since its 2012 start,” he said.
WordCamp Hanoi will feature a diverse range of presentations to interest as many different kinds of WordPress users as possible. If you’re planning on being in Hanoi during September, watch for the ticket announcement so you don’t miss this historic WordPress event.
Many Google Maps plugins have a convoluted admin workflow for creating locations in WordPress. Some of the clunkier solutions actually require you to look up longitude and latitude coordinates to manually input for pinpointing. Very few maps plugins utilize custom post types to provide a user-friendly input.
Stellar Places is a new plugin designed to provide an intuitive way to create, manage and display locations in WordPress. The plugin registers a custom post type for locations with integrated Google maps. Once activated, a new Places menu shows up in the WordPress admin:
Scroll down to enter location data, which is pulled in via Google Maps. You can enter an exact address, just the cross streets, exact coordinates, etc. There’s a good deal of flexibility in entering a location to pinpoint. The map and extra data fields are automatically updated with your location, without refreshing the page.
Places added can be accessed on the front end via the location listing view or single location view with the associated maps. Maps can be inserted into a page or post using the
[stellar_places_map] shortcode. Stellar Places also allows you to display multiple locations on the same map.
The shortcode for embedding places is extremely customizable and includes parameters for customizing HTML attributes, such as ID, class, width, and height. It also includes query parameters for limiting the display by post_type, taxonomy, term, category, and post_id. Shortcode map settings allow you to specify latitude/longitude for the map center, mapType, scrollwheel, zoom, minzoom, maxzoom, and infowindows.
The plugin is also mobile-friendly and produces responsive maps that are easy to navigate on devices. This makes it ideal for featuring local events, divided by categories. You could also use it to create a store locator for businesses that have multiple physical locations. Each location gets its own dedicated page and will automatically appear in the list of all locations.
Stellar places features include:
In the future, the Stellar Places development team plans to build extensions for the plugin that you can install to gain additional functionality.
An easy-to-use maps plugin that looks and feels like native WordPress is long overdue. I tested Stellar Places and found that it works as advertised. The process of adding new places is intuitive and maps can be tailored to your exact specifications with the many options available in the shortcode. If you’re looking to try a new Google Maps plugin for WordPress, download Stellar Places for free from WordPress.org.
While there are many excellent plugins that make migrations easier for developers, WordPress migration as a service hasn’t been widely marketed. MigrateWP is a new business dedicated solely to providing smooth, painless migrations for people who don’t have the skills or time move a site from one host to another. Pricing starts at $200 and includes DNS migration and a free site audit. Larger and more complex migrations range from $300-$750.
Founder Daniel Griffiths describes MigrateWP as a curated migration and conversion service for WordPress. Griffiths is best known for his work as an Easy Digital Downloads extension developer and is also the founder of the Redux Framework. During the course of his work, he found migrations to be a source of continual frustration for the average WordPress user.
“The idea came about as a direct result of a series of issues posted in the Easy Digital Downloads support forum related to migration issues experienced by one of our users,” Griffiths said. “I came to the realization that no matter how well documented, migrations suck! Even for someone who’s done a few, they’re a headache and for a new user, they’re downright impossible.”
After researching the problem, Griffiths found that there are very few resources available to facilitate site migration, let alone conversion, for end users who aren’t technically inclined. “Yes, there are a few other services, but they all suffer from one fatal flaw: automation,” he said. “MigrateWP was built on the premise that no matter how well thought out, automated systems can’t compare with the reliability that manual processes can.”
Griffiths hand-tailors the migration process for each user’s unique scenario, and all migrations are completed hands-on by specialists with a high level of experience. This enables MigrateWP employees to ensure data integrity and customer satisfaction.
“Beyond the basic migration component, we do site conversions, full site auditing, and every migration is run through malware checks both before and after the migration process to ensure the client receives a clean site when the process is finished,” Griffiths said.
Customers often have no idea how much information they will need to provide access to in the course of a migration. I asked Griffiths how he plans to simplify the process of interfacing with his clients’ old and new hosts. “Before the migration begins, we personally contact every client to work out the details of the migration,” he said. However, the initial contact on the website is designed to be quick, without attempting to capture all of the information required.
“Our client contact form is extremely simple for a reason,” Griffiths said. “Particularly in the case of companies, it’s unreasonable to expect a single individual to know all the details up front. After all, companies frequently have multiple employees responsible for various facets of their tech. This may well include different people responsible for the physical hardware as opposed to software, or corporate staff changeovers.”
Griffiths’ team first performs a site review and engages each potential client directly to get a grasp of the actual migration before proceeding. He is aiming to hire a 5-10 person staff within the first year.
In the future, he hopes to attract developers to utilize his service, in addition to assisting end users who don’t have the skills to migrate their own sites. Any capable WordPress developer should be able to easily handle an average site migration, but Griffiths hopes to free up their time by creating agreements with development agencies or hosting providers to manage their client migrations.
The commitment to provide a more personalized migration experience with no automation is what Griffiths hopes will distinguish MigrateWP from its competitors. Many hosts already offer free automated migration when you sign up for a new account. Do you think end users are more likely to utilize a dedicated migration service or will MigrateWP find more success among developers and agencies?
wpgo.go is a command-line tool to interact with WordPress blogs, written in Google’s Go language. It’s cool to see this new generation of apps built on WP.com + Jetpack’s new APIs, like Postbot.
Welcome to the fifth “Week in Review” on Post Status, where I hope to offer up some of the things you may have missed in the last week or so.
A long-awaited feature, the first pass at introducing Sass to the Underscores (_s) theme has been committed. This morning’s commit by Tammie Lister follows a number of much-discussed Github threads, and it looks promising. The Sassy version of Underscores is in its own branch, if you want to explore it further and get started with that version right away.
I’ve been using my own forked version of Underscores for some time now, that includes Sass, and I’m happy to see this change. I look forward to comparing their version with my own and learning from it. Underscores has become one of the most popular WordPress themes to build custom websites from, and this is a great change.
If you don’t think you’re ready for Sass, Josh Pollock has a nice post on Torque to help you out.
Furthermore, he started a Github repo for a community-based, unofficial standards document. This is exactly the type of discussion that I hoped would occur, and I encourage you all to get involved. If enough of us encourage standards for some common custom content types, we can make portability between WordPress themes even better, and that would be great.
The first issue is to decide what post types to standardize, so go get involved.
Also along the standardization theme, WordPress.com has introduced a feature for theme developers to create standard support for site logos, a feature that’s in almost any WordPress theme.
The feature is live on WordPress.com, and coming to a Jetpack near you. WordPress.com added support for about a dozen themes for the launch of the feature.
On July 1st, Sucuri disclosed a vulnerability in MailPoet, a very popular WordPress-centric newsletter plugin. Over the next few days, MailPoet released a variety of updates. A bunch of WordPress websites were estimated to be hacked. Updates were available, and many hosts made server level changes, but it affected every version and was a serious issue.
However, MailPoet was unsatisfied with how Sucuri handled the disclosure, and posted some lessons learned on their blog a couple of days ago. That post is worth reading on its own, but essentially they’re displeased at the rapidity of Sucuri’s actions from notification of the vulnerability to publishing the news on their blog. Sucuri says it was standard practice, and give a rundown in an open letter to MailPoet on their own blog.
When your primary software product has something like this happen, your emotions definitely tick up a notch or three. I can see both sides of this story. In the end, it’s important that the fix gets in and site owners and hosts get notified so they can get their sites fixed. I don’t know who is more correct in this story (I haven’t given it enough thought, honestly), but I think most things are better settled in a different venue than trading accusatory and pointed open letters — something both parties are guilty of here.
Oli Dale has some really interesting insight where he raises the hypothetical, “If I were to start a blog about WordPress today.” He highlights how he thinks some genres (like WordPress news) are well covered, but that he sees a great deal of potential in more niche markets.
Definitely read Oli’s advice if you’re looking to start a blog. Also keep in mind, really there is so much opportunity, no matter what you see out there today; just do it better than anyone else and you can succeed. (Notable on this topic, WP Scoop just rebranded itself)
Related, but more general: You are not late.
Zack Katz has released GravityView, a plugin that takes Gravity Forms submissions and lets you put them anywhere on your site. This plugin look really slick, and I see a lot of potential uses for it.
Zack is the developer of the free Gravity Forms Directory plugin, and GravityView is a different plugin, but expanded version of that. Zack talks about GravityView and his thinking behind it on the latest Apply Filters podcast, which he recorded right before he released the plugin.
Iain Poulson wrote a fun little post about how he’s automated most of the work that goes into WP App Store, a former marketplace product turned email deals product.
Brian Richards has left his position at WebDevStudios to attempt a full-time career building WP Sessions, his WordPress learning website.
As I noted last week, he’s giving away a $2,000 value trip to WCSF to those that sign up for his VIP program, and there are still a couple of days to enter.
He also just released a course on building WordPress plugins, which Pippin Williamson is teaching; it doesn’t get much better than that. I wish Brian the best of luck, and hope WP Sessions sustains him.
I guest posted on the WordCamp San Francisco blog, where I talked about my first experience at WCSF. Incredible relationships and experiences are made at WordCamps; this is my story.
Along a similar vein, Christine Rondeau answers, “Why bother with WordCamps?”
I’m really excited to attend WordCamp New York City Friday through Sunday. If you’re there, I’d love to meet. The lineup of attendees and speakers is insane. I’ll also be doing some hallway interviews, so Post Status readers will hopefully enjoy the results of those. I’ll probably be singing Alicia Keys to myself for the next few days, so you can have that mental image for free.
It’s not quite midnight on Monday in Alabama, as I wrap this up. So while the week in review is a bit late this week, I hope you still enjoyed it and learned something new. If you did, I of course appreciate if you’ll share it with your social network of choice.
Have a great week everyone.
This Friday at 3PM Eastern, we’ll be joined by three individuals to discuss the topic of crowdfunding. Crowdfunding is defined as “the practice of funding a project or venture by raising many small amounts of money from a large number of people, typically via the Internet.” While some projects fail, others are exceedingly successful.
Our guests will share their experience, lessons learned, and what they would have done differently. We’ll also discuss the impact of crowdfunding open source software development.
Crowdfunding enables people to not only gauge interest in an idea or product, but also allows them to receive funding without having to deal with venture capitalists or banks.
If you have any questions for our guests, or about the topic of crowdfunding, feel free to post them in the comments.
A WordPress community initiative is underway to standardize content types used by plugin developers. Justin Tadlock is spearheading an initiative to create WordPress community-curated standards for common post types, taxonomies, and metadata.
WordPress developers are invited to join the discussion taking place in the Content Type Standards repo on Github where Tadlock outlined the objective: “The purpose of this repository is to create an open set of standards for the WordPress developer community on how to name custom post types as well as related taxonomies and metadata.” This would include common post types, such as testimonials, portfolios, recipes, FAQ, events, and products.
Tadlock, who has historically been a vocal advocate of data portability, is hoping that the standards will enable users to painlessly switch between plugins that compete in the same space, without losing any data. Standards will also make it easier for developers to build extensions in such a way that they can be more widely adopted by theme developers. He identifies a few benefits that both users and developers would enjoy as a result of content type standards:
The project will first be focused on establishing a set of standards for plugin authors to follow, based on the core WordPress methods. Tadlock also suggests a secondary goal of creating a few PHP scripts for developers to copy/paste for registering a post type or taxonomy that make use of the new standards.
Brian Krogsgard recently published an article calling for Jetpack and WordPress.com to lead the way toward standardizing custom post types. While Jetpack and WordPress.com are in a good position to lead the way on this, there are many community developers outside of Automattic who have valuable input to offer on the creation of a truly open set of standards.
In a recent article that outlines the need for custom post type standards, Tadlock argues that standardization goes far beyond simple naming conventions:
People are still using their own, separate code rather than adopting existing solutions, preferring a solution built in-house instead of joining together with others. That’s the reason we don’t have standards. It really has little to do with post type naming conventions.
The idea behind the community-curated standards is to help WordPress developers work together without the need to reinvent the wheel every time with their own solutions. Instead of closing off products with naming conventions that won’t be able to transfer users’ data, Tadlock encourages developers to work on creating plugins that become standards in their own right.
Standards are created after we’ve made them and they’ve been adopted by enough people. In other words, we create standards by building good plugins, getting users to install them, and having theme authors integrate with them.
The Content Type Standards project is a community initiative that puts users first and helps developers make products that can be more widely used. The first order of business is to establish the post types to standardize so that contributors can then address the naming standards, taxonomies, and metadata for each. If you build products that utilize custom post types, make sure to get in on the discussion happening on GitHub.
Utilizing SSH keys in conjunction with the servers you connect to is a great and highly recommended security practice. SSH stands for “Secure Shell” and enabling SSH for a server creates a secure channel between you (via the command line) and your server.
SSH keys help the server validate and authenticate who you are. SSH servers can even be setup to require a known valid SSH key in order for the server to acknowledge you to begin the login process.
Using SSH from a Linux or Mac system is straightforward. You may not realize it but your system will automagically generate an SSH key for you the first time you use SSH if you do not have one already. This key will then be sent with all subsequent request to that server and all other servers. This is a great start, however it is possible to maintain multiple SSH keys on your system.
If the one SSH key allows you to get into all your systems why would you want additional keys? Simple, extra security.
Having a unique key per system you are logging into will create additional security by only allowing that key to be used on that system and no other. If your account somehow gets compromised and the key to the server taken you do not have to worry about all the systems you have logged into with that key and remember to go secure them. You simply delete the key for that system and generate another.
Managing multiple keys is easy. Let me show you how you can accomplish this on your own system.
This tutorial assumes you have basic knowledge of the command line. It was originally written as part of a series of CLI (command line interface) cheat sheets, and I’m reposting it here so that a broader audience can take advantage of SSH for server management. The CLI cheat sheet has other excellent resources I recommend you check out as well.
All the SSH files live in a hidden folder
.ssh in your user directory. If your system is using the generic key file this folder may not exist. You can safely create this folder yourself. We will be working out of it for the remainder of this tutorial.
We will also be working from the terminal for the rest of this process.
Open up your terminal and get setup.
If you get an error that the directory does not exist create it with:
For this example we will setup keys for two servers: abc.com and xyz.com.
SSH includes a simple utility for creating SSH keys called `
ssh-keygen. The following is an example of what creating a key would look like.
blobaugh@devbox$ ssh-keygen Generating public/private rya key pair. Enter file in which to save the key (/Users/blobaugh/.ssh/id_rsa): [id_rsa.abc.com] Enter passphrase (empty for no passphrase): [Enter a passphrase] Enter same passphrase again: [Repeat passphrase] Your identification has been saved in /Users/blobaugh/.ssh/id_rsa.abc.com Your public key has been saved in /Users/blobaugh/.ssh/id_rsa.abc.com.pub The key fingerprint is: [Long crazy string] The key’s random art image is: [Cool ascii art]
ls into the terminal and you should now see two new key files that have been created for abc.com. Repeat the process with xyz.com.
Passphrases are recommended but not strictly necessary. If you are creating a passwordless login you can hit enter to leave it blank. Later on when we get into the configuration file there are additional login options you can set.
Since you are now a pro at creating SSH keys I suggest you also create a generic key. This key will be used on any systems you login to where you do not have a unique key created.
Likely there will not be a configuration file in your
.ssh directory. This is normal. You will create it in this step.
To utilize your shiny new SSH key with a specific system you will need to create a new entry into the
~/.ssh/config file related to that host. You can use either the hostname or the IP. One key can have multiple entries, so if you have multiple hostnames for one system, or want to use both the hostname and IP to login simply create an additional entry in the config file. The * wildcard can also be used.
To get started open the
~/.ssh/config file in your editor of choice and add the following lines:
Host abc.com IdentityFile ~/.ssh/id_rsa.abc.com Host xyz.com IdentityFile ~/.ssh/id_rsa.xyz.com
That is it! You will now be utilizing a different key for each of those hosts.
Setup the generic key with
Host * IdentityFile ~/.ssh/id_rsa.generic
There are many configuration options available to you in this file. Lets break down a few here.
The Host option is a bit tricky. Host is for the name you use on the command line with the ssh command. This does not have to be a real machine but can be an alias. When used as an alias you need to supply the HostName option as well. Here are a couple examples to help make this more clear.
Host lobaugh.net ….
On the command line you would use
ssh yahoo.com to connect to the machine still.
Host ben HostName lobaugh.net ….
In this example you would call
ssh ben and still be connected to the lobaugh.net server.
Allows you to set the username that is supplied to the connection by default. This can be different than the currently logged in user that is supplied by the system if one is not supplied. This setting can be overwritten at run time on the command line.
Host lobaugh.net User ben
Some servers have a timeout setting that will automatically disconnect a user if they do not perform an action for a specified period of time. This is great for security, however some hosts are a bit aggressive with disconnects and will bump you rather quickly (looking at you MediaTemple). This option tells your client to send keep alive packets to the server so you do not get disconnected too quickly. This setting is in seconds.
Host lobaugh.net ServerAliveInterval 60
This is the key file we created in the beginning that should be used for the connection.
Host lobaugh.net IdentityFile ~/.ssh/id_rsa.lobaugh.net
Allows changing the port number the connection uses for non-standard ports.
Host lobaugh.net Port 5000
A complete list of configuration options can be found at http://www.gsp.com/cgi-bin/man.cgi?topic=ssh_config
Now that we have things on the client side setup we need to let the server know what is happening. This will ensure that the server knows who we are. This is as simple as ensuring the public key is present in the authorized_keys file.
We will use a couple “magic” ssh commands that run remote commands on the server for us.
First we need to ensure the .ssh directory exists on the server or the transfer of the key will fail.
ssh USER@SERVER mkdir ~/.ssh
Now we will send the public key to the server.
cat .ssh/KEY_FILE.pub | ssh USER@SERVER ‘cat >> .ssh/authorized_keys’
You are now all set with multiple unique keys per machine you are connecting into, complete with verification of the key on the server side of things.
The JSON REST API plugin for WordPress released a security update over the weekend. Version 1.1.1 includes a fix for a vulnerability wherein the JSONP support built-in to the API could be used to serve up arbitrary Flash SWF files. This technique has been known to be used in the past to abuse JSON endpoints to allow Flash files to bypass browser cross-origin domain policies.
WordPress core already has CSRF protection, but the WP REST API is oftentimes used in combination with other software which may not have the same protections. You can use a filter to disable JSONP support:
add_filter( 'json_jsonp_enabled', '__return_false' );
WP API project lead Ryan McCue credits Ian Dunn in the release announcement for responsibly disclosing the vulnerability to the team.
The WP REST API project is now available on HackerOne, with a bounty for hackers who discover remote code execution exploits, SQL injection, privilege escalation, and other security issues. The WP-API plugin is listed as a high priority along with the OAuth 1.0a server plugin, which provides authentication for the API.
The vulnerability fixed in version 1.1.1 of the plugin was classified as a minor security issue, according to McCue, and no sites have reported any exploits. He recommends that anyone still using version 1.1 of the plugin to update as soon as possible.
This is an aggregation of blogs talking about WordPress from around the world. If you think your blog should be part of this send an email to Matt.
For official WP news, check out the WordPress Dev Blog.
July 31, 2014 03:30 PM
All times are UTC.