We think using the GPL license will result in the best code.
WordPress uses the GPL license, and Matt Mullenweg and the other WP leaders encourage and expect plugins to be GPL.
Some companies respond mostly to #2 there, and begrudgingly apply the GPL license to their code. For us, reason #1 is more important, and so we have embraced the GPL and try to not only live up to the law of the license but the spirit of it as well.
What does “the WordPress way” mean?
This one is more difficult because what is considered “the WordPress way” is an ever-evolving set of standards and conventions that will change over time, but basically what we mean is that our code, UI, and UX should be familiar to other WordPress developers and users interacting with our software.
What does all of this mean more specifically?
Doing things the WordPress way means making all of our software free and open source, just like the core WordPress software.
It means the plugins we write to integrate with other plugins and third parties are hosted in the WordPress.org repository because that will incentivize both parties to maintain the plugin.
It means our code will continue to work as expected if your paid license expires.
It means providing simple one-line code solutions to disable our upsells or extra gateway fees.
It means using the WordPress coding standards so our code is more readable to developers used to reading WordPress-based code.
It means finding the right hooks and filters to modify the behavior of a site instead of fully replacing existing functionality of WordPress and other plugins.
It means adding hooks and filters into our own code to make it easier for others to modify the behavior of our plugins.
It means striving to have documentation on par with the WordPress Codex.
Why is this important to us?
We believe that embracing open source and the WordPress way is going to result in the best software, and having the best software as our foundation will be a competitive advantage for our business. That’s it.
For sure, it’s not bad business to focus on paying customers, or charge for software, or make decisions to maximize profits. But I also feel that’s not the WordPress way.
WordPress is software designed for everyone, emphasizing accessibility, performance, security, and ease of use. We believe great software should work with minimum set up, so you can focus on sharing your story, product, or services freely. The basic WordPress software is simple and predictable so you can easily get started. It also offers powerful features for growth and success.
We believe in democratizing publishing and the freedoms that come with open source. Supporting this idea is a large community of people collaborating on and contributing to this project. The WordPress community is welcoming and inclusive. Our contributors’ passion drives the success of WordPress which, in turn, helps you reach your goals.
We believe in making money. We’re the “get paid” folks and understand the good that steady income means to individuals and organizations. But we believe that making software that is aligned with our values and the WordPress mission statement is more important than making money.
If a decision comes down to something that will make the software better and something that will make us more money, we choose the option that makes the software better.
For us that means embracing open source and the WordPress way, making our software available for free to get the most users and contributors, and building a business on top of the software we are making by adding value instead of artificially limiting our software and selling the cure.
The @MrBeast interview on the @joerogan Experience podcast is a good one. Mr. Beast's life story is interesting, but there is also a bit of marketing advice that's useful for businesses trying to produce viral content.
Here’s a link to the podcast. It’s on Spotify. You need at least a free account to listen.
Here's an excerpt on YouTube that I think covers some of the stuff discussed here: 3/
Anyway, what's the advice. It's pretty simple:
Make fewer, better videos.
Mr. Beast says he's helped several channels increase their views and earnings but mostly convincing them to make fewer videos, but spend more time on them.
Specifically, Mr. Beast emphasized having a better idea.
How do you do that? Early on, he would spend at least an hour a day thinking of ideas. He would use random word generators to plant a seed and then riff on that.
Why are ideas so important? It's the algorithm.
The YouTube algorithm optimizes for 2 things: clicks and stickiness. It's most important to get folks to click on your video, and then it's important to get them to watch the entire video.
Having a better idea helps to get those clicks. So does good titles and thumbnails.
How do you get people to watch the whole video? That seems to be the secret sauce. It involves pacing the video to keep it interesting while at the same time teasing the info coming later.
Mr. Beast talks about that some more here:
I found this concept of fewer, better videos fascinating because it goes against the advice I learned in the blogging world which used to work so well. That advice was basically post content as often as possible, and that consistency was key.
Posting a lot made sense in the early days of blogs and RSS, when a typical behavior was to visit a specific site daily to see what was new.
But no one does that anymore. The algorithms control what we see. So optimizing for the algorithm is way to go viral. Duh!
I watched a @neilpatel video this weekend too that also suggested blogging less. Less blogs, better ideas, more time to market your posts. It's a quick video, but has some good specific tips to try.
One thing I like about the old "post as often as possible" strategy is that it really forces you to produce and figure out the process and the medium. Good for starting out. But that's not really useful if you hit a plateau and your content doesn't get any better.
So the current trend, which makes sense based on the role algorithms play, is to produce fewer, better videos and blog posts focused on clicks and stickiness.
Mr. Beast posts Thursdays and Saturdays. Neil Patel posts on Tuesdays, which might be better for biz/work stuff.
In the early years of @pmproplugin, we never ran sales.
In 2017, we ran our first Black Friday/Cyber Monday sale. Now we run 3 sales per year.
What were we worried about early on? What changed our mind?
If you want sweet BFCM 💰, but have concerns, this thread is for you.👇🧵
First, what kind of sweet cash are we talking about?
We’ve commonly heard that a BFCM sale can bring in 25-100% of your typical November revenue.
In software, where late November and December are slow times, that can be a nice bump.
Seasonal sites can do even better.
For us specifically, we make an additional 20-30% revenue any month we run a sale. At 3 sales per year, this is about 5% of our annual revenue or ~$150k over 4 years.
For reference, it cost us ~$150k to renovate our garage into a “sweet” home office.
We’ve since made sales software for WordPress sites that addresses these concerns specifically.
I’ll include a link to that software at the bottom of this thread, but first let’s break things down and hear how we got over these fears and are now running successful sales 3x/year.
(1) We didn’t want to confuse our customers.
In 2016, we weren’t even sure if we had our standard pricing down. We were changing our plans and pricing every year or so already. We thought throwing a discount into the mix would confuse our customers.
We thought running sales would confuse ourselves too. Sales would muddy up the data we were tracking.
How could we tell if that price increase to $297 was really working if we sometimes were still selling things for $197?
BTW, consider running a sale when you’re about to raise prices. You’re set up for a natural experiment of sorts where you can honestly say something like:
“This is your last chance to purchase before we raise our prices. Lock in now.”
(2) We didn’t want to look cheap.
This is a big one and almost common knowledge for ecommerce stores.
We were concerned about how discounts, especially running sales too often, could hurt our brand image.
We were already fighting the image we had as “the free membership plugin” since all of our code was fully GPL and available for free.
Running a sale could send the message that our paid services weren’t worth the full price.
In reality, our service was the best and worth more.
We all know how jewelry stores at the mall are perpetually selling things for 50% off the list price, training us to take every price we see and cut it in half.
Even now, in mid Sep, if you visit the websites of traditional jewelry stores, they are littered with sales pricing.
Perpetual sales might work for some businesses, but we didn’t want to send the message that our PMPro Plus membership was “cheap”.
Our plugin was the best. Our service was the best. We should be charging the highest prices, not be “forced” to put our membership on sale.
(3) We didn’t want to waste our time running sales every month.
Each sale involves at least a few hours writing up sales copy and emails. At worst, it involves designing one-time landing pages and custom programming to handle the pricing logic.
What do you do if someone who purchased in July for $197/year is checking out in November for $147/year?
Here’s a small snippet of *some of* the pricing logic we used to have running on the site. The current pricing.php file is about 140 lines of code.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
$paid_47 = $wpdb->get_var("SELECT id FROM $wpdb->pmpro_membership_orders WHERE user_id = {$current_user->ID} AND membership_id IN(6,20) AND total IN('47', '47.00') AND status NOT IN('refunded', 'token', 'error', 'review') AND timestamp < '2017-08-30 00:00:00' LIMIT 1");
if($paid_47) {
$level->initial_payment = '47.00';
$level->billing_amount = '47.00';
return $level;
}
$paid_97 = $wpdb->get_var("SELECT id FROM $wpdb->pmpro_membership_orders WHERE user_id = {$current_user->ID} AND membership_id IN(6,20) AND total IN('97', '97.00') AND status NOT IN('refunded', 'token', 'error', 'review') AND timestamp < '2014-08-30 00:00:00' LIMIT 1");
$paid_147 = $wpdb->get_var("SELECT id FROM $wpdb->pmpro_membership_orders WHERE user_id = {$current_user->ID} AND membership_id IN(6,20) AND total IN('147', '147.00') AND status NOT IN('refunded', 'token', 'error', 'review') AND timestamp < '2017-08-30 00:00:00' LIMIT 1");
$paid_197 = $wpdb->get_var("SELECT id FROM $wpdb->pmpro_membership_orders WHERE user_id = {$current_user->ID} AND membership_id IN(6,20) AND total IN('197', '197.00') AND status NOT IN('refunded', 'token', 'error', 'review') AND timestamp < '2017-08-30 00:00:00' LIMIT 1");
When we did client work, some clients were constantly looking for the right discount/invite scheme, and every month we’d have to update their pricing across the site.
And every month, we’d have to write code to handle all these new edge cases we were creating.
Again, Thanksgiving week was one of our slowest periods. The whole month of December is usually our lowest-revenue month.
Getting an extra month’s worth of revenue during this time helps a lot of smooth things out.
It also gives us a nice bump when we are calculating bonuses.
Here are our November sales from 2016 and 2017 with the BFCM weekend highlighted.
2016 – no sale. 2017 – with sale.
Here is a shot of our revenue from last November, 2020. In addition to extra sales from our promotion that month, we benefit from all the recurring sales year after year.
November went from a slow month to our busiest month.
My friends who had run BFCM sales eased our concerns 1-3 as well.
Q: What about people asking for the discount after the sale is over?
A: It was just a few people the following week and no one after that.
Q: Are you spending all your time running sales now?
A: Yes and no.
Some of those we talked to run sales almost every month now. Some just a few per year.
The latter appeals more to us, and after some experimenting, we have settled on 3 sales spread throughout the year.
For the past few years, every year, we run a Black Friday/Cyber Monday sale one week in November.
Then a Spring Sale one week in March-May.
Then a Summer Sale one week in June-August.
We experiment with content, pricing, and length, but also have templates we can reuse easily.
That’s our story of how we came to start running Black Friday/Cyber Monday sales, made a bunch of money, built a home office, and now are trying to help others do the same.
I’d love to hear from others who have had similar success, or better yet different struggles with sales.
Oh yeah. Here’s our pitch for Sitewide Sales, a complete BFCM and flash sale plugin for WordPress.
Today’s WordPress developers need to understand a variety of JavaScript methods and frameworks. This article covers the most common methods you’ll see in the wild in both older and more forward-looking WordPress code. Some examples include AJAX with jQuery, ES6, the Heartbeat API, REACT, and Gutenberg blocks.
My goal is to help you feel more comfortable opening up any JS file you come across in the WordPress world.
A few years ago, Matt Mullenweg asked us to learn JavaScript deeply.
I think Matt meant for PHP developers to learn JavaScript and for us to learn vanilla JavaScript in particular so we could program with it regardless of framework. Learning JavaScript deeply was important, because over the next few years, framework development continued quickly. Every year a different library, framework, or flavor of JS would become popular.
Vanilla JavaScript developed quickly as well with the base language itself gaining new features. Different browsers adopted the new features at different rates, requiring polyfill solutions, requiring compilers and package managers. I honestly don’t know how new developers pick this stuff up. The JavaScript landscape seems very confusing right now. Maybe it’s more confusing for folks like me who have been using JavaScript since the 1995.
The following sections go through 10 or so examples of JavaScript you will see in the wild with the intent of helping you to detect what kind of JavaScript, libraries, frameworks, and tools are being used.
Commonly Found Examples of JavaScript in WordPress
Used For: Everything. In particular, WordPress core tries to avoid JS frameworks in any frontend code. Plugin and theme developers have been moving toward using Vanilla JS vs libraries like jQuery.
Identifying Features: window, document, getElementById, addEventListener (most libraries and frameworks have shortcuts for these).
Used For: Reducing the bandwidth of network requests. WordPress will also try to combine JS into a single file unless you have the SCRIPT_DEBUG constant set to true.
Identifying Features: .min.js extension. Lack of spaces and returns. eval() function.
Used For: Breaking into your admin dashboard. Inserting spam links into your posts.
Identifying Features: Code that is inserted inline into PHP and HTML files are usually not minimized. If you see an eval() like this in a .php file, especially if it is out of place or the same code in multiple files, it is usually malware. Use scanners.
Used For: jQuery made it easier to do DOM manipulation like this, toggling the display of fields based on other fields. Also made AJAX easier at the time.
Identifying Features: jQuery or $, CSS selectors, .show(), .hide(), .ajax().
Used For: Asynchronous JavaScript and XML. Asynchronous = making many calls back and forth with the web server once a page is loaded. Usually sending small amounts of data rather than the full page. Originally used XML as the primary data format. Now use JSON a lot.
Identifying Features: ajaxurl, data, error, success, complete jQuery really made it easier to do AJAX requests. Before that you would use the XMLHttpRequest and use a bit more complicated code to manage the state of the requests. Modern JavaScript has the fetch command, which is more similar to how jQuery and other libraries use AJAX without requiring a library. (I’m looking for a good fetch example to add if you have one in some real WordPress code.)
Used For: Storing data in a way that is human readable and easy to parse. JSON can be pasted directly into JavaScript and interpreted. So the json_encode PHP function can be used to get variables into JS inline in a pinch. Using wp_localize_script is even better. JSON is perfect for sending data back and forth between JavaScript powered frontend and backend code. Also great for configuration files like those used for webpack and babel.
Used For: If you have a single use script meant to be used exactly on one page/template/etc, I still think it’s okay to put JavaScript into a <script> tag in your PHP code. In general tholugh, you should put JavaScript in a .js file and get data into your scripts through wp_localize_script and AJAX.
Identifying Features: script tags. found in .php files. If one piece of inline JavaScript breaks, it will halt the execution of all inline JavaScript. One of the many reasons putting JS in its own file is better.
Used For: JavaScript is updated annually with new features. ES5 is the generally accepted baseline based on EcmaScript2015. ES6 added a lot of popular features. ESNext is shorthand for the latest. Use babel to polyfill your ESNext code.
Used For: “A JavaScript library for building user interfaces”. Started by Facebook. Library of “components” you can reuse across UI code. Manages “state” of UI to update things automatically as new data comes in. REACT Native for mobile development.
Identifying Features: import { … } from ‘react’, class … extends React.Component, React.createElement, JSX (New way to use HTML inside of JavaScript)
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.
One of the biggest mistakes made by website owners is to have a website that is totally detached from any business activity.
Maybe your website is beautiful. Maybe it has tons of information about your business. But what is the goal of your website?
What do you want people who visit your website to do?
If you haven’t thought about this question yet, do it. Some good answers are:
Buy my product.
Sign up for my mailing list.
Call me for an appointment.
Follow me on social media.
Fill out a contact form.
Mistake #1 has a corollary: Too Many Goals.
When asked what the goal of your website is, you might have answered 2-5 things. Great! Throw away items 2 through 5. What was your first answer? Do that. On your homepage.
I’ll be speaking at WordCamp Philly coming up October 20th and 21st this year. Would you like to join me? Do you want to mingle with the smartest folks working on WordPress in the Philly area and beyond? Are you a little strapped for cash and balking at the $20-$25 tickets?
Well have no fear. We’ve raised enough money via CharityGoal (runs on WordPress, show it some love) to provide scholarships for 4 attendees to this year’s WordCamp Philly. Big thanks to Scott Kingsley Clark who donated on behalf of the Pods Framework.
What?
One Saturday or Full Weekend Pass (your choice) to WordCamp Philly, October 20th and 21st 2012.
How?
Make sure you are available to attend. Did I mention the conference is October 20th and 21st, 2012?
Write in the comments here or by email (a) how you would benefit from going to WordCamp Philly, and (b) why we should pick you over the others trying.
Optionally, send out a tweet thanking @Jason_Coleman and @ScottClark for the opportunity.
I will pick four lucky winners by October 1st and announce them here.
Last Saturday at WordCamp Philly, I ran a session on “Building a Plugin in One Night”. Together, with about 50+ attendees, we brainstormed ideas for a new WordPress plugin that I could code that night.
The brainstorming went great, coming up with some good ideas… like plugins to:
Help first responders after a disaster (Big Idea!)
Add VIM (a Linux editor) shortcut commands to the Visual Editor
Disable the Visual Editor on a per-post basis (The Winner)
Add syntax highlighting to the Visual Editor (Chris did it!)
The concept that the audience voted for me to work on was a way to disable the Visual Editor tab on a per-post basis. The motivation for this is the fact that the autoformatting of the Visual tab will sometimes break a complicated (or not so complicated) HTML structure ruining your code. Folks wanted a way to say, “Hey, WordPress, back off on this page/post”
And someone (you introduced yourself to me later, but I forget your name) came up with a kick ass name: Don’t Break the Code. It explains the purpose and also harkens back to my days at Haverford College, which has a strong social/academic honor code.
I’m happy to announce the launch of CharityGoal. This is a site we built for a client whose goal is to enable anyone to raise money for any (legal) cause. CharityGoal gives you an easy way to accept donations online, a beautiful landing page, and quick access to social network sharing.
For those interested, the site is built on top of WordPress. “Causes” are custom post types. A custom plugin we developed allows users who have signed up to create new causes through a front end form and to manage that cause. The checkout code was pulled from the Paid Memberships Pro plugin (also developed by us and GPL) and tweaked to work specifically for this site.
So take a look. While you at it, I’d appreciate a donation to our cause:
