A few weeks ago, it was suggested that Members could use a feature or add-on for restricting access to the WordPress admin. It makes sense. I could see such a feature being particularly useful for sites that already have some sort of front-end profile editing. Ecommerce and forum plugins often offer this feature. Many users on those types of sites should never see the admin.

I decided to go the add-on route because this is a feature that probably won’t be used by most Members’ users. Plus, this will add to the overall Members plugin add-on ecosystem and will be the 4th add-on available.

What does the plugin do?

Members – Admin Access basically allows you to control which users have access to your site’s WordPress admin.

By default, all existing roles on your site will have access so that nothing changes when you first activate the plugin. You simply need to go to the “Admin Access” tab on the Members > Settings screen to change that. There’s a couple of other settings there too for changing the redirect URL and handling the toolbar output on the front end.

The “Administrator” role cannot be blocked out of the box. This is simply a security measure to make sure no one accidentally locks themselves out of the admin.

PHP 5.6+ only

I wanted to make this quick announcement here since this is my first plugin to require this version of PHP.

I’ve officially bumped the minimum PHP version for this plugin to 5.6+. Many other plugins and themes will follow this path going forward. It’s time to move on to newer (relatively speaking) PHP features, which make my life as a developer much better. Anything that makes it easier for me to develop plugins will be better for you, the users, in the long run as well.

So, if you’re not on at least 5.6, talk to your Web host. If they won’t upgrade it for you, I strongly recommend moving on to another host.

And, while you’re at it, see if you can get them to put you on PHP 7.2. You might as well ask for the latest and greatest technology for running your site.

It was about time for a Stargazer theme update. We’ve enjoyed a good stretch of stable code for a while now. In the meantime, I’ve learned new techniques and have come up with better ways of doing things.

That’s what this update is all about. More than anything, this is a housecleaning for the theme.

What’s changed?

Primarily, I updated Stargazer to the latest and most updated version of the Hybrid Core framework. There were tons of improvements to the Hybrid Core code base late last year. I’m happy to be able to bring those into the theme.

The most obvious user-facing changes are going to be with the customizer and editor. In the customizer, I created a separate “Theme Options” panel that houses any theme-specific options. In the editor, I’ve removed the stylesheet integration in favor of integrating with the Gutenberg plugin, which will be the editor that is shipped with WordPress 5.0.

And, frankly, I say good riddance. Editor styles were one of the most troublesome aspects of theme development.

If you still want your editor styles, you might stick around on Stargazer 3.0.0 for a while, at least until WP 5.0 is out and the new editor is in core.

For child theme authors, you shouldn’t have to worry about too much. Just give your child themes a test and make sure they’re working. You’ll probably want to get rid of your editor styles that were auto-loaded by Stargazer (they are no longer). You might also want to register some custom colors with Gutenberg (I’ll post a tutorial on doing that soon).

]]>https://themehybrid.com/weblog/stargazer-version-4-0-0/feed2Christmas 2017 discounthttps://themehybrid.com/weblog/christmas-2017-discount
https://themehybrid.com/weblog/christmas-2017-discount#respondFri, 22 Dec 2017 18:51:41 +0000https://themehybrid.com/?p=10245[…]]]>This is just a quick announcement to let you all know that Theme Hybrid is currently offering a site-wide 25% discount. Anything you purchase here, including a membership plan, is covered with this discount.

All you need to do is apply the XMAS2017 discount code at checkout.

The discount is available until January 1, 2018. I’ve got lots of awesome content planned for 2018. Now would be a great time to grab a membership if you’ve had your eye on it.

I want to thank the community for a great 2017. I hope everyone has a wonderful holiday season this year. I look forward to seeing some fresh faces around here in the coming year.

When I launched the redesign of Theme Hybrid at the end of October, I promised that I’d share my testimonials plugin. This is a plugin that I’ve used for years here on the site but just never got around to releasing to the public.

A few of you who knew about my plans to release Toot probably thought I’d never get it released. I’ve had most of the code sitting a public repo for nearly a year. It’s just one of those things that kept getting pushed to the backburner. But, I’m glad it did. Some of the directions I took with the code benefited from me taking the time to learn and grow as a developer.

And, I’ve got some neat plans for this plugin already lined up for 2018 and the new Gutenberg project that is set to be merged into WordPress 5.0.

What is Toot?

