Migrating to Sitewide Sales from the Paid Memberships Pro Add On

Posted on September 22, 2020 in Sitewide Sales

Before Sitewide Sales was a standalone plugin, there was a version of the plugin exclusively developed for Paid Memberships Pro customers. Membership sites that used this previous version can migrate historic sale data into the new plugin via a one-click migration step.

How to Migrate your PMPro Sitewide Sales

Before you can begin the migration, you must install and activate the new Sitewide Sales plugin.

Navigate to Sitewide Sales > All Sitewide Sales in the WordPress admin.
If the plugin detects historic sale data from the pmpro-sitewide-sales plugin, you will see a notice titled “Migrate Your Previous Sales Data”.
Click the “Migrate PMPro Sitewide Sales Data” button in the notice to begin the migration script.

If you accidentally dismissed the notice, you can also access the migration process at the bottom of the Sitewide Sales > About page in the WordPress admin.

Understanding the Migration Process

The migration process is designed to make a few key updates to the way your data is stored and accessed. Below is a list of the updates to your data that this script will process:

Change the post_type for the pmpro_sitewide_sale CPTs to the new sitewide_sale post type.
Detect and migrate the pmpro_sitewide_sale shortcode to the sitewide_sale shortcode in post_content.
Update all Sitewide Sale postmeta, including the some sale data formerly stored in the WordPress options table into postmeta. This includes adjusting the prefix (meta key) for specific sale CPT data, as well as data for reports that was formerly stored in the options table.

After the migration is complete, you should be able to see all previous sales and their report data on the Sitewide Sales > All Sitewide Sales page in the WordPress admin.

How ANYONE can make MORE MONEY with WordPress

Posted on August 23, 2019 in General

Presentation by Jason Coleman at WordCamp Orlando on Friday, August 23, 2019 in the Business Development Workshop

Money isn’t everything, but having more of it tends to solve the stressful problems of modern living: things like paying rent and traveling to WordCamps.

This presentation is for anyone who wants to make more money with WordPress. I will start with some basic frameworks for thinking about income and business revenue and then transition into specific actions you can take to make more money in your freelance business, product business, side gig, or full time job.

Attendees should come out of this talk with more confidence in their ability to make money and some tactical advice to increase their income or business revenue.

Workshop Links

Creating Your Own Plugin for Customizing WordPress (WPReading Meetup)

Posted on November 20, 2018 in Plugins, WordPress

At the Reading WordPress Meetup, on November 20th, 2018, I demonstrated how to code your own plugin for WordPress. This was a high level discussion, focused largely on the Q&A.

Here is the GitHub repository for the demo plugin I created.

What is a plugin?

Extra code, in addition to the theme, that is run after WordPress is loaded.
Plugins are stored in the /wp-content/plugins/ folder of your WordPress site.
Plugins must have a php file and a valid plugin header comment.
Only plugins activated from the plugin menu of the WordPress dashboard will run.

Why code your own?

Because you are a badass.
Because you need to tweak something specific to your site.
Because someone like Jason gave you custom code to patch your site.

Why not use functions.php in a theme or child theme? (Or edit a plugin or edit WordPress core.)

If you edit a theme or another plugin or WordPress core… that edit will be overwritten when the theme, plugin, or WP core is updated.
If you have your own child theme, you can put the code there. It’s less likely to be updated. However, your code stops running when you change your theme. Or maybe you don’t want a child theme.

Demos

Changing the excerpt length of archives.
Removing unused profile fields.
Setting a sitewide banner for Memberlite theme.

Other Demos?

WooCommerce
Ninja Forms
Paid Memberships Pro
Custom APIs

Jason was on WPwatercooler again. Summary.

Posted on August 7, 2013 in Business, Design, Development, WordPress

The WPwatercooler is a great show, and I was on it again this past Monday with my BWAwWP co-author Brian Messenlehner. I may make it a habit to get on that show. And I may make it a habit to follow up each show with a summary of what went down.

The show topic was How do I make sure I don’t have to re-do my website just months after it’s done?

