Zerif Lite Suspended from WordPress Theme Directory, 300K Users Left Without Updates

Zerif Lite, one of the most popular themes on WordPress.org, has been suspended by the Theme Review Team for several violations of the Presentation vs. Functionality guideline. As a result, more than 300,000 users (including those on child themes of Zerif Lite) can no longer receive maintenance and security updates to the theme.

Justin Tadlock, an admin on the Theme Review Team, performed a comprehensive review of Zerif Lite and found a dozen violations of the requirements, some of which had been outstanding for more than 15 months. The team often receives complaints from theme authors who point to Zerif Lite as an example of a theme that is allowed to skirt the rules.

“We’ve been extremely lenient and fair with this theme, moreso than we’ve ever been with any theme in the history of the TRT as far as I’m aware,” Tadlock said. “But, at a certain point, we’ve got to make sure that Zerif Lite is following all the same rules that other themes have to follow.”

During the course of this exchange, ThemeIsle, the company behind the theme, fixed a few of the more trivial issues. However, the final sticking point was the issue of psuedo custom post types. ThemeIsle published a post to explain to its users why the theme was suspended:

One of the things that we’ve been requested to change with Zerif Lite is using “faux custom post types.” Basically, this is about using those small custom content blocks that appear on the homepage of the theme to present things like team info, about block, testimonials, etc.

Those are used just on the homepage and nowhere else. According to the current rules, we should have set true custom post types for those. This, kind of, makes sense if you’re building a new theme, but changing this in an existing theme means that whoever’s currently using it will get their site messed up. And in our case that means 300,000+ people (including the child themes).

The image below shows an example of the type of content in Zerif Lite that the Theme Review Team is requiring to be migrated to custom post types.

An example of Zerif Lite faux custom post types
An example of Zerif Lite faux custom post types

The authors of Zerif Lite were given two weeks to comply with the requirements but decided they didn’t want to break 300,000 sites with a requirement to install plugins to store the front page content as custom post types. The theme was suspended from the directory this week.

This isn’t the first time the Presentation vs. Functionality guideline has been enforced. The TRT began cracking down on violations more than a year ago and Zerif Lite was at the forefront of that conversation as a prime example under consideration.

In his post about Zerif Lite’s suspension, Ionut Neagu, CEO of ThemeIsle, cites a quote from Matt Mullenweg, who joined a TRT meeting following the heated discussion on the issue last year.

“We have a lot of hard and strict rules designed to ‘protect’ users, like around CPTs et al, but someone could make an informed decision to trade off future potential portability for current form or functionality,” Mullenweg said. “It would be a perfectly rational decision to make.”

At that time, Mullenweg encouraged the team to step back and examine the submission process and the directory in a new way that would encourage creativity among theme authors with fewer guidelines and restrictions. In response, the TRT issued a series of surveys but the guidelines have remained the same. Zerif Lite is now being required to meet all of the guidelines with no exceptions.

“On the one hand, if you don’t make the changes, you’ll be banned from the repo,” Neagu said. “If you do make the changes, you stay in the repo, but you’re messing up the sites of your current users. Which is worse?

“In my view, disrupting the current user experience is just not worth it, and until we find a way to keep that user experience intact – and in a way that the review team is cool with (so far, our suggestions haven’t been received well) – we will have to stay suspended from the repo,” he said.

Neagu estimates that Zerif Lite’s suspension from the directory will diminish the company’s $70K/month revenue by 50%, as most of it is driven by Zerif purchases. ThemeIsle, which employes a 15-person team, will be reducing its expenses in preparation for the dip in sales. Neagu said they plan to cut out sponsorships for things like WordCamps and Pods.io, among other things, in order to make up the difference.

“Obviously we all feel disappointed with the decision, we feel it isn’t fair and believe that we did our fair share of contribution towards the community,” Neagu said. “However, complaining or starting a kind of war is not something we want to do. We would rather ‘fight’ to make the WordPress.org themes repository a better place for both users and developers.” The company and its employees still plan to volunteer, review themes, and submit new themes to the directory, despite the suspension of their flagship theme.

ThemeIsle has no way to contact the 300,000 Zerif Lite users. The company has created a plugin called Zerif Lite Transition so users can safely continue to use the theme and get updates when available. The plugin also applies to sites that are using Zerif Lite as a parent to a child theme.