Toot is a plugin for managing testimonials. If you have products or services that you deliver to consumers, you’ll likely want to showcase some of their testimonials at some point. I do that here at Theme Hybrid.

The plugin has all the features you need to get started:

Settings screen to configure your options.

Custom shortcodes for outputting testimonials wherever you like.

Categories for grouping your testimonials.

I built the plugin with the bare essentials for handling testimonials. There’s so much that can be done via add-on plugins and theme integration. I look forward to seeing what folks come up with.

Theme Hybrid members have already had some opportunities to beta test the plugin. In fact, this made for a good opportunity to show what the plugin can do right here in the announcement post. The following is using the [toot_testimonial] shortcode bundled with the plugin for showing off a single testimonial (thanks for the quote, Brett).

Been testing it this morning. So far so good and not had any issues. Does exactly what I was looking for so thanks a lot! Looking forward to a carousel option then all my bases are covered

One of the oft-asked support questions I get is how to allow a user to edit posts/pages but not create new ones. WordPress actually allows for this with custom post types, but for backward-compatibility reasons, it’s not possible out of the box with posts and pages.

After sharing bits and pieces of code enough through the support forums, it made sense to turn this into an add-on plugin for Members.

What does the plugin do?

Members – Core Create Caps creates two new capabilities:

create_posts – Permission to create new posts.

create_pages – Permission to create new pages.

By default, creating posts and pages in WordPress is directly tied to the edit_posts and edit_pages capabilities, respectively. However, those capabilities also control who can edit posts and pages. There’s no separation between the creating and editing permissions.

In a nutshell, this plugin splits the “create” capabilities away from the “edit” capabilities.

There’s a couple of other things it does, such as register the new capabilities with the Members plugin and fix a bug in WP’s admin menu handling system. But, the core of the plugin is to provide more flexible control over managing posts/pages on sites that need it.

Known bugs

I hate to release a plugin with an existing bug, but there’s little I can do about it at this point because this bug exists in core WordPress. However, the plugin itself is useful even with the WordPress issue.

Currently, this plugin separates out the create_posts and create_pages caps. However, you cannot simply give those caps to a role without also granting the edit_posts and edit_pages caps. Of course, most people who create posts/pages will need the ability to edit them anyway.

Where this plugin shines is when you give users the ability to edit_posts and edit_pages but not the ability to create. This is particularly useful when you have an editor or admin who assigns specific posts/pages to specific users to edit (most common use case).

In part 1 of this tutorial series, I covered how to set up a custom REST API route for your Web site. Doing that allows others to get info they need from your site in a standardized JSON format and use it to “do stuff”.

Our route was for accessing plugins from our plugin portfolio. In particular, we created a method for accessing a specific plugin’s add-ons (or, child plugins).

In part 2, you’ll learn how to output a list of your plugin’s add-ons in the form of “plugin cards.”

I’m going to assume that you already know how to build an admin screen. If not, head over to the WordPress documentation for Administration Menus. This tutorial is only going to cover what you output to the screen. So, before moving forward, have your custom admin screen set up and ready to go.

Talking to the REST API

Our plugin, which is installed on a user’s site, needs a way to talk to the REST API on our site. Fortunately, WordPress already has us covered with its HTTP API. We’ll be making use of wp_remote_get() and wp_remote_retrieve_body() to handle the request.

In the following code, I’m using the term pluginslug. You should replace that with your plugin slug from part 1 in this tutorial.

For our plugin, we need to create a function for grabbing add-ons for the plugin and returning them for use on our admin screen.

You’ll notice that I’m setting a transient on the user’s site for 7 days. You can make that a shorter amount of time, but keep in mind that potentially 1,000s of sites could be trying to get data from your site. You’ll want to store that data for a while. Unless you’re releasing a new add-on for your plugin every few days, this data doesn’t need to be updated often anyway.

Displaying your add-on plugin cards

Unfortunately, like so many other UI components in WordPress, plugin cards are hardcoded into core with no way to reuse the component. So, we must roll our own functionality for this.

Creating the add-on card function

The first thing we need is a function for an add-on card. I’m reusing the core WP classes to avoid having to write extra CSS. Keep in mind that WP could change this on a whim. Feel free to roll your own classes and style this however you want.

Note that the fields we’re using are fields that we set up in part 1 of this tutorial series. If you changed them in your code, you’ll want to make sure they match here.

The numbers

