Whenever you’re working on a plugin that offers a page for its settings, there are several ways that you can save and retrieve the information.

You can:

• use the Settings API,
• use a custom page and calls that are a hybrid of the two,
• use some type of hybrid between a submenu page (or a menu page) and other functionality.

The more I’ve worked with WordPress, the less and less I care to use the Settings API and opt to go with a bit of a hybrid approach.

Depending on the requirements of the project, the implementation will vary; however, I try to use a relatively consistent way to create the functionality.

And though this post won’t go into the various ways that I create my pages, related classes, and so on, it will offer one way that you can go about initializing plugin settings when working on your project or a project for someone else.

Continue reading

In Part 1, I wrote a bit about what happens when someone gets bored with WordPress development. Specifically, I raised points of interest in:

• Is it the community?
• Is it the social (perhaps read: political) aspects of it?
• Is it the fatigue of learning something new?
• Is it the notion that you’ve learned all there is to learn about it?
• And more.

And though I think it’s completely reasonable and acceptable to say “I’m ready for something new,” I think doing so under the guise of “I’ve learned all there is to learn about WordPress” to be a bit of an overstatement.

It’s a big piece of software with a lot of APIs, tools, and libraries around it. To make the claim that you’ve learned everything, there is to know about WordPress may be a stretch. I’m not saying it can’t be done (because there are people who have been involved with the project since it’s initial fork), but it seems unlikely.

Regardless, I thought I’d spend a few more words talking about the areas in which I’ve been involved and why I moved away from them as well as why I moved into the areas I’m in now.

Continue reading

This is a sponsored post from the fine team over at WPMerge. The following tutorial provides all you need to know to get started.

Whenever we’re working with WordPress environments, it’s common for us to clone the production database to our local development database but not necessarily the other way around.

For example, let’s say that we do work in the local development database that contains new posts, perhaps new WooCommerce orders, or other data that you’d like to share with the production site.

At this point, you have two versions of the database that you’d like to merge without losing changes in either environment.

To manage this, we have a few choices:

1. You can note all changes made in the local development site and meticulously perform them on the production site.
2. You can copy changed rows from the development site and run the queries on the production site. The problem with this is when the new data comes in; users may have the same IDs used in the local development database ultimately creating a conflict.
3. With currently available tools, you can move the development database to the live site. But you’d lose the vital changes like comments or orders that happened on the live site during development.

None of them make for an ideal deployment workflow.

Continue reading