Hi!
First, the Drupal success does not came from "smart marketing" but from "smart coding and attitude".
If you have a bad product, like Plone 5 is right now, there is no marketing that could help you.
Drupal deliver what the majority of users needs, and, more important, what the clients think they need.
What the clients prefer?
Easy, Drupal has a much small TCO than Plone, and these days cost is almost everything in business.
If it were not for the bugs and the regressions, technically Plone is far superior than Drupal, no doubth about it.
But, when it cames to cost, Drupal brings to important things to clients: 1) lower cost, because they can bargain the price; 2) tranquility, there are so many Drupal companys and devs out there, they have flexibility to choose, just in case.
Another thing: when they trial Drupal and Plone, they are not stupid, they know Drupal is mostly inferior but they perceive it as a far more polished product, no hidden surprises to bite you.
We have a old client on Plone 3.3 and we've been talking for months to upgrade to Plone 5.
Last week I've been to their office, and tried to install plone 5.0.3 on two of their servers for them to trial.
(I have no admin rights, because the servers are maintaned by another company)
What a shame, I could not even had sucess in installing Plone!!
On two diferent servers!
So, probably next week we will have the news that we lost that client.
(probably to Liferay, that's another shame )
Sorry my friend, but you are the one that is wrong!
Repeating myself: " I don't care about "my 2 problems", my company does not use Plone anymore, I do not use Plone anymore, I just been testing Plone 5 to see what's new, and re-learn a little of Python. "
So, you or anyone in Plone really don't have to FIX ANYTHING FOR ME!
You should fix it for Plone itself!
The ones who wrote stupid code like having a "listing_events" template hardcoded with the phrase "Future Events" even if it is applied to a folder that only contain past events, should correct his or her mistakes.
(it is easy, the listing template should use the folder or collection name, like summary_listing does)
I know that my co-workers will be ashamed to make such errors, and will apologise. Better yet, they will never deliver code like that, because they have pride and self-respect.
But, for my surprise, with Plone, no one cares, it is just business as usual, everyone seems happy.
Or am I wrong??
The core devs should be planning a Plone 5.x release just to fix all the important bugs, but instead, the focus is on more and more features... and more bugs, of course!
I'm not ranting, honestly I don't want to hurt anyone, just want to alert where are a few of the weeknesses of Plone.
Maybe my english is far from perfect to explain my thinking?
I'm trying to give something back, maybe is not what you wish to hear.
Plone 5 is not a bad product. It has a few serious issues and issues one can discuss about. As with all dot zero releases of any software: they are always broken. It will take some time and a dot one or dot to release for becoming mature again. Apart from that: your statements about Plone are far beyond from being substanial and supportive. I am also critical about Plone but at least my rant usually contain something substantial..so please grow up and come back with more solid arguments...your argument here are truely on the lower blather level.
@JotaMG - regarding your experience with installing Plone - You should have known the environment where it's going to be installed, tried first and be very confident before installing it at your customers environment. Or better yet, install it on a server you own and let them play there until they were able to make a decision on taking it or leaving.
Plone is not the easiest environment, but still I think it's the most flexible for integrators and developers to build customized content management systems, perfectly targeting the requirements of customers.
But it takes something to be able to do this - whether experience or money to pay someone with the necessary experience.
That's how I see it.
I think we want an easier integration experience and there we can learn from Wordpress and maybe Drupal also without repeating their failures. For example, through the web plugin installation like at Wordpress is impressive - if you don't care about security and UX problems.
@djay I think, I'll try to find some time to try "BigPipe" approach with blocks. It should be possible to do it without explicit middleware using Zope's "stream iterator" producer for Medusa (for WSGI a similar middleware would be required). It would need JavaScript to move the streamed tiles into their places. If it works, a server-side non-JS composition could be implemented later.
@djay@vangheem I can confirm that it is possible to asynchronously stream (transfer-encoding: chunked) tiles with Plone (Blocks/Mosaic) in BigPipe style. Explicit support from ZPublisher would make code look cleaner, but nothing prevents trying this out to get some benchmarks.
Devil is in the details:
fetching tiles can only happen post transaction to ensure that tiles render only after possible db updates
async fetched tiles each get their own zodb connection and may have different data
javascript is required to move tiles in place, so should this be opt-in, but how?
the actual cross-browser code to move tiles into their place
tiles could be fetched using ZPublisher (a lot of code) or using http (simple, but possibly some overhead; maybe less overhead if using localhost and VHM URLs)
all the possible corner cases
possible issues with front-end proxies/balancers/caching
yes, you are wrong; I don't know the person behind the nickname, but I know most core developers and many of them work endless hours, even on weekends, because they love Plone and they care about the Plone community.
so, you don't need to lecture us every 3 or 4 weeks telling us the obvious (that Plone 5 is plenty of bugs); keep opening bug reports, if that's the only thing you can do.
we are a small and very productive community and this place is plenty of smart people and I find very disrespectful to come here to tell us that we are doing shit because everybody, even your fellow co-workers and the Drupal guys, make this kind of mistakes also... don't believe me? you don't have to:
perhaps the most important part is if we are going to get better performance using this approach or not; I would suggest to evaluate that first with some proof-of-concept before trying to dig deep into it.
Although, it's now pretty obvious that big pipe as such is not a good fit for your usecase. With site layouts (everything with tiles) it could provide "feeling" of instant load in logged-in intranet environments, because of need for JS, it might be better to just build JS app on top of restapi...
I assume that you are already using ESI and getting the possible benefits from parallel tile rendering?
(Although, the current ESI transform is not optimal, because it does small subrequest for every tile to figure out if both head and body injections are needed.
ok. so in summary drupal is better because its popular (which is why its well supported, more devs etc etc). doesn't help us work out how to make Plone more popular but I think we all agree that Plone would be better if it was. (I hope we all agree on this).
My only other takeaway (other than bugs which I think has been well covered), is that install experience could be better. Drupal, WP has always had an edge here by being LAMP and being supported by hosters directly because of that. In fact that is likely the single biggest reason WP and drupal are more popular.
Again, I'm not sure what we can do about that, but I suspect tools like docker are going level the playing field a lot. GitHub - plone/plone.docker: plone on docker is now a true one line install of Plone and direct support from AWS will only make that easier. We have some nice self scaling docker builds that once we perfect, we might contribute.
So to summarise -> We need to make Plone popular and all the other nice things you hope for us (quality, no bugs, cheap devs, hoster support) will all happen. And to make Plone popular we likely need hoster support (and quality and cheap devs). easy!
@datakurre. wow. interesting. So with each having a different ZODB connection we using up a lot more RAM per instance right? And is the asynccore stuff actually coming into play? ie during a object load, will it which to rendering a different tile that already has its data loaded?
I'm not sure its true to say it would be better off as a JS on top of a RESTapi. That would mean its much harder to customise, and also slower. A page, has to load, and then start calling the subparts with REST. Unless you plan to make a CMS public view as a one page app it will be slower. Bigpipe idea seems to faster becasue you don't have multiple requests yet you do get the percieved fast loading by getting most of teh page quicker.
But it would have to be opt-in. It would be a themers choice, if they build their theme with the right code and right html, they could enable it to get that boost, with the downside of using more RAM. and again its only going to be a boost for pages that require heavyish network access somewhere in it.
@djay Async tile rendering could either a) queue tile rendering requests for the current instance using its worker pool b) fetch tiles using HTTP to let load balancer share the load to existing zeo clients. Option a) is probably faster for individual tiles (re-uses the warm ZODB cache and has no HTTP overhead), but because tile rendering is usually CPU bound, parallel rendering a lot of tiles could be faster only by balancing rendering across multiple processes (option b). We cannot get away from the limitations of CPython
Asyncore's / Medusa's role here is to make asynchronous chunked streaming possible from Zope, but data for those chunks must be fetched in separate parallel threads (using the previous options).
I didn't understand the last question. The main request renders a tile layout for a content object. Once that request (possible transaction) is committed and its zope worker thread is free to handle more request, the layuout chunk (up to ) is streamed to browser, parallel thread pool for fetching all tiles (each which completely separate request) is initialized and tiles are streamed in order their threads complete.
folks, this gets an endless thread with various mixed topics. please use the feature of linked topics if you choose to switch context. I close this this now, linked topics should be still possible.
)
easy!