From a business perspective, this addition to the Members plugin has consistently brought in an additional 1,300 visitors to Theme Hybrid each month. At the moment, there’s only 2 add-on plugins listed. The add-on screen is not something that would be visited often by a user.

Members is my most popular plugin with over 100,000 active installs. A bit more in-your-face admin advertising would probably bring in more visitors.

But, that’s not how I roll.

I like to integrate cleanly into the WordPress admin interface and not tick off my users. The extra visits every month are nice.

When I released version 2.0.0 of the Members plugin a few months ago, I created a new admin screen that listed all of the plugin’s add-ons. I used the WordPress REST API on this site and some custom code to get that data within the Members plugin. Basically, this is a way for me to directly communicate with my plugin users.

I even cleared this project with the WordPress.org plugin team ahead of time to make sure I wasn’t doing anything out of bounds in terms of the guidelines.

Most tutorials you’ll read on the REST API talk extensively about all the cool JavaScript stuff you can do. They go into stuff like ES6, Webpack, Babel, and so on. If you’re coming from a PHP development background, much of this can be confusing, especially if you simply want to know what sort of things you can do with the REST API.

In this tutorial, I’ll only be sharing PHP code, and our use of the REST API will only be for reading/getting data. This is the type of foundational stuff that should be helpful to those who just want to learn some of the basics.

In part 1 of this tutorial, we’re going to cover the REST API aspects that will run on our own sites. In part 2, we’ll build an admin screen to show off our add-ons to plugin users.

If building an add-on screen for your plugin isn’t your thing, you may still find this tutorial helpful. What we’re really doing is learning how to retrieve data from our site using the REST API. There are numerous applications for this.

Prerequisites

I’m going to make some assumptions in this tutorial. Primarily, I’m going to assume you have some development experience under your belt. If you haven’t built a few plugins, this is probably not the best starting point. A general working knowledge of WP concepts such as the following are necessary:

I highly recommend Plugin Developer for managing your plugin portfolio. It’s a plugin I built for people who build plugins, and I personally use it here on Theme Hybrid. Use whatever you want. Just note that I’m using a custom post type of “plugin” and some custom functions from Plugin Developer in some of the code examples.

Building with the API

Now, we’re getting into the meat of things. We need a way for our site to share data. There are many ways to actually do this, but the REST API makes this simple by creating some standard ways of handling the more complex bits.

Creating a REST route

The first step is creating a custom REST route. A route is basically the part of the URL that tells us what to create, read, update, or delete (CRUD). If we have a URL of example.com/wp-json/th/v1/plugins, the th/v1/plugins is the “route”. The th/v1 is the namespace and version for the route.

And, that’s exactly what we’re doing in this next example code. We’re registering a custom route with WordPress.

I’m using the th/v1 namespace. th is just short for “Theme Hybrid”. You should change that to something unique to your project. Namespaces require both the name and version. Note: Versioning is awesome because you have a back-compatible way to handle breaking changes in the future.

args

This is an array of arrays for additional parameters on our URL. Because we’re looking to find add-ons for our plugin, I’m creating an addons parameter. In the case of the Members plugin, the URL to access its add-ons would be example.com/wp-json/th/v1/plugins?addons=members.

Our custom parameter is addons. And, we’re letting WP know how we’re going to handle that scenario. Here’s another look at that bit of code:

Sanitizing the add-on value

Because this is a basic text field, I simply used sanitize_text_field. If you’re writing something more complex, you may need to build a custom callback function for this. Just be sure to make sure the data is safe to use.

The endpoint callback

This is where the magic happens. We’ve done a lot of work. Now, we actually want to return some add-ons for our plugin.

This is the callback function for actually getting and returning our add-on plugins.

For this, you primarily need to know how to use a WP_Query call and loop through your posts. I’m not going to walk you through every line of code below. Any plugin author who is diving into the REST API should be able to grasp what’s going on (feel free to ask questions in the comments if necessary).

A few points to note:

I’m using transients to temporarily store data. Because this data isn’t going to change often, I’m storing it for 1 day.

I’m handling both getting all plugins from the th/v1/plugins route and the ?addons=xxx parameter. You could split this up into multiple functions if you have many parameters.

All of the pdev_*() function calls are from my Plugin Developer plugin. They should be self-explanatory and can be replaced with custom or WP functions as need be.

The function must return data, not output it to the screen. A simple array of arrays will work fine here. This will all get turned into JSON in the end.

With Gutenberg getting closer and closer to being ready for merge into core WP, I thought it’d be time to look at two of my favorite features being introduced for users and theme developers.

