I am glad its not just me thinking the situation is poor
I have a few sites running and 2 new ones to do for my own business
I am face with paid bundles of old themes of no use, if I move old sites to 5.7 it has to be manual.
And the bought eCommerce package is also dead
If I upgrade a site to 5.7, cant use it at all

Its not just the money, its the time.

If this is a case of the emperors new clothes, let me ask you, is he naked!

I have spent the last week getting my head around word-press, I cant afford not to, sadly

You don't need wordpress. You just need 5.6.3.2 - the long term support release for c5.6

For site visitors, all they see is the content and the theme. All the shiny new features of the 5.7 edit interface and the new technology behind it are irrelevant to them (as would the same site built in wordpress or whatever other CMS you like).

The new features, once they mature, may make life easier for developers and editors of content. But unless a site actually needs some of the new 5.7 gadgets, there is no reason to rush to it.

The C5 blog states 1 year support for 5.6 only

At the moment there is no mechanism for submitting 5.7 items to the marketplace and the PRB is not set up to review any 5.7 submissions.

Hi,

thanks for replying! Then I really think it would be worth adding some kind of warning to the Downloads & Marketplace sections. Something like: "Marketplace themes and add-ons are not compatible with 5.7 yet", since this is a major reason for not using 5.7 in most projects and it seems some users are not aware of this.... (I know this is explained in "Which Version To Use?", but I'm afraid it's not as visible as it should be).

Anyway I completely understand this is a big change, not easy to please everyone...

Also, yesterday I received a newsletter shedding some more light on the subject :) It seems the markeplace will be ready in early October, and 5.7 themes and add-ons will have their own section on the markeplace.


Regards,

Jordi

Hi,
I am also looking at the documentation to make my current marketplace items 5.7 ready. The documentation here is helpful:

http://www.concrete5.org/about/blog/concrete5-sightings/5-7-develop...

But it would be nice to have some specific 5.7 marketplace submission guidelines. I'm guessing that is coming shortly?

Also, I am wondering if there will be some information soon for marketplace developers with existing 5.6 markeplace items who want to add their converted items to the 5.7 marketplace. I'm curious if everything is going to go through PRB (which seems impossible given the number of add ons and themes), or if there is a plan for some kind of streamlined process for converted add ons and themes from the 5.6 marketplace?

Thanks,

Jennifer

The PRB won't have the resources to review a rush of 5.7 ported addons and themes. PRB volunteers struggle to keep up with existing submissions. So I do not expect 5.7 updates to be reviewed through the PRB, or if they are, many will end up going auto-live without approval.

On the other hand, the re-work involved in anything but the simplest addon or theme will result in many issues should 5.7 updates of existing addons not be tested as thoroughly as the PRB would test them, especially when much of the infrastructure in 5.7 is new to the developers (and new to PRB reviewers).

Some developers will do a thorough and reliable job and their 5.7 upgrades will be just as reliable as their existing work. My experience of reviewing PRB submissions suggests that a sizeable proportion of developers will not, either through lack of knowledge of 5.7, lack of experience with 5.7, or just plain careless work.

Yes, I think it will be a bit of a learning curve. But the new version does look amazing so it will be very exciting when the new versions of addons and themes are available on the marketplace.

I personally have little faith in the PRB. It's "nice", but anything but consistent. It befalls to any given PRB reviewer's "preferences" with little regard as to what it's doing, who will be using it, and more importantly "does it work".

I've had packages held up for months at a time over ridiculous non-requirements. (not documented anywhere as a required element). It adds additional workload for largely unnecessary "phantom requirements" such as "I think you should add an option in your settings to enable or disable bootstrap 3 styling" - as if simply adding "//" in front of addHeaderItem is really all that burdensome or taxing of a support issue?

I've had consecutive themes submitted wherein one gets approved in a week, and a duplicate with slightly different look gets held of for months over icons.