The consensus was that you can’t make a website that won’t require updates. But you can do a few things to prepare for future updates and minimize their impact:

Make sure you are using a good developer. Good developers will do things “the WordPress way” (e.g. using hooks and filters instead of hacking plugins), which will be less likely to be broken by plugin and core updates.
Make sure you are using a good designer. Good designers will simplify things and use proven methods that are less likely to be broken by software and browser updates.
Make sure your website has a purpose other than looking pretty. One year after your website goes live, it will probably be out of style… at least a little bit. But if you built a website that encourages people to call your sales phone number, it will still do that no matter what the design trends are.
Make sure you have a maintenance plan. In addition to having someone on call to perform WordPress upgrades, have a developer on retainer or on call to fix things if anything goes wrong.

We need to do a better job of communicating with our clients about what role maintenance will play in their website. There were a few analogies thrown around on the show (websites are like babies?). My favorite was to think about your website like a car bought on lease (get regular oil changes and be ready to trade it in every 2-3 years) instead of a used car you buy and run into the ground.

Heartbeat API for WordPress

Posted on August 7, 2013 in Development, Plugins, Tutorial, Web Application, WordPress, Writing

As part of the JavaScript chapter for our upcoming book Building Web Apps with WordPress, I got a chance to research and work with the Heartbeat API that is new to WordPress 3.6.

It’s a cool little piece of functionality that will help out developers building asynchronous apps on top of WordPress.

At first, I didn’t see the need for it. (It’s not too hard for developers to create their own script to poll the server every few seconds.) But I soon realized why an API like this would be useful. If you have 5 different plugins all with their own server polling, you are going to have 5 different hits to your server every 15 seconds. However, if they all piggyback on the Heartbeat API, those polling requests are going to be bundled so you are only hitting your server 1 time every 15 seconds. There are other benefits, but that’s the big one to me.

For people trying to get started with the Heartbeat API, I put together this nice little minimal example that you can use as a starting point. The script below simply sends the message “marco” from the client and then detects this on the server and sends back “polo”. The messages are logged in the JavaScript console (so if you inspect elements and click on the console tab in Chrome you will see them). You should be able to easily tweak this to send requests like “how many members are logged in?” and send back a number, etc.

Let me know if you have any questions about the API and I’ll try to address them.

Thoughts on GPL WordPress Plugins and Themes

Posted on July 31, 2013 in Business, WordPress

This was originally posted as a comment on a Reddit thread of all things, but kind of too good to stay there.

WordPress is distributed under the GPLv2 license. The basic gist of that license is that you can do whatever you want with the code, but if you distribute any altered code, that code must be distributed with the GPL license as well. Meaning anyone you sell your code to can do whatever they want to do with it. This makes things like “one site licenses” and other restrictions unbinding or outright illegal.

If you do a consulting project for someone, the GPL license doesn’t come into play. Only if you want to sell or otherwise distribute your plugin on your website, etc, will your code need to carry the GPL or a GPL-compatible license.

First, what everyone agrees with is that if you copy and paste someone’s GPL code, even if you tweak it a bit, you are inheriting that code and the GPL will apply to it.

But let’s say you built your plugin from the ground up and it doesn’t borrow any code from GPL code. (Which is actually hard to do.) Most would say that the GPL will apply to your theme or plugin anyway since it relies on WordPress to run. The most cogent argument is by Mark Jaquith here[1] . Part of Mark’s argument:

Note that WordPress theme PHP files are not “templates” or “documents” in the way that most people think of those words (though the word “template” is sometimes used, it is not strictly accurate). They are PHP script files that are parsed and run on the same exact level and by the same PHP process as all the core WordPress files.

The particulars of the GPL would make exceptions if the theme was actually being loaded and parsed by the WordPress code, but it’s not. It’s being executed in tandem. Your plugin is really like a patch for WordPress in a nice little package vs. a separate application run by WordPress.

Some people might disagree with Mark and the rest of us, but for the most part their argument is “but I don’t wanna use the GPL, wah!” (Anyone is free to reply with a real argument if you are in this camp.)

