I support that Plone - even out of the box - makes a good fit as a document management solution for organizations - who do not need that full blown super high support level agreed sharepoint solution.
I like your quote: "However, the vast majority of organizations are not large. Let’s help them.". I support that. Plone can make a good fit for many organizations.
I'm a Plone core contributor and earn my money with selling customized solutions for clients with more complex requirements than Wordpress or Drupal can serve out of the box. For me, Plone is a framework to build upon. It offers you a lot, but you also have to customize a lot. You won't sell Plone out of the box over a Wordpress solution. There are not even any useful high quality themes for Plone (known to me). I'd love to see that fixed and much of my work goes into making Plone better, so that I don't have to fix something again, for another customer.
Regarding all the critique on Plone 5.0 - I think Plone 5.1 will make it better. There are some open questions and issues which have to be sort out and fixed. For example, I'm looking forward for the current project, when I'm going to implement a new theme based on barceloneta. I expect to have to fix a lot along the way.
I'm happy that we did not sent out press releases to our german based it magazines! That has to be done with 5.1.
I was (am) in love with Archetypes, but Dexterity is great. I shoved Dexterity to lot of customers and they all loved the TTW + behavior support, and knowing that this can easily moved to filesystem is amazing.
Still, from the backend/development approach, things with Archetypes were easier and cleaner. Apart the lack of API, sometimes the problem came from z3c.form (which I will never like): doing simple things as creating a validator, or a dynamic default value for a field is possible, but seems half-baked sometimes.
Finally let me say this: I spent many year developing on old Plone sites and now I'm finally able to use Plone 5 in production. There are issues? Yes! But is a breath of fresh air.
Hi. I'm reluctant to call them bugs, anymore than I would call the navigation issues that I have previously discussed on the site a bug
First because I am open to the idea that I am missing something and it does work, just not how I expect.
Second because I believe this open community is the best place to see if people agree with my take on what I would call a missing feature.
I have posted bugs before after confirming and If there is a call for these features to be added I would be glad to add as a bug
If it didn't work as you expected it then the bug is that its not intuitive for users to understand how it works. UX encompasses the full experience from marketing, to learning, to documentation, to engaging with the community. Any hicup in that process is fair game for the bug tracker.
Asking others here if they have the same problem is actually not a good idea as you are talking to experienced users who have no idea whaf is confusing first time users. You are better off showing the plone to someone who has never seen it before to confirm the UX bug.
sorry to say this, but you've failed ;-)[quote="rileydog, post:40, topic:1437"]
i. When I add content and use the ‘publish’ dates. I don’t see them as working. I have a site (mckennariley.webfactional.com) where, as a test, I changed the publishing date of the homepage to a future date. So why is the page still visible to users?
because that's the way it works: when you set the publication or expiration dates of an item, you're only messing with the visibility of such item; the item will be filtered from catalog searches and listings, but it will still be accessible to anyone who knows the URL; so, if you are setting your item as the default view of your site everybody will be able to see it, and it will not work as you expect.
I was looking at the documentation and I think this is not clear anywhere:
Come on Hector , you say that like if we were 3 persons working full-time for 3 days.
I would rather describe it as a pleasant spare-time exchange of ideas which somehow results in few lines of code (because that's our favorite way to persistent our ideas).
You might register an invisible "Viewlet" checking the publication period. A similar approach is used in "CMFDefault" (and I thought I had it also seen in a previous Plone version). Instead of a "Viewlet", you could also use a post traversal hook (--> "ZPublisher.BaseRequest.BaseRequest.post_traverse") for the check and register it in a traversal subscriber. Likely, some care will be required to avoid the check on templates that do not really view an object (e.g. a login template).
@hvelarde: the fact that plone makes pages before publication date visible is one of the more unintuitive things about plone. Yes its how it works but I think supporting this + a way to have stuff invisible before publication is good too.
@dieter: you could do it that way. You can also achieve the same thing using a diazo rule that hides the content based on an expression that looks if the page is published or not. Not that hard to do.
A third way, is an idea we are trying to get a client to pay for. A content rule that waits until the date specified in published or expires to activate. Kind of like a delay action. We were going to add it as a feature to collective.cron. You could then combine it with an action to publish it and then unpublish it. or remove it or email it or whatever.
Is "published" not purely controlled by workflow and independent of the publication period?
When I understand "diazo" correctly, it can only perform decisions based on information directly provided by the Plone output and not based on some "internal object state", such as the publication period (maintained as content fields).