It is a colossal waste of professional time and really is not reliable either way.

We've somehow confused the role of PRB members as some sort of lacking code police system, when all it should be doing is testing if it works & if it meets REQUIREMENTS.

And sadly we (the C5 community and PRB members) have no accountability as to are they staying within the simple boundaries of form and function, or are they holding up peoples businesses unnecessarily.

The PRB needs to change and shift from trying to make addons and themes how "you" would do it, to - "does it work?" & "does it meet documented minimum requirements?" - "here are some suggestions...approve"

The PRB should not be holding up peoples businesses over their personal preferences. And right now, they do and that should definitely change.

I have customers emailing me franticly about some of our products being available for 5.7. I already have them working and testing them in 5.7 but am absolutely dreading PRB submission.....sigh.....

Sadly, they could be hung up in the PRB for the better part of 3 months while I wait for whoever to "learn" 5.7 and suggest a bunch of stuff I know for fact my client base doesn't give two ripps about.

Exempt some of you obsessive PSR2 fans, it's really hard to code all that badly in 5.7 and not have fairly rounded understanding of Laravel patterns anyway.

We need to get away from pedantic and get back to form and function.

ChadStrat

The most common reason why something gets held up in the PRB is simply that it doesn't work, in whole or in part. It may have worked fine in the developers current client project, but put it somewhere else and it fails on little things like compile errors, failure to install, breaking when used with any theme other than the theme it was developed under, breaking other blocks, breaking the dashboard.

Next most common is that it does work, but only until it gets an unexpected input or placed on an unexpected part of the page, then it fails as per above.

Then we get security weaknesses that many developers are not aware of, where an interface leaves a site open to injection attacks.

Many of these things may not be important to the developer and their immediate client, but will be important to many potential marketplace customers.

If the addon or theme is only relevant to an immediate and carefully curated list of a developer's own client sites and none of the above matters, then it doesn't need to be in the marketplace. The marketplace is not intended to be a means for a developer to manage support of their own customer projects. Maybe you need a mechanism for that, similar to the marketplace, but independent of it.

The PRB is a fantastic resource and we should all be thankful to John, Tallacman, Goutnet and everyone else who is willing to donate their time to keep the marketplace a safe place to shop.

Calling it a "colossal waste of time" is a mistake. They are giving far more time to you than you are to them. Routinely I am told by developers who use concrete5 that our unique approach to the marketplace (things must work, things that don't are removed) is a huge advantage over other projects where you might lose days installing modules that simply are broken.

There have been some big strategic shifts in the PRB this year, so I'm not surprised that there'd be some organic repositioning as things go. In earlier times our own staff were the final approval for all items; "great choice with Greg Joyce" was an absolute gate keeper. This year we handed over keys to the castle to the volunteers and now there's a handful of individuals who can choose to make an add-on/theme go live at any point. We also changed the workflow so if the submission passed automated tests, it was given a launch date and would go automatically live unless someone from the PRB extended that launch date manually.

It's true there's a lot of subjective feedback happening in PRB threads today, and it's fair to question if those items should be a reason to push that launch date or if the PRB should be more willing to let things go live without their endorsement (which is my view). To that end in the current round of changes we're working on for this site we're changing the message on add-ons/themes that haven't been approved by the PRB:

"Pending PRB Review" on marketplace listing pages should change to: "Has Not Passed PRB Review"

It's a subtle difference, but an important one IMO.

In regards to a 5.7 rush and 5.6 support, a few thoughts:
1) Yes we've committed to keeping 5.6 stable for at least a year. You should expect to see a series of moves from us to encourage all new stuff to go towards 5.7, but that doesn't mean that September 2015 all legacy 5.6 sites will somehow cease to work.

2) 5.7 is really a different beast than 5.6 in some pretty deep ways. While it's wonderful that RadiantWeb is ahead of the game, we're not expecting every add-on and theme to be updated to 5.7 as if it were just a bug release version. We're also expecting to spend some time helping in there if and when there is a big rush.