151 Comments


  1. Mr. Tadlock waited 16 months to take action on issues that would prevent any other theme from being approved in the first place. And Mr. Tadlock isn’t the only person involved in the decision. I’m the one who brought the issues up to the developer, 16 months ago:

    https://themes.trac.wordpress.org/ticket/24907#comment:5

    The TRT has been more than fair and patient here – to the point of being unfair to other theme developers if no action was taken.

    Report


    1. Hey Chip,

      Is a bit off-topic but honestly nobody here was aware that we have x months to solve something, 15 months ago everybody stopped saying something and after the slack chat with Matt and other members I just thought everything is fine.

      Now coming and saying that that we had 15 months to fix this sounds weird and misleading for me. Maybe is just our fault that we got it wrong, however still we would had same discussion, now or 15 months ago

      Report


  2. Before you start saying stupid stuff like that you should really go and read that trac ticket.

    This article points out that they had more than 15 months. This isn’t the first time they were warned.

    It’s the other way around, the guys behind zerif had all the interest to delay this final review. They did know for a long time most that they are breaking most of TRT’s requirements. The only reason they kept doing this is for money.

    Report


  3. If my eyes rolled any harder at this, I could go back in time.

    Report


  4. Personally, I’m glad to see the guidelines being enforced. Sixteen months is a more than reasonable time to get the issues fixed, and Theme Isle is of course completely free to choose not to comply with them, and host their theme themselves. If guidelines aren’t enforced for everybody, then you can’t enforce them with anybody. And the theme lock-in effect causes all kinds of problems for users when they want to change themes.

    Report


    1. I think the timeframe is completely irrelevant in this case, because there was no solution presented (or allowed out of those we suggested) that could update the users’ websites without breaking them first.

      When is the right moment to break your user’s website?

      I think the focus should be on the users and not WordPress or ThemeIsle.

      Disclaimer: I am part of ThemeIsle’s team

      Report


      1. your company had SIXTEEN MONTHS to fix things, you didn’t. Now you know what happens.

        If you can’t or don’t want to follow the rules, you DO NOT have to be hosted in WordPress.org

        Report


      2. Why are you splitting this up into WordPress vs ThemeIsle? This is about the users, we couldn’t offer a smooth transition.

        Right now, the problem is still “what will we do with these users?”, there is no way to send a bug fix, a security update or just to add some of the latest recommended features.

        It’s funny that the discussion is still about whether we were right or WordPress Review Team was right and nobody asks the right question:
        “What will we do with those 300,000 WordPress (and ThemeIsle) users?”

        In my opinion, the WordPress community is not made of developers only and we should start focusing more on the users who actually make the majority.

        Report


      3. Why couldn’t there be a halt in the current development and no updates(what you have now anyway), re-built the theme into a v2 with proper guide implementation ? and give the users 16months to transition ? (or not)
        Just a path that comes to mind very quickly.
        It’s not like it’s Angular1 vs 2 here imho..

        Report


  5. This action seems driven by the complaints of other theme authors rather than the complaints of end users. Perhaps the rules surrounding theme submission to the repo should be relaxed for everyone – limited only to security concerns perhaps, let the market sort out the rest.

    It seems very few popular themes are published on the .org repo, to the point where people often search elsewhere when they’re looking for a new theme. Is it possible the current rules (and the long review time necessary to enforce them) are partially to blame?

    Is it possible that absolute data portability isn’t an expectation or desire from most end users? That they expect to do some manual porting of data when they change themes? That they prize other features like site design and built-in functionality over something like data portability?

    Report


    1. I agree, one way to actually see this is by taking a look of many sales are getting the themes with custom content from ThemeForest.

      Guidelines should help the community and especially the end user.

      Report


  6. Couldn’t look farther from that. I trust Justin’s judgement on such issue more than my own.

    Low, inflammatory, baseless remark.

    Report


  7. What themeisle didn’t mention in their blog post is that they had 16 months to fix it.

    At that time, migrating users would have been much easier. If I’m not mistaken they had around 40-50k users. All the admins offered to help them migrate back then, as they did right now.

    They did know back then that moving all those CPTs would lose them money, so they didn’t change a thing.

    How is this fair to any theme author or even for users who are locked in, unable to move their content to a new theme.

    Report


    1. Hey,

      Would you mind sharing the solution where the end users wouldn’t lose their content from the website on update?

      Report


      1. I know very little of the discussion so i can ( and i will be wrong)

        Make a 1.5 version where:
        all the faux CPT are still there (so theme look neat)
        BUT you get asked to add proper CPT (so you follow guidelines.
        AND you get a Switch to move from faux CPT to proper CPT?

        Easy? i don’t know
        Cheap? I don’t think so
        Better than losing 35K/months? Yes.

        Report


      2. For your information, Make saves all the content in post_content. That is not a faux CPT and info will not be lost when you change themes.

        They will lose more money, around 50-60k, if you count as a loss the money they now need to reinvest :) . Only because a big portion of their traffic comes from wp.org, which was totally FREE. You should check out Alexa in a few months, I know it is not a proper tool, but still.

        Report


  8. While it might not a be a popular decision, Justin and the TRT made the correct one in my opinion.

    Report


      1. Hey Gary,

        The discussion around faux cpt isn’t that simple, here is my comment from the trac ticket :

        First of all that content was designed to be used just on the front-page, is a one-page theme and users want to be that way, creating 4 custom post types for a content that is still minimal, I don’t think it brings a lot of value, just way more complexity.
        The accepted and most widely used solution by themes with the same focus is to create a ‘companion’/’extensions’ plugin and throw all of those plugin-teritorry things there, how is this better ? Isn’t the content still locked in the db ? Or now is fine because is not a theme problem but a plugin problem ? While this approach follow the repo rules, I consider it to be worse, you are asking users to install a plugin to enjoy the theme, while continue to ‘lock’ that content.
        The other recommended solution is to use generic plugins, like recommending a team plugin, testimonials plugin, client plugin, contact form plugin and so on, plugins which are indeed more flexible and users can enjoy using them with other themes as well, but the thing here is that you trade-off the initial setup UX ( requiring and configuring 5 plugins to setup a simple one page theme isn’t the easiest thing for a user ) because you assume that users will need that in the future or you assume that there are other themes out there who can incorporate those 5 plugins as the current one is doing.
        In an ideal world I agree that 2nd solution is a good one, but isn’t the case in the current eco-system because isn’t mature enough, plugins will break theme functionality and the theme will break the plugin one ( even big plugins like WooCoomerce aren’t doing a great job in maintaining backward-compatibility ), while without being allowed to use an installer in the theme the whole installation/activation and configuration of those 5 plugins will be a nightmare.
        We are talking with a lot of users on a daily basis, we have themes build in the all 3 scenarios and by far people would prefer to go with the option 1, like we are doing in Zerif for one-page themes. If we are talking about a portfolio theme or about a review theme where 1 standalone plugin is required ( not companion-like ), of course is clear that the best thing you can do is to recommend that plugin so users can easily switch themes while maintaining their review ratings, tables and so on.

        Report


    1. I guess I that case it was content blocks, rather than say team or testimonials actually being there own custom post types being pulled into that section on the home page.

      Report


  9. Zerif didn’t respect the guidelines, I agree with that. But at some point Zerif was accepted in the repository so it means that it respected the guidelines from that time.
    If there is no way for a developer to change that theme without breaking a single site and follow the new guidelines at the same time, I really think it’s your fault guys.

    Report


    1. Why couldn’t Themeisle leave the “faux CPT” types and create an alternate solution on top/parallel that was acceptable? Sort of a phase out of old functionality to the new. I guess given 16 months was not enough time. *smirk*. I think they may be quick to respond if it affects the bottom line as drastically as is being discussed.

      Report


      1. An alternate and acceptable solution for this is to take all that code from the theme and put it in a plugin. We can recommend the plugin with tgm but the thing is it requires some input from the user.
        Imagine you just spend couple of hours reading theme documentation, writing content and search for pictures. Then we came with an update and say “Hey, we just deleted all your work :) … to get it back please install this plugin”…. How would that makes you feel? Would you ever use another product from us?
        We don’t do this. I’m a backend developer here at Themeisle. If you check the code you’ll see that we still have compatibility with versions of WordPress older than 4.1.0.

        Report


      2. Yeah. I agree. Lots of effort not just from the coding side but customer support. I am not a good example because if you explained to me the reason for what you were doing – transparency – I would figure out how to make the ‘plugin w/theme’ hybrid work (no joke intended). Others, less technical or inclined may behave as you suggest. You’ve sort of done this with the ‘plugin for updates’. Mr. Bennett seems to think this was a simple thing. What about the help offered by the TRT? Your thoughts?

        Report


      3. that could also be solved by taking the work done by the user and transition that into CPT. It’s maybe not simple or not something you’d want to spent time over, but it sure avoided all this.

        Report


  10. I think Ionut has done an excellent job in his post detailing the issues at play here and has put forth some very compelling suggestions for how this whole scenario can be avoided in the future.

    The main justification for suspending Zerif Lite seems to be that there was ample notice – 16 months – for changes to be made to bring the theme in line with the TRT guidelines. Fair enough.

    However, maybe things are happening behind the scenes, but the impression I get is that things are not happening quick enough to solve the issues that themeisle and all theme authors want to see to bring the .org Theme experience up to scratch with what WordPress theme users expect in 2016.

    Heck, Matt himself says it in the slack chat “it seems like every day that passes we lose more users (and devs) to places like themeforest”. Themeforest don’t do it particularly well either – but at least things like theme previews are down to the theme author.

    I’m guessing the onboarding process into WordPress for many new users starts with looking at themes on .org. Right now that experience is sub par to say the least. As Matt himself would no doubt concur – WordPress is competing against massive hosted solutions like Squarespace and Wix. Go take 15 mins and compare the onboarding process between WordPress and the theme experience on .org vs. what happens on Squarespace. If we want to keep WordPress as the dominant publishing platform we need to do much better at showcasing the fantastic work that thousands of theme authors do. Right now it seems like we’re doing exactly the opposite.

    I do understand the need for guidelines. But perhaps it’s time to take a hard look at the guidelines again and figure out what’s best for users?

    Report


    1. “If we want to keep WordPress as the dominant publishing platform we need to do much better at showcasing the fantastic work that thousands of theme authors do. Right now it seems like we’re doing exactly the opposite.”

      Yup spot on.

      Report


      1. WordPress 4.7 will contain enhancements and new core features that should help facilitate this.

        Report


  11. I’m really confused about faux custom post types. So is adding any sort of text and/or textarea field in the customizer considered a faux custom post type then? Because you you would lose that content when switching themes? What about something like a standard hero image intro with a headline, byline, and cta button? Would you not be allowed to have fields in the customizer that control the text for the headline, byline or cta? Confused…just seems all like content you would lose when switching themes…

    Report


    1. Believe me, there’s no binary answer for that. A lot of themes have such widgets, other than Zerif, and are still in the repository, while some are still asked to remove even for a single field.

      Report


    2. Furthermore, does that mean all non-core functionality *must* be available from a plugin in order for a theme to be permitted into the .org repo?

      My interpretation could be wrong. But if I’m right, this isn’t something I’d be entirely comfortable with.

      Personally as a developer I think its best to have functionality in plugins.

      However, I’d like consumers to have a choice. And I’d like the themes in the repo to compete at least a little bit with themes in themeforest when it comes to non-core features. And that’s only possible if features are built-in.

      Report


  12. “When is the right moment to break your user’s website?” Simple answer: never, ever, ever.

    It does not matter whether ThemeIsle was given 16 months or even 16 years to implement a change that would cripple its customer’s websites. It should not be done. TRT is making a demand that favors certain developers and runs counter to the interests of WordPress users. This really looks bad for WordPress. It certainly gives me pause when considering whether to continue with WordPress.

    To an outsider it looks like a cabal of jealous competitors stacked a committee to do war with a successful competitor. TRT’s justifications, as presented above, are not convincing and appear self serving.

    Where are the safeguards? Where is the process to review what appears to be a committee run amok? Who will represent the interests of WordPress’ users?

    Report


    1. The change would not cripple a single website. The TRT has made multiple attempts to resolve the issues, and multiple offers to help. The decision was not made by competitors. (Most of the key reviewers don’t even sell themes.) The actions and decisions of the TRT are completely in the open.

      Report


      1. The change would indeed affect our 300K users. They’ll lose all the content in the theme widgets and having to do a website all over again would certainly be a bad experience for them. Apart from that, if someone is away and has automatic updates their website will lose a lot of content without them being aware of it. And in the end, they won’t be like “Oh, this one follows all the guidelines” but more like “ThemeIsle crashed my website.”

        Report


      2. @Suyogya:

        The change would indeed affect our 300K users. They’ll lose all the content in the theme widgets and having to do a website all over again would certainly be a bad experience for them.

        You guys REALLY don’t know how to transition the content? That’s a bit alarming to me as a plugin developer.

        Report


      3. @Scott:-

        As I already said in a different comment, the problem isn’t that. The problem is getting some 300K+ users to install the plugin in order to get their content back and moreover, it means the theme will have to get rid of the functionality that we originally promised to ship with the theme itself.

        Report


      4. Can’t you just transfer the existing content of users website to new CPT programmatically, instead of asking them to install a new plugin? Something like showing an upgrade screen when the user updates the theme, take them through few steps and delete the old content. I know it is hard but at least you have many talented developers.

        (Just an opinion).

        Report


      5. @Joel James

        Can’t you just transfer the existing content of users website to new CPT programmatically, instead of asking them to install a new plugin?

        They could **if** they were allowed to register the CPT in the theme – but they are not. That’s plugin territory and would still get the theme suspended.

        So they can only set up the new CPT in a plugin and until the user installs and activates that plugin (which the theme is not allowed to do automatically), the content will disappear from the website.

        Of course, there’s always a way to do things. In this case, maybe they could create a single page with all the widget information in the content and set that as the home page. Maybe they could also add the content from each widget to different custom field for that page, then get the plugin (once installed) to migrate the custom fields into the CPT. But it’s not as straightforward as many people seem to think.

        Report


      6. @Chip:

        I fully agree. It’s completely not necessary for it to cripple a site. Exactly…there was plenty of time given.

        Report


  13. My prediction is ThemeIsle will likely experience a 50% decline in revenue or more because of this decision, 300,000 users will lose access to security updates, new features, and bug fixes, and people will probably lose their jobs over this because of mere faux custom post types. The Theme Review Team should be ashamed of themselves for not considering the impact their decisions make on users, and theme authors.

    I faced many similar issues with the Theme Review Team when I ran CyberChimps WordPress Themes.

    In my personal opinion, users and theme authors come before guidelines. I do not understand why the Theme Review Team even has the authority to ban a theme over a mere guideline for a theme that has existed longer than the guideline, and presents no security risk. Meanwhile not allowing for an alternative solutions that make sense. Why not grandfather this theme in and simply enforce the guideline moving forward for new themes?

    Forcing theme authors to fit some ideal of what the Theme Review Team wants, vs. what actual users need doesn’t help anyone. In fact, all it does is hurt both theme authors, and users, and for what?

    I knew it was simply a matter of time before the Theme Review Team did something like this, and it was even a factor in my decision making when I sold CyberChimps. I knew at any moment the Theme Review Team could make a decision I didn’t agree with and remove our themes. In fact, the Theme Review Team did make several decisions without our say, including preventing us from naming our themes, removing us from the featured section without warning, changing the featured section into a contribute-to-play system at one point, being able to communicate with our users, and preventing us from being able to upsell our pro themes.

    Much like ThemeIsle, we had 15-18 people working for us, and had to eventually let them all go, and sell the company. There were several decisions made by the Theme Review Team that negatively impacted our users, impacted our ability to issue updates, communicate with our users, and ultimately directly impacted our revenue. That’s 18 people who don’t get a pay check anymore, including myself, partly because of pointless decisions made by the Theme Review Team that they shouldn’t have had the authority to make in the first place.

    I spent years volunteering my time trying to improve the Theme Review guidelines, attended Community Summits (until I was literally asked not to attend them), and contributed thousands of dollars to the WordPress Foundation but none of it mattered. Ultimately I had no say, and had to remove myself from the equation by no longer participating in the WordPress.org theme community.

    Report


    1. Wow… this… this is pretty damning.

      Report


      1. And it is entirely specious.

        Report


      2. No Chip, it is not “specious”.

        This is the reality of messing with other people’s businesses.

        Report


      3. While I disagree with much of what you’ve said here, my comment was actually supposed to be in reply to the comment below.

        Report


      4. Chip,

        If theme developers are leaving the repo because of decisions made by the TRT, justify it to yourself however you want, it’s an unfavorable environment for developers, period.

        Developers release freemium themes on the repo because they can make money offering upgrades, otherwise they wouldn’t. Business is business, no one is developing these nice themes out of the kindness of their hearts.

        Most themes on the repo are not that nice, the nice ones which have been popping up are fremium themes. If users cannot find nice themes on the repo they WILL go elsewhere.

        So if you create an environment unfavorable to developers, who will produce nice themes, and thus bring more users to the repo, then you are only shooting yourself in the foot.

        If you cannot understand this simple point of view, then there’s not point discussing anymore. The repo will takes it place behind marketplaces like TF, MT and CM. And a competitor will most eventually appear.

        The decisions the TRT are taking are directly responsible for this, whether they are “right” or not.

        Report


    2. Living off the WP.org theme directory in any form, shape or fashion is a recipie for disaster. It started out as the domain of hobbyists and will return to that. Another win for ThemeForest.

      Report


      1. We made over a million dollars selling themes with WordPress.org being the primary means of distribution for our free themes, and we were doing great until the Theme Review Team and other factors derailed us after 5-years.

        There are dozens if not hundreds of plugin authors who make millions of dollars off plugins distributed on WordPress.org as well.

        Anyhow, I’ve moved on. However, when I saw this blog post I felt the need to say something.

        Report


      2. I run one of the oldest WordPress theme shops out there, being listed at WP.org when it first opened up to commercial themes. In those years, I’ve made quite a bit of money and grew a successful theme business.

        But every time something like this comes along or the theme listing page is redesigned resulting in plummeting sales for some theme shops, I’m reminded that WP.org has their own values and priorities. They may give passing thought to how it affects us and our livelihoods but its not the chief priority.

        Anyone who is considering starting a business that will depend largely out of WP.org needs to take a hard look at situations like this and really think about if incorporating WP.org as the primary means of traffic/revenue is a good idea.

        Report


      3. Hey Bill,

        I agree, it wasn’t our business plan or we are complaining that our revenue is lower, we started doing this with no expectations. In fact when we published Zerif in the theme repo we wanted to quit developing themes, just worked well and we focused on it, while trying to both grow the community and develop other products.

        Report


  14. As a user, I once used a theme company that didn’t play by the rules. When I finally left, it was painful to transition to a new framework that did play by the rules.

    Now I can change themes more easily.

    I’m really glad the TRT shut these guys down so that even more new users don’t get locked in to their bad practices.

    Congratulations TRT!

    Report


    1. More than agree on it with you Marcus. I’ve been playing with Zerif last days and it was actually a pain in the ass, especially because I was not sure which theme to pick etc. The styles, sometimes I couldn’t even change the style of some tables (I run a table plugin) because of some !importants somewhere in the code I guess. Additionally, the widget area which is more crazy – as they don’t use regular widgets here but some HTML text etc. Design and idea are quite nice if you take everything as it is.

      Report


  15. Tadlock and the TRT made the right decision. 16 months is extremely generous.

    “On the one hand, if you don’t make the changes, you’ll be banned from the repo,” Neagu said. “If you do make the changes, you stay in the repo, but you’re messing up the sites of your current users. Which is worse?

    Lame! As much as ThemeIsle is insisting that making the fix would mess up user’s sites, that’s some serious BS. If they don’t know how to do it, then they should hire a contract specialist who does know how. You don’t reduce the size of your company and lay off people for something like that. No, there is something else going on there.

    Transitioning data implementation for ever-evolving web functionality and standards is part of the job. You just have to make sure the theme has a check to know if it’s been updated, then after it detects an update, check if it’s on the new format or old format, then run a process/script to move/convert the data to the new method (ie correctly registering CPTs), then delete/clean up the old data. That’s oversimplified, but basically the process. I really get irked when other web devs say, “that can’t be done.”

    The theme devs could easily do it….they are either incompetent or just being stubborn. I’m guessing the latter. Probably they will act like a victim, and use this as an excuse to try and upgrade a lot of users to the Pro version.

    Report


    1. Just so you know, the current idea to get updates to everyone is to give pro version of the theme free to the existing users, if you think it’s an attempt to make money.

      Report


      1. @Hardeep:

        Do you know something that no one else does?

        None of the explanations on the ThemeIsle site or anywhere else mention giving away the Pro version. So, where are you getting that from?

        Everything references the same info above:

        ThemeIsle has no way to contact the 300,000 Zerif Lite users. The company has created a plugin called Zerif Lite Transition so users can safely continue to use the theme and get updates when available.

        Besides…what you’re saying makes no sense. Since they have no way to contact users, that also means they would have no way to verify that their site was previously using the theme. Anyone could grab it from a friend or find it online and install it, and then claim they were a long time user. “Free Zerif Pro for everyone in the world! Woohoo!”

        Somehow, I don’t see that working out too well.

        Even if it were somehow true, it doesn’t mean they couldn’t make money off it. They could just give away a year license for free, then after the site owners would have to pay to renew it and continue using it.

        Report


      2. @Hardeep:

        Ok, so that answers one question. You work for ThemeIsle. But it doesn’t explain the rest.

        The bottom line is that you guys had 16 months to fix a problem. You had plenty of time to come up with a solution to transition the data.

        It’s not even that hard. I could write code to do that in a couple days, and there are plenty of others out there who could as well.

        Standards are put in place to protect users. What’s the alternative…have no standards?

        I agree that sometimes there are extenuating circumstances that require some kind of grace period, but the TRT gave you guys plenty of time to fix the issues.

        Report


      3. @Scott:

        The problem isn’t writing the code. The problem is getting all the users to download and activate the plugin in order for their content to re-appear. As my colleague Cristian already said in a different comment:-

        Imagine you just spend couple of hours reading theme documentation, writing content and search for pictures. Then we came with an update and say “Hey, we just deleted all your work :) … to get it back please install this plugin”…. How would that makes you feel? Would you ever use another product from us?

        Report


      4. @Suyogya:

        You don’t need to have an additional plugin to do that. Well, you do NOW, because you waited until it got kicked out. If you had acted within the 16 months they gave you, you could have done it easily. In the theme itself, you could have added the code to transition the data. You guys are acting like it’s an impossible task. That’s ridiculous.

        Report


      5. Hi Scott,

        Sorry I was at an airport so couldn’t reply. If we migrate everything to a plugin, how is it gonna solve the issue?

        The issue is that the content will be lost once you change the theme, right?

        Even with a plugin added to our theme which has the content, once you change the theme, the plugin will be completely useless because other themes won’t work with our plugin. Every such theme has their own theme-specific plugin so it doesn’t solve the big issue which is the migration.

        And I’m also a part of TRT and I’ve talked about it before and there has been no solution. People are still losing the content even if the theme comes with a plugin.

        Report


      6. @Hardeep,

        You guys seem really hung up on having a side plugin. You don’t need a plugin….you can do everything you need from within the theme itself. (I’m not talking about now that your plugin is out of the directory…I’m talking about while it was still in.)

        As I mentioned in my first comment:

        You just have to make sure the theme has a check to know if it’s been updated, then after it detects an update, check if it’s on the new format or old format, then run a process/script to move/convert the data to the new method (ie correctly registering CPTs), then delete/clean up the old data. That’s oversimplified, but basically the process.

        Report


      7. You are not getting the point. We’re not talking about migrating the users in our theme but this guideline. Let’s not talk about our theme but what TRT is recommending. How is it solving the content migration issue? Maybe Zerif will be fixed but the big issue will remain the same.

        And I’m not here to blame TRT for anything. They are doing their job, and I won’t call you wrong for your opinion.

        I posted a long (quite long) below so please read it if you wanna know what I’m talking about. I’ve mentioned this issue in TRT Meetings in the past as well.

        Report


      8. You don’t need a plugin….you can do everything you need from within the theme itself.

        Not combined with (emphasis mine):

        move/convert the data to the new method (ie correctly registering CPTs)

        Theme Check won’t let you upload a theme that contains a register_post_type() function.

        That needs to be done through a plugin.

        Report


      9. @Leland,

        Right…but they were in a grace period for 16 months…no?

        Report


      10. @Scott,

        Your comments seemed to suggest a misunderstanding of the Plugin Territory guidelines. “Correctly” registering CPTs without involving a plugin just wasn’t an option on the table.

        Glad we got that cleared up. :)

        Report


      11. @Leland,

        You’re arguing over minutiae and missing the point.

        There was no misunderstanding of the guidelines…and nothing that needed to be cleared up.

        As far as the repo goes, I’m first and foremost a plugin developer, but I do a lot of work with themes outside the repo. We are no stranger to issues of scale…we currently have over a quarter million active users of our plugins. While it isn’t 300k, it’s not insignificant.

        Forgive me for not memorizing every last line of the guidlines (even though I am quite familiar). I wasn’t aware that my comment was going to be analyzed at a microscopic level.

        People have to comment on the go…when folks microanalyze a comment and miss the overall point of it, it makes it hard to have a conversation on here.

        I was making a quick off the cuff remark…in the context of the article.

        The suggestion itself wasn’t the point…The point was that it was one of a million possible solutions. If I make a suggestion that doesn’t work, then it doesn’t work…I don’t get offended. Just move on the the next one.

        The point is, that there is always a solution. Especially when you have 16 months…there is no excuse.

        Report


  16. They can just take all that code from the theme and put it in a plugin, right? What’s the problem?

    Report


    1. The problem is getting ~300k users to transition.

      Zerif is very popular. Stuff will break no matter how well-managed the transition is.

      Then themeisle will have to support maybe tens of thousands of users. Many of whom may not be technical. Many of whom may not know the first thing about WordPress. Many of whom will be angy. Many of whom for who their website is a vital part of their business.

      Report


    2. The problem is you can’t “auto install” the plugin with the theme update. If we were allowed to do this, it would’ve been long done.

      If we break it into steps:
      1) The user updates the theme
      2) Content from their homepage disappears
      3) The users receives a notification to install a plugin
      4) Install the plugin, activate it
      5) Contents is back up

      This is what we’d call a terrible user experience. A good solution would be:
      1) The user updates the theme
      2) The plugin is automatically installed and activated
      3) Content never disappeared

      Unless we can offer a seamless and failproof solution to our users, then we’d rather not make these changes at all.

      Report


      1. Why an extra plugin? Can’t you just do that in the theme itself? LThen later you can remove the old content as well as the code.

        Report


      2. Hey Joel,

        We are not allowed to have CPT or custom widgets/content in the theme, this is the point :)

        Report


      3. /headdesk. The guideline they violated is that they mixed functionality and presentation. Telling them to do that more to solve the issue is unlikely to please the TRT.

        Report


      4. Why not move everything into a plugin, ask users to install the plugin. Then make the theme code conditional – if required plugins are active, don’t run the “bad theme code”. For 12 months slap a big warning message to a link explaining the issue with the transition. After 12 months of the hybrid beast – remove the “bad theme code” entirely. The users who haven’t within that timeframe and haven’t installed the required plugins will have functionality missing, which they can get back with the 5 steps you listed.

        Report


      5. @Norris But will that solve the problem? The reason this guideline is there is to make sure that the users don’t lose the data once they change the theme.

        If we make a plugin for Zerif widgets and make every thing alright, people will still lose the data once they switch themes because other themes won’t be using our plugin for their content.

        So that will make the theme compatible with the guidelines, but won’t solve the issue.

        Report


      6. @Hardeep Asrani Just port the info from widgets into page/child pages which could also have meta info (you can use this for images, urls).

        All the information you need is in widget_* (content) and sidebars_widgets (position)

        After that recreate the widgets with a select input for pages and add them to the db. When you inject those widgets in the database, based on their previous position, add a value attribute for that select input with the page needed (content) for that widget.

        Report


      7. But Marius… surely if there that is a perfectly ‘good solution’, why was it not done already during those previous 16 months before the ban?

        Report


      8. Why not prevent the theme from updating until the plugin installation step is completed and provide a UI for that. Problem solved.

        Report


  17. OMG storing content in widgets is so unfriendly to users that the question should probably be why did it take more then a year to kick them.
    I thought that this kind of practice died when CPT were introduced.

    Anyway, not sure what all the whimpering is about. Sounds like they are doing enough money to be able to afford to restructure their code. All the employees here that claim it is impossible to write a migration code just essentially justify the decision as if people that are familiar with the code can not migrate the sites to a new theme (zerif++) then how will simple site owners do that. It is just a lock-in and since it took 16 months without anything done about it, it seems like the company was happy with the lock-in and didn”t want to give up on it.

    Report


      1. yes, that is the real question. but nothing wordpress.org does is 100% consistent :(

        Report


      2. @Mike There are many themes which were approved in last year which generates a lot of content. There is no consistency in this. Some admins are fine with some, while others ask to remove everything.

        Report


    1. Hey Mark,

      Nobody is complaining that the theme is suspended, rules are rules, more on this here : http://www.codeinwp.com/blog/transparency-report-19/ .

      Regarding the content in widgets thing, is not as simple as you might think, in short creating 4 CPTs just to fill some info on a single page I am not sure is a good practice.

      First of all that content was designed to be used just on the front-page, is a one-page theme and users want to be that way, creating 4 custom post types for a content that is still minimal, I don’t think it brings a lot of value, just way more complexity.
      The accepted and most widely used solution by themes with the same focus is to create a ‘companion’/’extensions’ plugin and throw all of those plugin-teritorry things there, how is this better ? Isn’t the content still locked in the db ? Or now is fine because is not a theme problem but a plugin problem ? While this approach follow the repo rules, I consider it to be worse, you are asking users to install a plugin to enjoy the theme, while continue to ‘lock’ that content.
      The other recommended solution is to use generic plugins, like recommending a team plugin, testimonials plugin, client plugin, contact form plugin and so on, plugins which are indeed more flexible and users can enjoy using them with other themes as well, but the thing here is that you trade-off the initial setup UX ( requiring and configuring 5 plugins to setup a simple one page theme isn’t the easiest thing for a user ) because you assume that users will need that in the future or you assume that there are other themes out there who can incorporate those 5 plugins as the current one is doing.
      In an ideal world I agree that 2nd solution is a good one, but isn’t the case in the current eco-system because isn’t mature enough, plugins will break theme functionality and the theme will break the plugin one ( even big plugins like WooCoomerce aren’t doing a great job in maintaining backward-compatibility ), while without being allowed to use an installer in the theme the whole installation/activation and configuration of those 5 plugins will be a nightmare.
      We are talking with a lot of users on a daily basis, we have themes build in the all 3 scenarios and by far people would prefer to go with the option 1, like we are doing in Zerif for one-page themes. If we are talking about a portfolio theme or about a review theme where 1 standalone plugin is required ( not companion-like ), of course is clear that the best thing you can do is to recommend that plugin so users can easily switch themes while maintaining their review ratings, tables and so on.

      Report


      1. That’s the point.
        There should have a standard export format and a mapping tool with UI, otherwise it would be difficult to change themes and plugins.
        I always lost theme options or widgets or menus after switching to child theme or pro version.

        Report


      2. The accepted and most widely used solution by themes with the same focus is to create a ‘companion’/’extensions’ plugin and throw all of those plugin-teritorry things there, how is this better ? Isn’t the content still locked in the db ?

        Exactly. In the end, users will still lose some kind of content or customisation when they change theme.

        A solution for WordPress would be to allow modular building blocks. Let theme designers use them or not. There is a balance in consistency when you allow some themes to use more functions than others. It’s actually how tumblr themes work: some have a lot of options, other don’t. Content and function are still kept separated, with some exception. Maybe WordPress could borrow from that and be more flexible. Maybe allowing CPT in themes would not be so bad. As long as you have good documentation, standards and guidelines in place it can work. Users are not idiots. You can inform users about what content they’ll be able to keep when switching themes. From a user’s perspective, it makes more sense to pick a theme that has specific features than to chose between a few thousand themes and then pick maybe a dozen plugins to get specific features to work…

        Report


  18. From reading the trac ticket, it looks like a bit of a misunderstanding to me.

    ThemeIsle seem to have been thinking of migrating the faux CPT data to a real CPT defined in a plugin (which is the obvious solution to use for that function going forward). The sticking point was they couldn’t auto-activate that plugin (which is a good rule). That means that while a script could migrate the content, that content would disappear from users’ websites until they installed and activated the plugin. Not acceptable.

    ThemeIsle pointed this out in trac:

    Now we still have 1 really big guideline issue : faux CPT, for which I can’t see a seamless migration if we aren’t allowed to auto-activate a ‘companion’ plugin while informing the user ( part of the migration script ). I am right ?

    Quite a few people above have mentioned that offers of help were made by the TRT, but when presented with this final sticking point, no further advice was provided – the next communication was that the theme had been suspended.

    However, what ThemeIsle seem to have missed is that in the previous communication, Justin had said:

    Like a temporary script for migrating existing (anyone on version 1.8.4.7 or below) users’ front page to use a page instead of posts? Sure. No problem with that.

    So while ThemeIsle were thinking of migrating the data into a CPT (the permanent solution for the home page feature, which would break things for existing users), Justin was actually suggesting putting everything into a Page (a temporary solution for existing users only, which wouldn’t have broken things).

    The problem could have been avoided if either ThemeIsle had picked that up and acted on it or if the TRT had addressed the final sticking point with “migrate it into a page instead of CPTs” instead of suspending it.

    At least that’s how it appears to me… Anyway, I hope they get this sorted so that the theme can be reactivated in the .org repo without users being affected.

    Report


    1. I still have one thing to say – how is it gonna solve the problem if the user changes the theme? If we add everything to a plugin and make sure 100% of the users are migrated properly, the plugin will also be useful when you will switch the theme. No other theme will use our plugins because everyone wants to have full control of their product. There are many themes which come with a separate plugin for their theme’s widgets, and no plugin is compatible with any other theme, so you always have to abandon the old plugin and install new theme’s new plugin.

      Even if we sort this particular issue out, how is it gonna solve the main problem? :)

      Report


      1. Hey Hardeep,

        I answered this on your other comment, but essentially at least the content is available in the back end if it’s in a plugin defined CPT, so the user can still copy it elsewhere. If it’s in the theme defined widgets, they won’t be able to access the content via the back end.

        But I agree there is no perfect solution for this. :)

        Report


      2. Hi guys,
        Your two comments here summed up all what I was thinking about this situation, and here is my further input which I hope will help clear things up and figure them out:

        1- At first, when reading the article, I was a bit angry and thinking to myself “how stupid these theme reviewers are for wanting to break end users sites” but a few seconds later I came to realize that if you guys have a hard time to migrate the content from when version to the next, then how will those end users be able to migrate their content from this theme to an other.

        2- Still, as you pointed out, moving the problem from theme to plugins only seems to move it further or to displace it, those plugins’ output wouldn’t be styled properly on third parties’ themes and more likely, won’t even show up in them. So this seems like a dead end, BUT… in practice, it is much easier to migrate content from one plugin to an other than from one theme to an other, simply because you can have those two plugins activated at the same time to manually migrate the content while you can’t have those two themes activated on the same site at the same time for the same page. It’s of course still possible to migrate the content in the case of themes but that involves some advanced browser multi-tab working logic.

        3- Now that we have, hopefully established that plugins are good for any non-core functionality, here is a workflow/hack that I hope will help you fix the situation:
        — You need to implement that functionality in the plugin as requested by the TRT.
        — Then, in both the theme and plugin you need to use some sort of global boolean (to be set by one of them only) to decide which part is being run by wrapping the functionality code in “if” blocks.
        — Or from the theme, you could simply check if the corresponding plugin has been activated or not and wrap the code in an “if” block like above. (Here is something that my help you further: is_plugin_active and don’t forget to require plugin.php when using it in your templates)

        Let me know if you have any questions, I will check this thread tomorrow just in case.

        Cordially, M.

        Report


      3. You can have two plugins activated at once with a plugin. Plus, if a user has to copy paste then he can always use notepad. And Zerif thing is done.
        Let’s put it behind and see what TRT is doing to solve the main issue.

        Report


    2. Well, they did get this advice about 16 months ago: https://themes.trac.wordpress.org/ticket/24907#comment:19. If they would have followed that path they would have had 16 months to encourage their users to install that plugin. Heck, maybe they would have gotten more time since they’re showing progress..
      Instead they choose not to and made the claim that forcing their users to use a plugin would instantly break 300K websites. Mind you: that’s a current user count. 16 months ago that number would have been way and way less.

      Report


    3. Hey Stephen,

      Honestly I just didn’t imagined that this is an acceptable solution, since content will be also locked.

      Thanks for insights!

      Report


      1. Hey Ionut,

        I was only thinking of the page as part of the transition, with users ultimately migrating to the new CPT. As I said to Hardeep, there’s no perfect solution to this problem, but having it in the plugin defined CPT at least means the user can copy and paste the content somewhere else.

        Anyway, hope you get this sorted out somehow! :)

        Report


  19. No apologies for my first comment.
    If you retroactively apply changes in the rules that would affect 300k sites, you either need to supply a suitable migration path or your just playing in a Shakespearean farce and not living in reality.
    Claiming you’ve waited 16 months to kill the theme is bogus as it was the only path provided so waiting a little bit to offer up this twisted argument just makes for good press.

    Report


    1. You should apologies because everything you say is not true. They were not asked to do the migration in just one step.

      It is mentioned in those tickets that they should/are allowed to migrate users step by step, in time. They could have triggered a dismissable notice each time they did an update, mentioning that a feature has been ported to a plugin and a link to a step by step instructions page (on their site). You can ask any admin, they would agree with this.

      Instead they let the older ticket “die” and nothing changed. Why? Because moving all those options would make their theme as any other theme, resulting in them having to go 1vs1 with the rest of authors who follow the rules.

      Zerif Lite isn’t even an “awesome” theme, as they call it. It’s just a plain bootstrap theme with outdated code/design, locking in any user that use it.

      Report


    2. @mike

      …and in an alternate universe, where Zerif Lite was allowed to stay on the repo, there’s an alternate you calling out TRT for playing favorites.

      Just kidding man, I’m sure if you were calling the shots everything would be great.

      :)

      Report


    3. The guidelines did not change. The theme was improperly approved originally. Theme reviewers are human, and make mistakes. That said, presentation-vs-functionality is a long-standing guideline, that predates most/all of the active themes in the directory.

      Report


      1. I am reading so many different versions of what happened, at this point it is impossible to draw any conclusions one way or another.
        But if my memory is correct, Mr Tadlock was previously involved in another arbitrary decision.

        Report


      2. you sure do have a personal vendetta with Justin

        Report


  20. Just follow the rules, ThemeIsle.

    Best solution:
    1. Retire Zerif Lite or keep it available only on you site.
    2. Create a compliant version of Zerif Lite – call it Zerif Lite 2.0
    3. Let people know about the differences between the two so they can adjust their websites accordingly.

    Simple.

    Report


    1. James Katt, how exactly do you let them know of this? I think this is the biggest issue of wall, there is no way of communicating with all of them.

      Report


  21. I want to mention that I’m a part of ThemeIsle.com, as well as TRT. And I wanted to discuss how this will solve any issues, step by step.

    The issue that is with Zerif Lite is that it has widgets which generate content. And what happens is, if a user changes the theme from Zerif Lite to some other theme, let’s say XYZ, they will lose all the content which they added to Zerif using the in-built widgets.

    So what’s the solution? They asked us to take all the widgets out of the theme and put them in a separate plugin. We don’t have to change anything in the widgets and just put it in the theme. Easy, right?

    Let’s just say that we did all of this and somehow the transition went so smooth that 100% of the migrated users had no issues. Now what?

    They have Zerif Lite + Zerif plugin installed to their WordPress. And few months later, a user wants to use use XYZ. So when he deactivates the Zerif and actives XYZ, he will still have Zerif plugin installed which will have all the content saved.

    But is it gonna solve anything? Because even tho they will still have the content, XYZ has its own plugin for such widgets which it requires. How is it gonna solve the problem? The user will still have to install the XYZ’ companion plugin and migrate all the data from our plugin to their plugin. The issue still remains ever after everything.

    And believe me, every theme author uses their own plugins to do the job, instead of using our plugins because everyone wants full control over their product, which is understandable.

    How is putting the content in a plugin is gonna solve this problem when every theme uses a different plugin?

    It is just adding extra steps to the process. And I’ve put this issue months ago in a TRT meeting and key reviewers say that they will look into this issue and there has been no word on it afterwards.

    And no disrespect to key reviewers, they have been doing their job. I do not agree how they are dealing with this situation but that doesn’t mean I don’t admire them for their work.

    And I will really appreciate if we could ask end-users what they want. They want themes which have these options built in, or they want to do the same + an extra plugin every time they change the theme.

    If we make the Zerif improvements and somehow migrate all the users, it will make Zerif compatible with the guidelines, but how is it gonna solve the bigger issue? End-user will still have to redo all the changes, and will have to install a new plugin to do the old task.

    Report


    1. End users do not want bad code. Bad code will come and bite your a$$ sooner or later. End users are trusting **YOU** and all other theme and plugin developers to use best practices, to be forward thinking and backward compatible. There is no need to ask end users anything, they just want it all.

      Now what you are basically saying is “We were pretending to supply a top notch product, while we weren’t, lets ask the users if they want to use crap code or follow a crap upgrade path”. I don’t see how anything good will happen to you if you ask the users directly which option they prefer, I predict hate mail and lots of support time wasted on it and this will obviously impact your pro offering.
      You had such a long time to decide on a proactive plan and to communicate it to users and I don’t see anything you are going to gain by a delay tactics like a users poll.

      Report


      1. The code isn’t bad. It’s just not allowed in wporg themes, which one went under review and was accepted.

        Report


    2. Actually, I did not think on this matter with this angle previously. But I must say Hardeep you have a very strong point here. Talking particularly about this Zerif theme case, even though if guys at ThemeIsle make a companion plugin and put all the custom content in that plugin. User after switching to other themes are most certainly not going to use that companion plugin as it won’t be compatible with other themes.

      Result: From users point of view, all users that this theme has, if they decide to switch to other theme will lose the custom content.

      This can only make sense if current custom content can be replaced with WordPress default content like pages/posts in version updates. That way even if user switch to other theme, there would be no loss of content.

      As mentioned earlier, I am talking about this Zerif case only. If a theme author is releasing a new theme along with new companion plugin. Then it will be clear to the users that this particular plugin will be fully compatible with this new theme only and will not be or may not be fully compatible with other themes. So, user can decide at initial stage whether to setup the site with this new theme or not.

      Just my view.

      Report


    3. Hi Hardeep,

      Having the content in a CPT defined in a plugin is definitely not perfect, but it’s better than the current situation.

      Currently if the user switches theme:
      a) the content disappears from the home page
      b) the user can no longer access the content (it’s in the DB somewhere, but no way to get it through the back end)

      With content in a CPT that’s defined in a plugin:
      a) the content disappears from the home page
      b) the user can still access the content in the back end and copy and paste it somewhere else

      It would be great if there was a common CPT / plugin / standard for themes to share, so that it’d be seamless to change themes, but I agree that’s not likely any time soon. :(

      Report


    4. Let’s get something clear here. Themeisle is the one that put their users in jeopardy here – NOT .org. Start taking responsibility for your own stupid mistakes.

      You had 16 months to deal with the issue and you did NOTHING. Did you even try to let your userbase know there was an impending issue? Of course not – that might affect revenue.

      This BS about plugins and “what happens when they move to another theme?” is silly.

      Every Elegant Themes (as an example) customer (Divi) has the same issue. I can’t change to a new theme due to the way it handles content (actually I could since they now have the Divi Builder which works with any theme). I knew that going in and I’m cool with it.

      Stop crying – start fixing.

      Your users are going to end up hating you anyways since you have now officially risked the SECURITY of their sites by doing nothing. A massive security issue comes to light with your theme now and there’s NOTHING you can do about it (and it WILL happen – you can take that to the bank). 300K users exposed. The script kiddies will have a blast screwing with that many sites.

      Good job….

      Report


      1. Hi Ron,

        Thanks for your input. But how does it makes any sense? How is making this change fixing the issue? Could you let me know that?

        And look what exactly happened 16 months ago. We asked admins something and they didn’t reply.

        And again, please don’t make this about TRT vs Themeisle but let’s discuss how putting widgets to a plugin will solve the issue. If the issue isn’t being solved them what good is it doing?

        “Hey, don’t put this data in a theme which will be useless after theme change. Put it in a plugin which will be useless after the plugin change.”

        So please only reply are open to an open minded talk without starting TRT vs Themeisle. A lot of themeisle members are a part of TRT so we can’t be against ourselves. :)

        Report


  22. Seriously???

    The rules are there for a reason.

    Oh, HO-HUM

    we feel it isn’t fair and believe that we did our fair share of contribution towards the community

    Since when are the rules different because you have contributed? In fact, sine you do contribute, you should know the rules and should be an example of what following the rules is all about.

    I put it to those watching this thread from the theme and plugin review teams. Apply the rules.

    Apply them across the board and stop giving the violators the impression that because they contribute they don’t have to follow the rules. The violators know what they are doing and they seem to believe you will drag your feet because their customers will be damaged somehow. Fact of the matter is, if someone is violating the rules, and you tell them to fix it and they don’t, they (the violators) are responsible for what happens to their users.

    Don’t sit back and let these things happen. Period.

    I can’t believe it, crying because the theme review team finally did what they should have done long ago.

    Report


    1. I am sorry you got this wrong, if you are reading my answer I explicitly say that rules are rules and everybody should accept them, so I am fine with having the theme suspended if it doesn’t respect the rules – http://www.codeinwp.com/blog/transparency-report-19/ .

      What I wanted to say with the quoted phrase is that internally we FEEL that is not fair, it was not targeted at a specific thing like having the theme suspended, but rather than we feel disappointed by community as a whole, I rather hard to explain since I said is just a feeling :)

      Report


      1. Yes, you have made it very clear in all of your comments (and your blog) how you believe things were unfair. And I guess your entire team feels that way. It’s not unfair at all. Regardless whether they said something 15/16 months ago and then didn’t enforce until now or if they kept reminding you, the result is the same and rightfully so.

        And yes, your responses have been in the category of crying, from my take. That’s my opinion. Neither your comment nor your rant on your blog changed it. I really wasn’t impressed with your take on the issue. Maybe you could spend a little more time getting over it and going on with your (now) $35,000 per month business income.

        I could go into the issue related to themes having functionality and the conflict resolution issues that arise from that but I believe you are aware of it. So I won’t. Just accept things or change the theme so that it can go back onto WordPress.org. It’s really your choice.

        BTW, how many times do you believe you need to place your link in the comments?

        Report


  23. A couple things here:

    1) Any time your revenue stream depends on a third-party marketplace, you are placing the success or failure of your business in the hands of someone that is not concerned with whether you succeed or fail.

    2) In this case, it would appear there was ample time to either a) do something to at least begin unraveling the issues, or b) do something to diversify your revenue stream.

    3) This isn’t a win for the repo, either. Whether or not this is a sound decision by the TRT, it does in the end hurt users.

    4) In the spirit of Matt’s words, quoted in the article, I wonder if there isn’t a better way? Perhaps a transition to a system in which the TRT’s role has two parts… The first being a review to prevent malicious code from hitting the repo, the second being a very visible set of badges that are awarded for compliance with the ‘requirements’.

    In such a system, the Zerif Lite theme, rather than being banned, would simply be forced to wear a badge of shame indicating its’ poor portability. That would protect future users, without the risk of harming current ones.

    Report


    1. Hey there,

      I agree with you, we aren’t trying at all to complain on why we got suspended, you can read my entire perspective here : http://www.codeinwp.com/blog/transparency-report-19/ .

      I am just trying to express my point of view regarding all this and work together to avoid situations like this in the future.

      Report


      1. Misplaced comment, apologies.

        Report


  24. Difficult situation and no easy or perfect solution. The easiest solution (but it’s not great) would be to retire the theme (send out one last update with instructions on how to transition to the 2.0 version and the changes that are being made and why) then develop version 2.0 of the theme that does adhere to the TRT guidelines. But as noted, while easy to do, it’s not great and some users will definitely get burned in the process.

    Report


  25. As a user,, TRT should have shut this theme down a long time ago. 15 or 16 months means thousands more of unknowing customers / users implementing a theme that locks you in.

    As a user the theme developer should also have been upfront with their customers / users and told them about the problem 15 or 16 months ago!

    By the way, bet they STILL haven’t fessed up properly with their customer base.

    This is deceitful not telling your customers that by implementing your theme you are potentially getting locked in.

    The excuse that 300,000 users will now get hurt is a sham. Be honest and tell them your customer base what is really happening especially now. To allow this issue to fester for so long will now bear you much more discomfort as it should.

    Report


    1. A newsletter has been sent to all customer email addresses we have a hold informing them about what has happened.

      “Locked in” I have no doubt that locking anyone into a theme is something Ionut never had/has intentions of doing.

      As Hardeep said previously, what is the difference between using a separate plugin to store the data if after the user changes their theme it would still be lost? Saved in a plugin which they have no need for.

      Just to be clear we are are still having internal discussions on this. Thanks to everyone who have given their possible solutions and everyone who see the issues with the possible solutions.

      Report


  26. This is the right decision :)

    Report


    1. Marius Ghitulescu:

      I only have one question, hoping the TRT can anwer this:
      Who will benefit from this decision?

      I am no one of the TRT, but that’s my answer:

      No one benefits!

      And the reason for that is, that you obviously did nothing to solve the issue for 16 months.

      You and some of your colleagues act like victims. But who are the real victims? Yes, the users. And why? Read the paragraph above.

      Geez, .org is not the only place in our lives where we have to follow standards and rules. And like everywhere else there are people who are more strictly than others. That’s life! 16 months are a long time to plan a solution, discuss the solution in your team, realize the solution, review it and finally implement it. I really don’t know what was the deal, sorry.

      Report


  27. 16 months and nothing was done!
    Not an easy task but it could have been resolved in stages – TRT did allow for that.

    So now Zerif Lite has been suspended and instead of working on a resolution all thats happening is arguments going back and forth – all the while throwing in the end user whom non of this actually helps!

    Develop and release Zerif Lite 2.0 with a companion plugin as suggested.

    The companion plugin should be designed is such away that it checks as which version of Zerif is active – so if its the old version then the old data is retrieved and if its the new version then the newly introduced CPT are retrieved.

    At the moment for the Zerif team the sticking point seems to be the question of data portability. This will only remain an issue if the companion plugin is designed to function in the same manner as the current theme does.

    Solution is, old theme active use old data – new theme active use new CPT data.

    Within the old version of the theme on a theme specific info page inform users that with the current theme the data in xyz sections are not portable while they would be in the new version.

    The question of data not being displayed on another developer’s theme is irrelevant as that is a choice the use makes when they change themes. However the data is still there, safe! (its like having a car with a tow bar and a caravan – you switch to a new car with no tow bar but you still have the caravan :) )

    Make the new version as awesome as the first and soon or later most of the 300K will transition over – those who choose to remain on the old version will still have a perfectly functional theme and continue to receive updates addressing any security issues.

    Some may argue its not the best solution and I would argue that its a step in the right direction for the end users!

    Report


  28. Kudos to William Bergmann for his brilliant suggestion “a very visible set of badges that are awarded for compliance with the ‘requirements’”. Or perhaps the opposite may be easier to implement and more readily visible: warning stickers for noncompliance. Same as we do with food: some people won’t eat GMOs while others don’t care, so we put labels on products and let customers decide for themselves.

    One of the key factors that makes WordPress a success is its brilliant social engineering. Unfortunately TRT did not get the message. An autocratic TRT can wreak serious damage on the social contract that makes WP such a successful community. WP does not need a “star chamber” to punish innovative developers. I suggest that all TRT be allowed is to note departures from guidelines and apply a warning sticker. Then let WP users decide for themselves.

    Report


    1. Try and review a theme or two before saying TRT kills innovation in developers. The only thing they are doing, and doing well, is making sure your site is secure, plugins don’t break and translations work.

      If you would’ve reviewed a theme, you would know what crappy code is sent for review each day and how spammers try to get by undetected.

      You should thank TRT for enforcing their guidelines. Also, if you haven’t notice, themeforest is following their steps. You know why? Because they are tired of receiving support queries for broken sites by plugins or security, resulting in refunds.

      Functionality should go in plugins, let the theme worry only about the design aspect.

      Themeisle had 16 months to figure this out, they didn’t. Great decision by TRT, I hope they follow up and do the same for the rest of themes.

      One more thing, Zerif is not innovative from either a design or ux point of view. It’s just a theme that was in the right place at the right time. If you follow up on its history, you would know what I am talking about. It’s all in their “Transparency Reports”, start with #1.

      Badges :)

      Report


    2. You are of course welcome to join the team and help us improve the process and the requirements. -You will not be able to make any changes from here.

      A similar suggestion has been put forward, -multiple times even. And it has been down voted multiple times by those who do participate.

      Report


  29. The TRT’s job is to review themes in relation to the guidelines. Suggestions that they do otherwise doesn’t, in my opinion, make much sense.

    The “contract” with the users that is being enforced is, if you change themes you don’t loose your content. That is very reasonable and laudible.

    By continuing to allow Zerif-Lite in the repo, the problem grows with each install. My own opnion is that it would be acceptable to allow ThemeIsle to put a neurtal notice in the theme dashboard for 6 months, in the version in the repo, that directed users to download further updates at the ThemeIsle website. I realize that we don’t want that kind of advertisement, but in cases where something was allowed, and no longer is, it seems reasonable.

    I’ve been following these types of conflicts between TRT and commercial theme developers for several years now. My conclusion is that we need to make some changes to core to support new / more options for theme innovation, changes that will be acceptable in the repository.

    In the meantime, I’m thankful for the hard work of the TRT and appreciate the positive way that ThemeIsle has expressed themeselves (even if I disagree).

    Report


  30. If a theme has persistent and serious bugs or security-related flaws that may harm a website then extreme actions are justifiable. On the other hand if a theme has features that threaten the business interests of other theme developers, that is an entirely different matter. As previously suggested, it would be appropriate for TRT display a warning in the theme directory. In this case I see TRT as taking an action that is entirely out of proportion with the problem. As William Bergmann suggested there is an easy and more appropriate way to handle the problem. TRT is causing a problem where there does not need to be one. TRT’s action in this case also damages the credibility of the TRT itself. It gives the appearance of one group of businesses using the TRT to wage war on a competitor. That’s a bad place for the WordPress community to find itself.

    Report


  31. The TRT seems to have screwed up but not necessarily by suspending the theme… but by waiting. Had they taken this action ASAP after finding the issue the number of users affected would be much smaller. By dithering around for 16 months they share responsibility for the impact. There’s no shame in having mistakenly approved the theme – humans aren’t perfect, stuff happens. But if people are going to make the argument that letting this go on for more that 16 months simply increases the magnitude of the problem well, so did letting it go on for more than a month, etc.

    Caveat: Not read the trac ticket, so if this was only discovered recently, eh. But if it was discovered early on, the theme should have been suspended right away. Hopefully, the TRT will, if a suspendible violation is found, be more prompt in removing a theme while at the same time working with the dev to address the issue.

    Report


  32. My personal take on this is that it is about money. The theme developers have made a lot of money by introducing a theme that locks users in. Now they need to spend the money to help users and actually create a theme that doesn’t lock a user in and they cry about it. They say this is about users. No it’s not. If it was about users then the theme would have been portable from the start. They wanted to lock users in an be make money from them. Now when they have to spend the money they have made to assist users they moan. Do the right thing.

    Report


  33. Hey! I have a solution for ThemeIsle guys!
    Stop working on Zerif, create a new company, a new set of themes and so a new business.
    What if the company detonate? The same. Users with no further upgrades. It’s not the first time it happen in history.
    Let’s just call it a failure. Cause it was since the beginning. A succesfull failure that, in the meanwhile, allowed you to grab a lotta cash.
    Luck come and go. It came at start, now is gone.
    There’s NO SOLUTION to the issue. A lotta clever minds here proposed solutions, and no one can apply. The TRT will NOT change his mind, the community seems to be aligned in favor of TRT decision and you can’t do any compromise, not even if willing for.
    This open only one exit: goodbye to Zerif, and prepare to have people searching you for security issues, that you can solve by a private upgrade (to not being pursued). It’s sad. But sometime things are sad.

    Report


    1. @Gas

      Lol! Awesome. That made me crack up. But it’s pretty accurate. Well said. :)

      Report


  34. Guidelines should be treated as guidelines and nothing more… The impact to users should always be more important than adhering to guidelines in my opinion…

    Report


  35. It’s simple. You had “only” 16 months to fix issue and you did nothing. Did you even try to let your 300k users know what’s happening with their websites? -No.

    Difficult situation. Good Luck!

    Report


  36. This is a good reason to never use wordpress. By using it, you’re putting a third party in control of your content. Sorry, wordpress… I’ll just keep building my own sites.

    Report


    1. Sorry Rick, but you’re confusing things. There is no 3rd party who controls your content. When using WordPress, the content is saved within your database on your own server…

      This simply is about the fact that the theme had included widgets to display content like team members (or else) and when you enter the content into the widget and then switch to another theme that doesn’t have this widget, you obviously can’t use the widget anymore.

      But still the content is saved in your database and you either could code a custom widget for displaying the content or edit your database to make the content available. Of course that isn’t optimal and that’s what this discussion is about, but there is no 3rd party who controls your content. No need for conspiracy theories. :-)

      Report


    2. I think you are thinking of Wix or Squarespace, which would be a 3rd party service which you do not self host yourself. Your paying for using someone elses platform.

      Report


  37. Awhile back in this thread, someone asked for end user feedback. I’m an advanced end user – I’ve been using WordPress for 10 years, and have multiple sites of my own. I also provide support and customization services to more technically-challenged end users who thought they were getting into something easy when they decided to build/manage their own site in WordPress.

    I instantly spotted Zerif Lite as a freemium theme the first time I looked at it. It’s not that hard to tell. The Zerif Lite documentation on ThemeIsle’s site redirects the reader to a login page for premium users in the first sentence. The company has a long-established practice of holding support hostage for premium users only, though (speaking of gaming things) they like to post a last word in WordPress.org support threads that were actually answered by volunteers so it looks like they are providing a lot more free support than they actually are.

    The fact that ThemeIsle claims it is defending a non-portable theme in the best interests of end users is the height of cynicism. Locking users into any theme is clearly not to their advantage, which is why portability is a core value of WordPress. If ThemeIsle’s disregard of that value wasn’t enough to expose their sense of entitlement to manipulate the system to their advantage, their threats to withdraw support from WordPress sponsorships surely is. They can dress that up however they like, but the underlying assumption that they expected those sponsorships to buy them special consideration is too obvious to hide.

    I have nothing against theme and plugin authors getting paid for their work. Creating themes and plugins has become increasing complex, and maintaining them has become increasingly demanding. However, there are a lot of different ways to monetize around WordPress products. Some models align well with the whole concept of WordPress (GeneratePress, for example has done a stellar job of this), while others are a mockery of it.

    ThemeIsle falls into the latter category. Their history makes it pretty obvious that their concern about an end-user transition has a lot more to do with the burden of providing support for it than it does with the end-user’s experience. Arguing that they can’t follow the rules they have knowingly violated for years because it would hurt thousands of customers is an application of the “too-big-to-fail” excuse that American users, at least, are unlikely to regard with any sympathy.

    That sense of entitlement crops up again when ThemeIsle insists that moving the content to a plugin is no solution, because any plugin they write must only work with their theme. That’s not a given, it’s a choice. If they are so devoid of the WordPress spirit that the thought of writing a plugin to work with other themes offends them, they could just as easily recommend an existing free plugin that works with all themes, as many other themes do.

    Widely-used themes have been required to migrate content from theme-specific widgets before. Is it a hardship for end-users? Yes. Is that a reason to allow theme authors to wiggle out of supporting a fix for a problem they created in the first place? No.

    This end user is very happy to see the Theme Review Team sticking up for founding WordPress principles. On behalf of myself and my clients, I urge them to keep it up. In the increasingly complex and commercialized WP universe, it is the only thing that continues to set WordPress apart.

    Report


    1. @Terry Lee

      That is an outstanding response. Agreed 110%!

      Report


  38. As a new wordpress user and just finished customizing my Zerif lite site… This is bad news!!!

    So will my site eventually end up NOT WORKING???

    Report


      1. I have been using WP for 3 years now and have several sites with Zerif Lite.
        Im done with it!
        Very unprofessional support, leaving existing issues for 3 months without any response and now the last upgrade have just managed to completely turn the theme upside down, causing all kind of troubles for users like me.
        I reached for support to TI and what they did, was just screwing things up completely.
        It was a good theme while it lasted, but for the future, I will stay away from any product, coming from ThemeIsle

        Report

Comments are closed.