That’s the .alignwide and .alignfull classes.

These are two classes that I’ve wished we had for ages. I’ve seen some theme authors implement them in the past, but there was no standard naming scheme for them. Therefore, they couldn’t be shared across themes. Regardless of the direction of the Gutenberg plugin, these two classes are more than welcome.

In this tutorial, I’m going to cover adding support for and styling these new classes. I’m already making liberal use of the classes on this site without actually having Gutenberg installed. This is useful with or without the plugin.

While the primary use case in Gutenberg covers images, I’m using the feature for other things too, such as full-width testimonials on my product pages and elsewhere.

Adding Gutenberg support

Adding support for wide and full images is pretty simple. You need to drop the following code into your theme setup function, which should be hooked to after_setup_theme:

add_theme_support(
'gutenberg',
array( 'wide-images' => true )
);

This tells Gutenberg to show users the wide/full image alignment options in the new editor. If your theme doesn’t support this, it won’t be shown to the users.

Adding your styles

The new .alignwide class is a way of telling a theme that an element (images in most cases) should be wider than the post content. The .alignfull class tells the theme that it should be full width.

Here’s some sample CSS that I’m using here on my site to handle this. I’m using the .entry__content class as my post content container, so you’ll want to adjust that to match your theme.

Since then, I’ve dabbled more and more with JavaScript. Before that, my only real experience was copying and pasting jQuery snippets to handle trivial things here and there. I had no real understanding of JavaScript at all. And, the jQuery that I’d learned over the years made it harder to grasp some of the underlying concepts. It was a crutch for bad habits.

To understand a programming language, you must be able to think in that language. That means being able to read code and have some basic idea of what it does. More importantly, it means being able to see in your mind potential solutions in that language before ever writing a character of code. It should come as naturally as any other language you know.

That simply comes with practice and real-world usage.

There was a point last week where I realized I’d crossed that barrier with JavaScript. Instead of searching online for code examples, I was writing my own JavaScript without much thought. Granted, the code I was writing was relatively simple, but I was the one writing it.

The biggest step I took in being able to think in JavaScript was dropping jQuery. I challenged myself to write any code that I needed in vanilla JavaScript. This helped me grasp some of the basic concepts that jQuery hides from developers.

I’m not writing this to knock jQuery (though it’s an unnecessary library nowadays). I do want to encourage other developers in the WordPress community to start writing vanilla JS. Gain a solid understanding of JavaScript before using a library built upon it. I think you’ll find that you probably don’t need a 95 kb library for most use cases and that you have a deeper understanding of the language in the end.

Another huge help for me has been our developer community here at Theme Hybrid. In our Slack channel, we’ve been sharing a lot of awesome JavaScript resources in the past year. We’re becoming more and more comfortable sharing JavaScript code and talking about it. So, find a community of like-minded people willing to help out in your journey (I hope you’ll join us).

]]>https://themehybrid.com/weblog/thinking-in-javascript/feed19Lists in comment texthttps://themehybrid.com/weblog/lists-in-comment-text
https://themehybrid.com/weblog/lists-in-comment-text#respondMon, 27 Nov 2017 21:36:15 +0000https://themehybrid.com/?p=10124[…]]]>One of the most common problems that I see when reviewing themes for the Theme Review Team and at ThemeReview.co is handling the styling of lists within comments.

Ordered and unordered lists aren’t often used within comment text. However, they are used at times. And, when they are used, they’re terrible.

This stems from two common issues that I’ll cover in this short tutorial. These issues arise because the comments list itself is typically a <ul> or <ol> with each comment block being an <li>.

I’m certainly guilty of both of these issues. I hope you can learn from my experience. The code in the tutorial is simply an example. There are multiple ways to handle this. The big thing to do is to test lists everywhere when developing themes.

Missing bottom margin/padding

Many theme authors do a reset and normalize their list styles with something like the following CSS. This causes lists within comment text to have no whitespace below, which is generally undesirable.

That looks OK with a quick glance, but you’ll likely want to treat lists within comment text as a top-level list. However, they’re actually nested within the overall comments list structure. That’s easily fixable with a simple > in the above code like so:

There are plenty of other comment classes to utilize as well, particularly for handling nesting and such. The big thing is to watch out for directly styling by tag name, such as ol, ul, and li. Anything you do to those can and will affect children (i.e., lists within comment text).