There is another thing called a “split license” where you license the .php (and maybe some .js code) under the GPL and license static assets like CSS, images, .html files, and some .js files under a different (more restrictive) license. This way people can’t just redistribute your theme as a whole without replacing the non-GPL pieces first… kind of an extra little hindrance.

Most will agree that this is legal for you to do with your plugin or theme under the GPL. However, some organizations will have stricter rules, requiring a plugin or theme to be “100% GPL” (meaning all files included in the package) in order to be listed/etc. Most notably themes and plugins hosted at WordPress.org must be 100% GPL. Also, WordPress won’t recognize or work with designers and developers who don’t release stuff that is 100% GPL. So, for example, as soon as Woo Themes (a big theme developer) made all of their themes 100% GPL instead of split license, they got a big ol’ link on the WordPress.org homepage. And recently a designer who sold a split license theme was banned from speaking at a WordCamp.

The idea behind requiring that themes and plugins be 100% GPL is that making them split license betrays the intent of the GPL, which is to make it easier for people to do other things with your code, improve it, and generally make the world a better place.

The intent of the GPL is NOT to keep you from making money. Even though there are companies (including mine) selling themes and plugins on their site, this doesn’t mean those plugins are not GPL. You can still charge for a GPL plugin even though someone could buy it and turn around and give it away for free.

There are several reasons people will pay for a plugin or theme even though they might be able to find it for free elsewhere: * They want to get it from “the source” * They are worried about free versions containing malware or other nasties * They want support from who they are buying from (Paid Memberships Pro) * They want to receive future updates automatically (Gravity Forms) * The plugin relies on a 3rd party service (VaultPress)

Now there are basically two camps of people selling GPL themes on their sites.

Camp 1 embraces the GPL fully and will have GPL stickers in their footer and mention it whenever they get a chance. Camp 1 is more likely to give away versions of their code for free (maybe a lite version, or one minus addons, or even the full code) and use other business models to make money.

Camp 2 will admit that the plugin is GPL, but you’ll have to dig around to figure it out. They won’t mention it on their website at all. They might not even include a license.txt or similar comment in their code, which they are supposed to. They are basically reluctantly GPL and hope they can hide that fact to avoid people trying to get their stuff for free. But if you confront them about it, they will admit that their code is GPL to avoid the legal and community ramifications.

I’m in camp 1. I’m still not sure if it’s best for my bottom line. However, I’ll leave with this:

If you are going to work with WordPress and try to make money off of it. It makes sense to be in alignment with the people running the show, namely Matt Mullenweg. WordPress is a community project, but Matt and the WordPress foundation are all about 100% GPL and definitely against non-GPL themes and plugins. You probably should be too. If you don’t want to be, you should probably look into other code bases with different licenses and different people running them.

Update: The best argument I’ve found for the position that WP Plugins and Themes are NOT “derivative” works is by Chip Bennett here. Give it a read. He cites copyright cases and applies their decisions to the question of WP Themes and Plugins. If he sways you, it’s possible that Mark Jaquith’s comment will convince you back to the other side of the argument. 🙂 It’s a very interesting legal question.

Continuing the WPWatercooler Discussion on Rapid WP Core Development

Posted on July 29, 2013 in Business, Development, WordPress

In his 2013 State of the Word Speech, Matt Mullenweg shared his plans to release two major versions of WordPress later this year in addition to 3.6 coming out this week and to generally increase the rate of WordPress updates. We discussed this a bit on the WPWatercooler today, but there wasn’t really time to get into things.

The discussion (argument?) went something like this: (paraphrasing here)

Scott Bolinger: The WP survey reported back that the two worst things about WordPress were updates and plugins. And Matt’s State of the Word Speech was basically a call for more updates and plugins.

Chris Lema: It’s really annoying and costs a lot of money to retrain people when WordPress is updated, especially in the enterprise.

Jason Coleman: You’re whining.

Chris Lema: Of course updates are easy for you, you bleed blue WordPress blood. You need to be able to relate to end users who are confused by UI updates, etc.

