Making WordPress plugins is fun, but is it a good business move for you?
In the end of 2014 I decided to start a commercial WordPress plugin company. In March 2015 David Cramer and I launched CalderaWP. We went to market with an add-on for Pods and add-ons for Caldera Forms. David and I met when he started contributing to Pods, where I worked at the time, and I was super-impressed by the UI in Caldera Forms. It worked the way I wanted my plugins to work.
A little over a year later I’ve started to look back at how it’s gone and how we could have done better. I want to share this in hopes you can learn something from my experience. This article is based on a tweet storm I sent recently.
To be honest, I was hesitant to write this post beacuse we’re doing OK, but we’re not having the kind of success that I see in the transparency reports from plugin companies that are killing it. But, I want to offer an honest and realistic vision of what it’s like to be a year out, and well positioned for success.
Speaking Of Imposer Syndrome
I just shared a bit of my self-doubt about sharing business advice. As a developer, it has been at time hard for many to get past “I’m not good enough for this.”
Do you know what? Fuck that.
I'm stupid excited to announce I've been working on a four part video course on the WordPress REST API. You can pre-order and save today:)
I’ve had so much fun teaching myself the WordPress REST API for the last year or so. Part of what has made the experience so great is sharing what I’ve learned a long the way — tutorials, WordCamp talks, Podcast appearances, a free ebook. I can’t decide what I love more — using the REST API to build custom APIs the WordPress way or sharing what I’ve learned. So, I’ll just keep doing both.
That’s why I’m happy to announce I’m working on a four part video course, teaching you how to use the WordPress REST API.
Actually, it is already in use by those doing the coolest stuff with WordPress.
WordPress just hit 25% market share among content management systems. That’s awesome, the more growth in our industry the more potential customers or clients there are for people like you and me who offer WordPress services and products. We know that there are a lot of negative opinions about WordPress out there. Some of them are fair, some of them are not.
The more times we can exceed the pre-conceived opinions about WordPress, deliver more “You can do that with WordPress?” moments, the more our industry will grow. I want you to be the one to deliver that “wow” moment to your clients. I want you to
We were all told the REST API was the future. Then we tried it and said “the future looks awesome.” Let’s not let go of that future.
Recently I sat down with the developer of Morning Frame, a really cool analytics integrator, to help him figure out how to integrate with WordPress. I had to explain, as best as I could, the difference between the WordPress.com API, the JetPack JSON API module, and the WordPress REST API. Explaining, to someone with little experience of WordPress, the subtleties of how the WordPress.com API relates to the JetPack JSON API module, and how the real one is the one that’s in a plugin, but it’s in a feature plugin, which is…
Yah, it got confusing.
The WordPress REST API has seemed like a forgone conclusion for inclusion in WordPress 4.4. Matt Mullenweg said during his last State of the Word that it would be in core “sometime in 2015,” and while no one contradicted him, there was no official word from the core team.
While there has been ambiguity, it’s the topic that everyone wants to discuss at WordCamps. It’s the only reason why application developers from all sorts of backgrounds are looking at WordPress as the back-end for their apps. And the API itself the code is really beautifully with really lovely extensibility. It’s also in use on high traffic sites, has a dedicated team of “core”
Josh delivers a succint overview of what you need to do modern WordPress development. Tuts like this should be required reading.
I’m teaching a few workshops this month aimed at those looking to level up their WordPress development chops. It’s got me thinking a lot about what you need to do quality WordPress development. It’s a very subjective question, what software to use, what principles to value, what resources to learn from… So I wanted to share my thoughts on what is necessary for getting started. The list is less about software, and more about concepts because in the end, it’s about the wizard, not the wand.
You can write code in notepad and FTP it up to a shared host and hope for the best, but to do it right you need some basics tools. Here is my opinionated list. I’ve broken it down into “basics” and “important”. The first category is things you should have right away. The second list is important, but can probably wait.
A code editor is a specialized text editor designed for writing code. I like Atom as my simple code editor. It’s the application I use when I just need to open up a file, read it and maybe make a few changes.
An Integrated Development Environment (IDE) is more than a code editor. A good IDE provides everything
Trying to understand the animosity and how we might move forward, with out excusing anyone who has crossed the line to harassment or letting myself off the hook.
Last week, Tom McFarlin laid down the hammer on the level of animosity that is currently all to present in many parts of our community. I thank him for doing so. When something is wrong in a community, its leaders have to stand up and say no. From discussions around to the customizer, to discussions about the WordPress Foundation’s lawsuit against WordPressHelpers, the tone of the debate has gotten ugly and in many cases become downright harassing.
Tom is very right — it needs to stop. But wishing doesn’t make it so. So I wanted to offer a few thoughts on where this frustration is coming from, while resisting the urge to throw in my 2 cents in on the actual issues being debated… for now.
I think understanding is important for improving communication and decreasing animosity. Before I do I want to say three quick things:
At the end of the day it’s going to take more than understanding, it’s going to take leaders in our community saying “this isn’t right.” Maybe we need a hashtag that is the reverse of the #wpdrama tag that can be used to point, hopefully with some humor, that what is happening is not cool.
More so than every other article I’ve ever written, some, if not all of what I’m
Would your plugin or your business be better off as a SAAS service?
Categories Articles, WordPressTags business, saas For the last year or so, I can’t get into a discussion about the WordPress plugin business without hearing why I’ve got to go SAAS, seriously SAAS, get that recurring revenue. I’m constantly hearing about why I need to turn my plugins into a software as a service (SAAS) model or create a SAAS business.
This worries me. The SAAS obsession can leads to businesses designed around a business model, instead of fitting a business model to a solution for a specific pain point. Also, the got to go SAAS brah push is paved with promises that it might not be able to deliver, depending on the product.
Don’t get me wrong, there is a lot of upside to a SAAS for developer, business and end user. So I’m not anti-SAAS or incorporating some of its benefits into a traditional plugin. I just think we need to break down why these things do or do not make sense.
Get Monthly Recurring Revenue
They want you to think you can’t charge for your plugin monthly
A lot of time I hear that I need to make my plugins a SAAS business so I can get monthly recurring revenue. This argument has at least three logical flaws.
It assumes you can’t charge for a plugin monthly
I shared my Caldera journey into commercial plugin development and some exciting news about what is changing for my team.
I started 2015 stranded by a freak storm in a small town in West Texas. I ended it wondering if I had what it took to make it as an entrepreneur. In between I launched a new company or two, traveled to ten WordCamps and the one constant that held was community. Those two days in Balmorhea, TX population 500, were actually pretty inspiring. After a scary night trying to get off the road and stay warm sleeping on a blocked highway off ramp, my wife and I made it to the one little inn, which was sold out and sent us to the community center turned shelter.
This tiny community, which clearly was not very well off came together to organize food, cots and more to keep over 100 people fed and safe until the roads were relatively safe to travel. Being stuck in an overcrowded community center is not the best experience. But being a part of a spontaneous and self-organizing community that arose to help out strangers made a bad situation into a great experience.
It reminded me of the value of community. You know like WordPress always does.
Back In The Sun
Who knew it snowed in Texas?
Six weeks later, back in sunny Florida, David Cramer and I launched a new company to monetize his plugin Caldera
Somewhere, in a parallel universe, I’m teaching high school science in an under-served New York City public school. At the beginning of the journey that led me to becoming a WordPress developer, I turned down an opportunity to join the New York City Teaching Fellows. This was 2010 and New York City was balancing its budget by slashing education funding. It was the wrong time to go into teaching, but I do sometimes regret not becoming a teacher.
But one of the things that the WordPress community has given me is the opportunity to teach. It’s something I love to do — writing about WordPress development, speaking at WordCamps and creating my REST API course — it’s all something I just can’t get enough of. I’m always looking for ways to teach more.
Plugin Development For Everyone
Today, I’m super excited to announce a new course “WordPress Plugin Development With The WordPress REST API.” This course is what you need to get started with modern WordPress development. It’s not just about the WordPress REST API, but obviously that’s a huge part of what I will teach.
This course is not just for people who want to develop
I recapped my year in WordPress, to help short-circuit my self-sabotaging and to stop and remember how awesome this year has been.
Categories WordPress, ArticlesTags WordCamp, community, growth, awesome, wcus There are a lot of reasons why my wife is awesome. Sharing my life with someone who is so driven and focused on her ambition inspires me. One of the many positive qualities she has is how well she takes a compliment.
It’s something I’m working on to learning to emulate. I’m getting a lot better at not replying to a denial or compliment with a self-deprecating joke, which used to be my default.
While I still have work to do, I think the way I worded the last paragraph, compared to how I express the thought it in my “mental draft” of this article — “it’s something I fucking suck at.” shows my progress.
At WordCamp US I met a lot of people who I had helped through support, an article or one of my plugins. I had to work hard to take these compliments well.
When we deny compliments we are not only being rude to a person who is being incredibly kind to us, we are tearing ourselves down. Negating compliments is detrimental to self-confidence, self-respect and self-optimization.
It’s lying to yourself.
#realtalk I’m Awesome
See, I can do this!
I know I’m awesome and I don’t need other people to tell me that. But,
Too much of the talk about what the "typical WordPress user" is capable of down right condescending to our users, but I suspect that trying to define one typical user, instead of an array of profiles is a fatal flaw.
Categories WordPress, ChallengesTags growth, wcus, challenges, users, assumptions Over the last few years, I’ve provided a lot of support for WordPress users, so the low opinion many in our community have about the “typical WordPress user” is not shocking. Having the privilege of attending WordCamp US and the WordPress community summit was a highlight of my year, and I had a great time but a few things about the experience were very disappointing.
The biggest disappointment was hearing so many people put down the intelligence of WordPress users.
There is a lot of disagreement on what a typical WordPress user is and what they can do. I witnessed and participated in some really serious disagreements about what a typical WordPress user can and can’t do. Whether they can use FTP, click 3 inputs in cPanel to update PHP, are a total moron, etc.
Too often this discussion becomes condescending towards the regular folks who make up the huge adoption numbers we see, and buy the products and services that make it possible for all of us to make a living.
This dismissive view of users is worse than the coffee was at WordCamp US. It’s fine to be a coffee snob, it’s not OK to look down at other for
I want to introduce you to Ingot, the new tool I've built for evolving your website's content to boost your conversions as well as Team Ingot.
Categories WordPressTags growth, ingot, announcements, products Recently I was setting up a MailChimp campaign and the MailChimp interface asked me if I wanted to run an A/B test. Of course I do, MailChimp. You’ve got to A/B test everything. I’ve been on the internet, I know that to be the truth.
So, I started setting up an A/B test for subject line, but then it occurred to me that I already did that. I wasn’t sure so I looked through my campaigns and found I was right. So then I set up another test of course, because thou shalt A/B test all the things. Then it came time to enter my from line, so I had to look up what had one last time.
This is why I never A/B test and I hardly ever read my Google Analytics — I don’t have time for that. Read it, analyze it, apply what I’ve learned on my site and then start the testing over again. I’m already doing too many things, I want to set up all of the different options and let my site figure out over time what converts best and use that.
So, speaking of doing too many things at once, I wrote that plugin.
Ingot is the “do less, convert more” tool that anyone who wants to make more sales, get more downloads, increase their email list
My company CalderaWP announced a new partnership with WordImpress, makers of GiveWP yesterday that we was about more than the GPL, it was about building relationships.
Awhile back I was working on the the Authorize.net add-on for Caldera Forms. Let’s just say it wasn’t going well. I sent Matt Cromwell from WordImpress, the makers of GiveWP — an awesome way to accept donations on your WordPress site — if I could take a look at their Authorize.net add-on. I know Matt through the AdvancedWP Facebook group that he moderates, and had the pleasure of meeting him and WordImpress/GiveWP lead developer Devin Walker at WordCamp Miami.
Matt sent it over and I found it very useful. So useful, that I started making the Caldera Forms Authorize.net integration based on it. Now, because Give and all its Addons are GPL, that’s something I have every right to do. It’s something that they explicitly gave each and every one of us permission to do under the GPL.
This led to a new partnership between their company and mine, CalderaWP. I wanted to share more about why I approach this relationship the way we did.
Helping Your Neighbors
Personally, I learn by reading source code, and often adapt other people’s code into my own. I could have just bought all of their add-ons as reference and source material for Caldera Forms add-ons. In fact, when I started talking to Matt
Josh Pollock has become on of the preeminent voices and experts on the WordPress REST API. If you want to get into it, this is probably the #1 best way to do that.
Categories WordPressTags rest-api The future of WordPress is the WordPress REST API. The future is here — it’s just not evenly distributed. The WordPress REST API is slowly maturing into a new and exciting tool, but it requires learning a whole lot of new skills and patterns.
I’ve had a blast writing and talking about what you can do with the REST API. In addition I’ve had the pleasure of presenting about the REST API at WordCamps all over the country. More importantly I’ve been putting it to use in my own work.
Today, I am releasing a four part video course about the REST API, with 17 videos in total. The premise of this course is that with the REST API, you can exceed expectations of what your users and clients expect from WordPress.
I genuinely believe that the WordPress REST API — once you master it — will allow you to deliver better more exciting, scalable and manageable results. It’s a new skill you need to learn, but it’s worth it. Don’t forget once you’re exceeding the standard of what people expect that you start charging more.
Also, I made a 4 part video course about the WordPress REST API, that is available for sale today. Each of the four parts is a series of You can purchase
The opportunity to write a big WordPress plugin -- Ingot, my automated A/B testing plugin -- allowed me to put a lot of my opinions on PHP development top the test. This is the first part of a series on what I learned.
Categories WordPressTags development, rest-api, php, ingot Over the last few months I’ve put a lot of time into writing Ingot — an automated A/B testing and conversion optimization plugin for WordPress. Because Josh, I did a lot of other things at the same time — but Ingot was my biggest project.
Ingot is probably the biggest plugins, in terms of lines of PHP code, that I wrote. I’ve worked on bigger plugins, but never as the primary developer. Pods and Caldera Forms are bigger, but my contributions code-wise to those are not huge.
For Ingot I wrote all of the PHP code. Roy Sivan helped me build the admin interface, which is an Angular app. He was also a valuable sounding board and bug catcher for the rest of the plugin.
I wanted to share some of the lessons I learned, as a developer, writing a big plugin. Writing this plugin from scratch allowed me to put to test a lot of my personal opinions on WordPress development. I’m going to follow this article with one specifically about coding a plugin around the WordPress REST API and another with some lessons I learned as an entrepreneur from the process.
Separations of Concerns
Working with the WordPress REST API helps encourage separation
If Automattic just bought WooThemes for a WooCommerce-powered eCommerce offering, they could have just installed the plugin and saved themselves what is rumored to be $30 million dollars. If that is true, as everyone assumes, no one can ever complain about spending a few hundred or thousand on WooCommerce add-ons.
There has been a lot of speculation and analysis about the WooMattic deal — why it happened, what it means for the future of WordPress.com and the ecosystem as a whole. A lot of people have assumed Automattic bought WooThemes, so they could use WooCommerce to power a WordPress.com eCommerce offering. That seems like a funny reason to spend what is rumored to be $30 million. If they just wanted to use WooCommerce, they could have just installed the plugin. If that’s why, then no one can ever complain about spending a few hundred or thousand on WooCommerce add-ons.
I think the real value here, besides a new revenue stream, is the people. Automattic is growing rapidly and finding employees who can thrive in a distributed company has to be a constant challenge for them. They just got fifty-some new employees, all of which are used to working remotely.
And yes, a lot of those people are experienced in building a WordPress eCommerce platform. WooCommerce-powered or built from scratch, a hosted eCommerce platform would be a very smart thing for Automattic to branch out into.
In addition, the leadership of WooCommerce is used to managing and planning a retail product-based business. Automattic
Anyone who has ever made a product knows how hard it is to make the right decisions to describe, sell and price their product. That's been my life for too long now. This year, I'm making data driven decisions.
Categories Articles, Business, WordPressTags a/b testing, ingot, wordpress There are a lot of ways my business causes me anxiety. This is an unescapable part of being an entrepreneur.
The biggest inducer of anxiety is decisions with no clear answer. Nothing makes this happen more than when trying to figure out the best way to describe my product.
I have a few different slogans I use for Caldera Forms, and I’ve never been sure what was the best one to use. It’s a source of constant worry for me if I’m using the wrong one, or if it doesn’t matter at all.
One slogan is descriptive, one says it’s different and one says it’s easy.
I’ve spent a lot of time debating over which one is best and I can make a good case for each. Without any data, I can’t know for sure, and honestly it’s been driving me a bit nuts.
Split Testing FTW
So, the other night I installed Ingot, on CalderaWP.com and started testing the three slogans. I’m using the new “destination test” feature we added in the last version. This allows me to drop a shortcode into my content, where I normally would use the slogan, and track a conversion when a product is added to the cart.
I might find that the slogan has no effect on conversion
As a user of WordPress, I expect realtime visual feedback, from post editing, or any other visual changes on my site. I want to edit and preview what I do in context, not in the abstract.
Imagine this: A client comes to you and says they want you to develop a web application. They show you a list of requirements, and in it there are a lot of options for the end user to customize the look and other front-end functionality of the app.
Then they tell you that they want some of these visual options to be managed in a real-time updating interface, that shows a preview of the site, and some to be managed in an interface with no visual feedback at all.
I don’t know about you, but I’d tell them that having two interfaces for controlling the presentation layer of their app is going to create a confusing user experience and that they needed to choose one or the other. My personal vote would be for the one with the real time feedback.
Change Requires Perspective
“Automatic updates in WordPress are going to destroy everything.” – The ghost of #wpdrama past
As WordPress users, or as someone whose job it is to deliver and maintain client sites using WordPress, change often sucks. But on a project as large as WordPress, change can’t be viewed from the level of the site, but requires a more global perspective.
I don’t know what it’s like to be a core developer. I do think that maintaining
Ingot was my opportunity to put to the test what I thought about how the WordPress REST API changes WordPress plugin development. I'm excited to share what I learned.
Categories Uncategorized Over the last few months I’ve been working on creating a totally self-contained WordPress A/B testing plugin. It’s called Ingot, and we released version 1 right after christmas.
Since I did almost all of the development myself from scratch I was able to do it all “the Josh way” and refine what that even means. This allowed me to put a lot of my opinions on WordPress development to the test. I shared a lot of what I learned in yesterday’s post.
Today, I wanted to follow up yesterday’s post with what I think it means to create a WordPress plugin using the REST API. Next week, I’ll talk about the business and product design lessons I learned from Ingot. The design decisions that went into building the Ingot REST API will be a big part of that discussion.
How Things Change
As most people reading this know, I spent a lot of time over the last year or so thinking about how the WordPress
A quick case study on using cookie-based authentication for plugins or core development if the content API is merged into core.
A big push back against the WordPress REST API has been a feeling that a lack of authentication system makes these endpoints not useful. This is strange to me, since the content endpoints use the exact same permissions system as the rest of WordPress. @Josh412 My understanding is that cookie-based isn't the right method for a lot of uses, but any non-cookie-auth right now = dependency.
— Helen 侯-Sandí (@helenhousandi) October 14, 2016
I think a lot of this confusion comes from the excitement about building cool apps that connect from outside of WordPress via the REST API. In those cases, WordPress’ cookie-based authentication does not work. Therefore a different solution is needed. oAuth1, oAuth2, JWT, a custom system, etc.
I like JWT a lot by the way in those scenarios. This plugin makes it very easy.
But what about when we are using the REST API to improve WordPress from inside of a WordPress theme or plugin? Or what if — presuming the content endpoints make it into WordPress 4.7?
In those cases, cookie-based authentication, which is super easy to use, is all we need. This is especially exciting for core. I’d love to see the REST API used for content
A few years ago I got bored and decided to write a blog. Not sure why I chose WordPress.com, but of all the random decisions I’ve made, few have seemed so trivial at the time, and made such a big impact on my life -- because ya'll are awesome.
A few years ago I got bored and decided to write a blog. For some reason, I chose to use WordPress.com, which I had never heard of before, instead of Blogger.com. I don’t remember why I made that decision, or how I even found out that WordPress was a thing. Of all the random decisions I’ve made, few have seemed so trivial at the time, and made such a big impact on my life.
For these last few weeks we’ve been talking about all the #wpdrama, and how to move forward from it. It’s an important discussion that we must have. There will always be examples of people in our space doing things that seem shitty.
But we can’t let it trick us, those who make up the WordPress community, that we are in fact awesome. We spend our time figuring out how to empower ourselves and others to tell our stories, make a living and keep writing cool shit, with a mantra of “add value.”
For the most part, the people who rise to the top of this community, are those who not just figure out how to add the most value, but how to get paid for it.
Sometimes I forget why I got into all of this, and that doesn’t matter. I’ve stuck around for two big reasons. That — the idea that everything we do is creating something free,
Here Josh is talking about using Composer for deploying WordPress Plugins and sites.
I’m a big fan of Composer, which I believe will give you super powers. I am happy that it is gaining in popularity in the WordPress world. I often hear from developers who love it, but are not sure what to do about the vendor directory in their plugins or themes or sites. I spoke about the advantages of challenges of using Composer in a recent episode of The Plugin Architect podcast. I use Composer in most of my plugins. Most of Ingot’s code is in Composer packages, which helps us share code between different versions and add-ons. I also helped refactor the plugins Maps Builder and Maps Builder Pro by WordImpress to make sharing code between the pro and free versions easier.
Often times people are not sure what to commit or gitignore and the best way to deploy their code to keep their package size small. I’d like to answer a few questions to help you make the best of Composer for WordPress development.
Should You Ignore The Vendor Directory In Your Git Repo?
A lot of people are hesitant to gitignore the vendor directory and other dependencies in their GIT repos. Most of the managed hosts encourage you to use GIT to manage your dependencies when using GIT
Getting new people involved in the WordPress community requires showing them ways they can match their unique gifts to projects that need their help. A new "contribute" tab in the "About" section is one good way to show off all the different ways people can get involved with the WordPress community. I wrote an initial patch to add this tab, but I need your help to make it great, and into core.
For Christmas and New Years my wife and I drove to Phoenix to spend time with my mother and law and her husband. It was a great trip. On the way back, we got caught for two days in a snow storm in Western Texas. We were so truly lucky to have found ourselves, after some of the most terrifying driving I have ever done, and a night spent on a highway off-ramp in Balmorhea, Texas–population 490. I say lucky because we spent the next twenty-four hours or so in this small town’s community center, with around a hundred other stranded travelers.
In response to a post on Facebook by the sheriff, people form the town showed up with food, blankets and cots. They worked to get the local news, Red Cross, and county government involved.
The whole experience was surprisingly not terrible. Why? Because the people in the town did enough to get the ball rolling, and empowered those of us who were stranded to do the rest. Instead of sitting around bored all day, we spent the day helping others. It was actually really nice.
Then I Saw The Tweets
When the storm finally cleared, we hit the road. My wife was behind the wheal, and I was checking Twitter of course. That’s when I found out that Kim Parsell
A quick look at how to get post_meta fields using the magic properties of the WP_Post object, and how to use the __get() magic method in your own classes.
Ok, maybe I’m the last on to arrive at the party on this, but I somehow never realized that you can get any post_meta field by using its key as a property of a WP_Post object. Pretty useful. It means that if you have a WP_Post object, and the post it represents has a meta_key called “josh,” you don’t need to use get_post_meta(), you can use $post->josh. Here are some examples:
How does it work? It works thanks to the way the __get() magic method is used in the WP_Post class. If a class has this magic method, it will run anytime a property that doesn’t actually exist is called. In WP_Post it is used for a few fields that are not in the post table, and therefore are not retrieved by the main query for the post.
As always, taking a look at the source, and then trying it out, is the best way to learn. Here is the __get() from WP_Post, copied from the source for your convenience:
Why am I thinking about this? In Caldera Forms we have the ability to auto-populate select fields from a specific post type, or taxonomy. I’m working on adding an autocomplete/ select2 field type that will be able to use this auto-population option.
As a result, I’m looking at how to make them more useful and flexible.
Developing plugins isn't easy, particularly as you add increasingly advanced functionality. Josh shares his insights into some of the more challenging new tweaks and features of his popular Caldera Forms plugin.
Last week, we release a new version of Caldera Forms and a new form translations add-on for Caldera Forms. These were both fun projects to work on and I wanted to share a more technical overview of some of what I did on those projects than I gave in the official release post. I hope this post is interesting and useful to all WordPress developers, whether you are a Caldera Forms user or not. But if you’re not, maybe it’s time to try it
Multi-lingual forms, more accessible WordPress forms and more. Four releases and an invitation to enjoy a taco with us at WordCamp US.
Caldera Forms Translations
Previously, When using Caldera Forms or most other form builders on a multi-lingual site, you had to have to create multiple forms, one per language. That is a pain to manage. Making one change meant editing multiple forms.
Caldera Forms Translations is our new translations add-on. One forms, many languages. I originally was planning this as a feature of the core plugin since we didn’t want to make it a paid add-on. That said, figuring out if a form has translations, then if each field has a translation, and then if that translation is in the right language introduces a bit of