3) To concerns that an add-on purchase for 5.6 today might not translate to a license for that add-on in 5.7 next month, fear not. We're introducing methods to provide upgrades for free or discounted rates across different add-ons/themes in the current marketplace work we're doing now. It will be possible for a developer to offer a license of NewAwesome5.7Theme to everyone who bought OldSad5.6Theme within the last X days for 0 dollars or for a rate less a full license of NewAwesome5.7Theme would normally cost.

4) We've been very clear that there's no upgrade path between 5.6 and 5.7 consistently for quite a while. It's not a secret. The truth is we're all guilty of not reading from time to time. There's no update button in 5.6 installs that destroys your site because it can't update to 5.7 so if an occasional bewildered client asks why they can't upgrade, I'm afraid the answer will have to be a personalized "there's so much different that there isn't an automated upgrade path, we can talk about migrating your content and adding some of those features you've been thinking about at the same time however." That's an opportunity my friends, not a problem.

It has felt like a waste of time to me. That's just my opinion.

Seems like there could be criteria that allow you to bypass PRB (if you wish).

- developer has 1 or more products that have been license associated more than X times.
- developer has 1 or more products that gross more than X amount
- developer has 1 or more products that have better than 4.5 rating
- developer has more than X number of products approved.

I wouldn't bypass the PRB myself unless I felt like it was just getting to be unhelpful. Which in the case of our Helpdesk addon, it turned into that. In that case, I would have loved at least the option to just say..."nah...I think we're good here. thanks guys." and approve.

John didn't like the fact that the addon was bootstrap icon and grid heavy. Which I specifically wanted as a design goal for the product. I wanted bootstrap3 icons. And he didn't like that I had an override of the content block in my on_start. (you have to do this if you want to dictate the content blocks cache from a package. C5 doesn't give you override options otherwise.)

So it just sat there. Unproved for an ongoing additional month. With the onset of 5.7, I just said screw it and pulled it.

Ironically, I've sold 6 or so licenses outside of the marketplace just by simple mention of it on twitter. So I know this would have met a need. But because of over-scrutinization . It never saw the light of marketplace day.

I start getting "unthankful" when it's getting in the way of meeting needs and doing business.

ChadStrat

Your memory serves you only partially correct. But close.

But whatever John....you win. Next time I will do whatever you ask and concede all differing views to your judgment for the sake of getting it through and moving on with my life.

So, you're right...I'm wrong. On the record. Moving on.

C

Wondering who you might speak about there :D


Radiantweb:

I kind of understand how you feel, especially since I was the one removing your tickets addon from the PRB because of inactivity, and some time later, I am also one that submit an addon that might be closely related (integration of redmine/trac etc…)

Even though John justified it already, (and that I don't have to personally justify it), here is what happened on my side, if you feel there were some kind of conflict interest:

- first, your addons and mine are on a completely different scope (yours is creating a ticket/kb system for c5, mine is integration a remote tracking server to report bugs *about* the website, in fact, I thought to write a remote frontend for your addons as well :) )
- I started developping this addon roughly in end 2012 … (quite a long time before yours kicked in :) )
- second, my addons actually were ready from some time, and I was waiting for your addons to get approuved (but honestly not getting part of the review to make sure no conflict could arise at any points)
- as John said, well issued happened, that were responded by inactivity on your side …

so at some point, we had to make a decision.

That said, if you come to fix the issues the PRB found on your addon (including missing t(), core ui conflicts etc…), you are more than welcome to re-submit it (as we posted in your review I reckon), and I will personally take part on the review to smooth it up (if you allow me off course).

No hard feeling, I think your addon really had its place there, so fix it up, and make a come back, we are all eager to approuve your addon :)

I'm good. I will do whatever JohnTheFish needs. Whatever John needs. [[back to 5.7 work]]

C

Maybe the current line of discussion could keep until after the 5.7 marketplace is ticking over nicely? Seems like it doesn’t matter for the moment as we are not going to have our items that we convert to 5.7 reviewed by the PRB.

I think probably everyone would agree that it is amazing that the people in PRB volunteer their time FOR FREE. And also, we’re very grateful for the work that the concrete5 development team do, and the fact that we can use this great CMS also FOR FREE. But I can understand ChadStrat’s point of view, as my last theme was in the review process for two months. I do think that it is important to value the work that the marketplace add on and theme developers do, as they also contribute to the community.

In regards to the length of the review process, maybe there is too much review work for the PRB, and not enough volunteers? It probably is a conflict of interest having marketplace developers review other people's submissions, but I'm guessing paying staff to do it would be totally out of the question! I have wondered if something could be done to simplify things – like providing more detailed submission requirements. I have read all the info that is available, but there are little things that sometimes get brought up in review that you wouldn’t know are requirements until you submit an item. Maybe we could start a compiled list of things that the PRB has given the "thumbs down" to assist other people in preparing their submissions? Perhaps if there were a more detailed submissions requirement “checklist” it would speed up the reviewing process and make things easier for reviewers and marketplace developers. And less frustrating for everyone :)

Up until May this year the review process was handled by the core team, and that is where the delays often occurred, particularly during the last few months of that process when everything in the PRB was pretty much ignored for months at a time. I had a submission waiting for core team attention for 4 months during that period.

From June onwards the process has been run completely by community volunteers. We try to respond to any new upload within a week. Occasionally we have to say 'sorry, we are very busy, we are extending the review by a week to give us some more time to look at this.' Occasionally the only fair solution to a developer is to give them the choice to let an item go auto-live if they would like. Most developers opt to keep submissions in review.

In the current PRB system, the biggest delays are usually because a submission has failed automated tests or starts accumulating review comments and the developer does not have time to sort them out. When a developer is online, responding to and fixing review comments almost by return, the review dialogue becomes almost interactive and a submission can go sailing through very quickly.

On conflict of interests, I think most PRB members over-compensate because they don't want to allow any perception of such a conflict to creep through. I regularly watch the PRB theme experts offering solutions to issues with CSS, when the review role only requires them to point out that something doesn't work and for the theme developer to come back when they have fixed it.

The best developers work proactively with the review process. A reviewer makes a comment and the developer resolves it and seeks out other issues inspired by that and solves them before the next review pass. The worst developers simply provide minimum responses. A reviewer comments that dialog field XX needs to be validated as a number or it could cause a database failure. so they validate that field, but not the one below it, or on the next block. Such a lazy approach wastes everyone's time.

I agree that a checklist on the marketplace submission page would be an improvement, simply checking boxes with notes beside them would remind developers of some common failings that they should resolve before completing their submission.

On the submission requirements, the most common failing we see is that developers simply have not read the submission guidelines. We get so many submissions at v1.0 where the requirements say v0.9. In itself, its not that important. But such a simple point indicates they have not read and checked the submission guidelines and is usually an indication of many more issues to follow.

The guidelines are long, so maybe that is where the problem lies. I have tried to augment and summarise with a couple of HowTos.

http://www.concrete5.org/documentation/how-tos/developers/get-an-ad...

http://www.concrete5.org/documentation/how-tos/developers/why-do-ma...

Yes, of course developers should read the guidance available before submitting.

I think it's a bit confusing that it says here:

http://www.concrete5.org/developers/submitting-code/marketplace-sub...

that you should start your version at 0.9.0 under the heading "gentlemanly advice". I think I may have ignored that advice previously as I thought it was optional. Maybe other people also misinterpreted that rule.

At any rate, I suppose what I was suggesting was that perhaps there might be some way of making things easier for developers and reviewers alike, but there probably is no point talking about it until the 5.7 marketplace has been running for a while and things are back to "normal".