And that’s about where we left it before moving on to the next topic. If I had time, I would have continued on like this…

First, I do understand the end user’s perspective. I have to do these updates for clients, answer the support calls, and sometimes retrain them. I used to be in the Chris Lema camp and thought WordPress was needlessly updating their UI too fast. I mean, I thought the change in version 3.3 to hide submenus in the dashboard behind flyouts was a big big deal. But that’s nothing compared to the potential change between the current version of the WP dashboard and this mockup of how things might look under the new “MP6” dashboard UI.

I’ve since changed my mind. Here are a few arguments for faster WordPress updates.

What’s the alternative? Slow down? Have fewer updates? I don’t think Chris’ enterprise clients would like that option. WordPress needs to iterate to stay relevant. If WordPress gets stale, we’ll stop using it to build cool stuff.
Things aren’t even changing that fast. That flyout menu feature was added in version 3.3 back in December 2011. Since then, the media library update was the only big UI change which happened earlier this year. An MP6-like update to the WordPress UI possibly (possibly) happening by the end of this year will be a big change, but then so is the jump from Microsoft Office 2010 to Office 2013. Enterprise should be ready for these kinds of things.
What about new users? Sure existing users are disrupted when the UI updates. But if the changes are meant to make WordPress easier to use, it will make training new clients easier. I use a similar argument all the time with clients: sometimes you can’t worry about the few existing users you have and need to instead focus on the many future users you want to have.
Finally, faster updates should encourage some changes that will make things easier for enterprise users. Things like automatic minor version updates or a better decoupling of the admin UI to the underlying WordPress framework are a bigger focus of WP development right now. I think the updates in these areas will make up for the inconvenience of a larger number of core updates.

I really mean for this to be a continuation of the discussion we started on the show. So I look forward to feedback and counterarguments in the comments below. Why am I wrong?

Update: Chris Lema has posted a reply on his blog.

Why We Changed The Domain of Our Book’s Site to BWAwWP.com

Posted on July 29, 2013 in Business, WordPress, Writing

(Originally posted to my Google+ account.)

Just a quick post here RE why we decided (without hearing explicitly from the WordPress foundation) to change the domain of our book’s site frombuildingwebappswithwordpress.com to bwawwp.com.

So first, the original domain we chose is the full book title. It’s a pain in the butt to type all that, but we liked that the domain matched the book title exactly so readers wouldn’t get confused since there are and will be many similarly worded WordPress and app development books.

John Parris (@john_parris) and others quickly pointed out that the WordPress foundation, on their website, asks “Please do not use WordPress or WordCamp as part of a domain name.” http://wordpressfoundation.org/trademark-policy/

Many companies and orgs protecting trademarks ask the same thing and actively work to keep people from using their trademarked name in a domain name.

We were aware that the Foundation had this policy. However, it is my understanding that we have a case under “nominative fair use” to use the full WordPress term in our domain name.

The Wikipedia page explains this pretty well.
http://en.wikipedia.org/wiki/Nominative_use

Another good description and overview of a test case where a website was able to use the LEXUS brand in their domain name can be found here: http://thompsonhall.com/nominative-fair-use-allows-trademark-used-on-website-domain-name/#nominative-fair-use

So we originally went with the full domain name. After launching (very quickly) we realized that even if we weren’t going to ask permission, we should at least inform the WordPress Foundation of the domain. So I submitted a note through their contact form.

We’re all busy at WordCamp San Francisco, so I never heard back from them, but I am willing to bet that they don’t want us to use the mark in our domain name even if we have a case for it. (Maybe they’ll get back and say otherwise.) My thinking is that their thinking would be that having our site in the wild makes it a bit harder for them to ask other sites to switch domains (but Jason can do it!), etc. And they might even think that nominative use doesn’t apply. And their lawyers are probably better than our lawyers. (Hint: we don’t have lawyers.)

So expecting a no, and potentially some friction with the foundation and software community that we are trying to work with and promote, we decided to just change the name anyway. The full book title will redirect to bwawwp.comanyway, and Bwawwp! is pretty fun to say.

So that’s why we originally used WordPress in our domain name and quickly changed course without hearing directly (yet) from the WordPress Foundation.

Our Book: Building Web Apps with WordPress

Posted on July 26, 2013 in Web Application, WordPress

Brian Messenlehner (@bmess) of WebDevStudios and I (@jason_coleman – you follow me right?) are finishing up a book for O’Reilly called Building Web Apps with WordPress. The book is for intermediate to advanced WordPress developers interested in building full on web applications using WordPress. We’re just finishing up writing now and diving into technical review with some of your favorite WordPress peeps. The book should be available for purchase later this year.

I know you are interested. So head over the book’s website to sign up for updates on when it will become available. If you are at WordCamp San Francisco, look for Brian or me to chat about the book.

Sign Up for Updates at BuildingWebAppsForWordPress.com

At last year’s state of WordPress speech, Matt Mullenweg spoke a lot about using WordPress as a framework to build web apps. I’m sure Matt will be promoting WordPress as a “web OS” during this year’s speech, and in general the use of WordPress as an application framework is going to increase as the WordPress platform and the number of good WordPress developers continues to grow.

Brian and I (and many others) have already been using WordPress to build highly interactive web apps that stretch the possibilities of what reasonable people expect to be able to do with WordPress. Our book will be the first to really dive into WordPress as a framework and codify a process for building apps with WordPress.

It’s an exciting time for us and an exciting time for WordPress.

Mistake #3: Starting with Design

Posted on January 28, 2013 in 8 Mistakes, Business, Design, WordPress

I’ll focus on WordPress sites and themes here, but this advice applies to any website built using an existing theme as a framework or just for inspiration.

I’m a big fan of using existing premium themes for WordPress sites. There are so many quality themes available now that you should be able to find something that fulfills 80% of the design and layout needs for your site. Tweak the colors and layout a bit, and only web designers will be able to tell that you didn’t design your website from scratch. (And only web designers will care.)

However, there is a mistake that nearly every client we use a premium theme for makes. They fall in love with the demo site and THEN think of things to put in each little widget area of the site.

That is, they start with design, then they supply the copy for the site.

It really should be the other way around: Write your Copy → Find a design for your copy.

Doing something like “mobile first website design” helps with this. Maybe we need “email first website design” where instead of a website, you write an email to explain your company (keep in mind your goal).

Start with words. Then build a website around those words.

The thing is all of those widgets may look nice, but they’ll detract from your #1 goal.

The best example of filling a design rather than using a design is with sliders. Sliders are cool. They work for a lot of site. But for most sites, they are just an excuse to put off figuring out your #1 goal and enter EVERY thing you want to say.

If slide 1 is more important than slide 2… then you shouldn’t have a slider. Just show slide 1 and keep it there.

WordPress as an Application Framework

Posted on January 11, 2013 in Development, WordPress

I wrote a comment over on Justin Tallant’s blog post titled WordPress is not an application framework. My comment got pretty long, so I figured I would also post it here. You should read Justin’s post first. He ends by asking “What do you think? Is WordPress heading in the right direction with the goal of being a Web Application framework, or should they focus on being a blogging platform and CMS?”

My Comment:

WordPress is heading in the right direction. Matt’s goal is to have WordPress used for EVERY “website” on the Internet. Our Internet use is moving away from sites to apps, and allowing more apps to be created more easily with WordPress is a good move.

It’s not just a good business move for those of us with interests in having WordPress used more often. There is something fundamental about WordPress that makes it popular and useful for people wanting to setup sites quickly with the flexibility to extend those sites later.

When you say “it’s a blogging platform that can work well as a CMS”, you are understating WordPress as a CMS. It’s the most popular CMS platform in use*. There must be some reason for that, no?

* http://w3techs.com/technologies/overview/content_management/all

This wasn’t always the case. Matt and the WP community made CMS functionality a priority and CMS use went from a fraction of a % to the 50%+ market share it has now.

This is why people may say you are short sited to think that WP can’t take over framework market share just because they are behind right now. We remember when people said the same thing about WP as a CMS… or hell WP as a blogging platform.

You can already think of WordPress as an application framework with some very successful apps running on top of it: WordPress blogs, CMS, ecommerce sites, membership sites, forums. It already works well for building custom apps and can be improved on in that area without being detrimental to the existing blog and CMS functionality.

The secret sauce of WordPress is not the UI or blogging feature set… it’s the plugin architecture, platform stability, and community.

MVC, REST, and database migration support are not requirements for building apps. MVC is a useful way to organize things, but not the only way. The theme/plugin paradigm works great for separating design concerns from programming concerns. I am a little bit removed from using other frameworks, but I know that I can easily build RESTful APIs and migrate databases with WordPress.

The way that WordPress really shines as an application framework is if you think in a “Lean Startup” kind of way. With WordPress you can start with a minimum viable product and incrementally develop it into a full blown application using the same platform the whole way. Something like:

Simple one pager built in WordPress, using an existing theme, to announce the concept of your app.
Add a blog to discuss development, etc.
Use Paid Memberships Pro and free levels to get people to sign up for the beta release (gathering emails).
Use plugins to integrate with MailChimp to start emailing the mailing list.
Combine existing plugins and simple content to develop a wireframe or proof of concept.
Create a custom plugin to house your beta app classes, logic, and customizations.
Create a custom theme for your branding.
Use Paid Memberships Pro (see a pattern here? 😉 to accept paying customers.
Re-factor your plugin/app for a version 1 release.
Use plugins for forums, social integration, analytics, caching, SEO, third party integrations.
Scale your system at the server level. Rewrite individual bottle necks in lower level PHP when it helps.
Rinse and repeat for version 2.

The beauty is that all along the way your app always has the same user base and underlying infrastructure. Your gathered emails become users then become paying customers. You can quickly add and test new features. You can use the same WordPress developers throughout the entire process and if you business pivots at steps 2-6, you didn’t waste time or money building a full blown app.

I’m excited to continue this discussion over the next couple years. 🙂 Pointing out how WordPress lacks as a framework is important to improving its functionality and use that way. What may look like insurmountable shortcomings to you are just challenges to be overcome by me.

I think your prediction that WordPress can’t “catch up” feature-wise and your fears that “WordPress will become a Molotov cocktail of code” as we try to build out WordPress as a framework are wrong. The WordPress core team has shown their ability to push updates that pretty successfully juggle new features with reverse compatibility and clean code.

There are advantages to having a platform built with applications in mind from the get go. There are also advantages to having a platform that is scrappy, accessible, and practical.

Mistake #2: Playing Designer

Posted on October 8, 2012 in 8 Mistakes, Business, Web

Unless your business is website design or something else in the arts, you don’t need a beautiful website. A nice looking website is a bonus, but make sure you’re working towards a functioning website instead of something that will look great printed out and framed on your wall.

Oftentimes when going over design mockups or newly updated websites, you’ll find yourself leaning back in your chair and staring at your homepage for a minute or two taking it all in.

Stop it! No one browses the web this way.

If you think of your website as a work of art, you surely will find little things here and there that might be smaller or larger or a little bit to the right. Resist the urge to do this.

If you know the primary goal of your website (see post #1), make sure the design focuses on that goal. Focus your design feedback on how well the design enables sales, mailing list sign ups, contact requests, etc.

As for website design, hire an experienced web designer at a decent rate and trust their instincts for what looks good.

If you hassle your designer with a lot of feedback on what “looks good”, they are going to shut down and move into “code monkey” mode where they just code up whatever requests you have. Unless you are paying bottom dollar (in which case you get what you pay for) you are wasting money by paying designer rates for code monkey work.

More importantly, micro managing a code monkey will not get you as good of a website as one where you control the vision via a strong primary goal, and an experienced designer controls the particulars of the site’s look and feel.

View all posts in this series here.

Stranger Studios

Blog