I do Drupal for a living and I like the system. However I've always been intrigued by Plone and wanted to learn it well to broad base my knowledge of CMSes in general. I've played around with Plone in the past and was both mesmerized and repulsed by it -- depending on the day.
But then again here is what I saw as the advantages of Plone
Python sweet Python
Built on battle hardened and uber mature Zope 2
Zope 3 style which is now available in Zope 2 also and therefore in Plone
Objects and not SQL
True separation of configuration and content (unlike Drupal where configuration and content is totally mixed up in the database)
Very powerful system to make custom content types (unfortunately not via a UI)
However it surprised me that there was nothing that I could find equivalent to views ( http://drupal.org/project/views ) and that taxonomy (i.e. classification) was not a first class citizen. Every Plone product seemed to take its own approach to taxonomy. All in all, though I loved its extreme and idealistic approach, it always struck me that everything was so darn difficult to accomplish in it.
I've really been hoping for Plone to succeed and every few months will explore its RSS feeds only to go back dejected.
I thought I'd test out Plone 4. The new feature list in Plone 4 was totally underwhelming to me ( http://plone.org/products/plone/features ).
Drupal 7 new features ( http://drupalcode.org/viewvc/drupal/drupal/CHANGELOG.txt?revision=1.373&view=markup) and Wordpress 3 ( http://codex.wordpress.org/Version_3.0 ) seem to have done tons more in their new major releases.
Moreover replacement to Archetypes through Dexterity ( http://plone.org/products/dexterity/documentation/faq/how-is-dexterity-related-to-archetypes/view ) is also a great step forward. So while Plone 4 itself may be an improvement over 3.x is it enough to keep Plone in the reckoning amongst other CMSes?
Which brings me to my question:
Is Plone on a steady decline? Whats the future of Plone? Am I wrong in my assessment that Plone is not adding functionality and features at the rate other top tier CMSes are?
This http://www.google.com/trends?q=plone seems to confirm my fears.
Should I give Plone 4 a try and make it my "second" CMS?
Let me get the bias out of the way first: I'm one of the co-founders of Plone, so make of that what you will. ;)
Plone 4 is in many ways an "intermediary" release — the original plan was to make it into a large release with new UI approach (new layout system Deco), improved type definition system (Dexterity) and improved theming story (currently referred to as XDV, name will probably change).
Along the way, we realized that we needed a smaller release before we did that, so the major improvements got pushed to a new Plone 5 milestone, and Plone 4 was turned into a infrastructure / cleanup type release.
With that goal in mind, the team delivered the fastest Plone yet (it trounces Drupal, Joomla and WordPress for speed), improved a lot of very important infrastructure (files are now stored outside of the database, it uses much less memory than it used to, and scales a lot better to large number of parallel requests).
The innovation is still ongoing, and now that Plone 4 is out, we're fully focused on delivering Plone 5, which should have a lot of the new features and improvements that were originally planned as Plone 4. In the meantime, we have an extremely solid and fast base to work from, and deploy customers on.
You can also make make use of a lot of the Plone 5 tech in Plone 4 already — examples include the aforementioned Dexterity type definition system, the XDV theming system, and several other infrastructure improvements like the Chameleon template language (adds ~50% speedup for most pages).
So, no — we're not adding features at any slower pace — if you look at the source code history and activity instead of Google Trends (which isn't a very useful metric for something as niche as a CMS system), you'll see that there are more active developers and more code improvements than ever before.
Yep Collections do most of what is described by that description of Drupals Views. One thing that collections don't do out of the box is the grouping/taxonomy. There are additional plugins that can help do that such as collective.collection.yearview. Taxonomy options could be stronger but in reality nested collections work for most use cases.
As for the future of plone? Plone's popularity has remained static for the last couple of years as it has gone through it's massive internal restructuring. It's lost developers and gained developers. Compared to the rise Drupal and CMS's in general that may look like decline. The important thing now is that, due to that restructuring, Plone is now very developer friendly. Due to Diazo/XDV which most Plone integrators are switching to, Plone is now very designer friendly. It's also now fast and just as secure and flexible as it always has been. Expect Plone to start getting a lot more outside attention and growth from now on.
As Limi mentioned the mantra has been 'Plone 4 is the evolutionary release, Plone 5 is the revolutionary release'. As DisplacedAussie said, look at 'Collections' in Plone, they are like saved searches and combined with the Collections Portlet are pretty powerful.
Coming up in Plone 5 is the Deco/Tiles system for content editing, this is going to be really pretty amazing, and you can see in initial preview of it here: http://www.mefeedia.com/watch/32696814
Basically the entire page is made up of composite elements, each one is a first class item and addressable with its own URL. They can be dragged about the page on a grid as you see fit.
-Matt
Related
Hi we are at a point in our wordpress website that it would seem appropriate to update the WP version. We have an existing busy site, have paid a good amount to hack plugins and core stuff to get it working the way we want it to. I'm debating the wisdom of updating the entire foundation of the site over a few minor vulnerabilities and enhancements that aren't interesting for us. My thinking is this.
The reason for upgrading appears to be because a given version may have some security issues. So you go through the painful process of updating, which usually kills all your plugins. You then spend many frustrating hours talking to plugin support people telling you 'it must be clashing with other plugins', or you take the time to / pay someone to fix everything (again).
After upgrading you have to take time to relearn the system and all the changes. You may have to adjust your workflow due to these changes, and maybe retrain your entire team. And after all that, in 5 minutes hackers find the security issues with the current version - which MAY be worse than your previous version - and you have to go through the whole operation again.
The aim of running a website is to not spend each and every day dealing with upgrade issues. The aim is to have a system that does what you need it to do, the way you want to do it. Once you have that, it's not useful to keep changing it 'just because', it's not a fashion show. It's not an iPhone, pushing users to upgrade their entire phone because they added a letter on the end of the phone name and changed the color from grey to a slightly different grey.
I am of the opinion that it is much more economical - once you have a system set up the way you need it - to just get a dev to fix any vulnerabilities in your existing WP code. And, somewhere down the line, if there was a VERY good reason you should update (e.g. major new PHP version) - then build the site from scratch and get a dev to migrate the data. This could be 7 years later or more. The time effort and money you would save doing it this way, seems a lot more logical.
Say you were building a Ford Model T in your garage. You are ordering parts from a supplier and you are halfway through the build when your supplier starts sending you parts from a Ford Capri - "Oh we are doing parts for Capris now". So you can the Model T and start building a Capri. Halfway through the build, your supplier starts sending you parts for a Mustang. And so on. You will spend your entire life half building that car and at no point end up driving the C*.
Given the performance issues of WP out the box - and the logical progression of a successful site to start migrating to a bespoke solution - it would make sense to me to take your existing WP, strip out the crap you don't need and optimize everything. At that point, it's not really WP any more, vulnerabilities fixed, and it is essentially already a bespoke solution without needing to start from the absolute ground up.
Does anyone have any thoughts on this? Serious question, we need to decide if we are going to go through all this a 4th time and I'm not really feeling it. Any input would be appreciated thanks. To make this 'it must be a specific question' I will just ask - are you a very experience WP dev, and do YOU keep jumping through the update hoop every 5 mins?
I'm working for non-profit whose has a very outdated system for tracking donations from its benefactors based on Microsoft Access 2003. They want to move to a web product (it's only used in-house), but I am very hesitant to build a lot from scratch. A technical consultant suggested using Drupal to replace the system, by building around it. I am unsure of this however, as Drupal seems mostly to be for content display only and not ideal for any sort of mathematical operation (such as summing the donations received in a year), reports, etc.
Does anyone have any experience using Drupal in this or a similar maner?
Drupal is very flexible and there are a lot of powerful modules for (almost) anything.
I don't know your requirements, but I will recommend you give a try to this CMS. If your question is about how manipulate maths operation, look https://drupal.org/project/computed_field
But I think your solution can be near to CRM Core module: https://drupal.org/project/crm_core with https://drupal.org/project/crm_core_donation
I found many articles on the web but most of them are so old and written for drupal 5 or even 4. I'm looking for recent modules or recent updated modules for drupal 6. And a manual on how to use them.
I already found this article http://drupal.org/node/275705 which is pretty good but also more then 2 years old so probably not up to date.
Thanks
I use:
i18n-6.x-1.5.tar.gz
l10n_client-6.x-1.8.tar.gz
lang_dropdown-6.x-1.2.tar.gz
languageinterface-6.x-2.5.tar.gz
multicurrency-6.x-1.x-dev.tar.gz
Note that you best try all these modules first, and when you start building your site, start from scratch and do some planning. There may be issues otherwise with pages that cannot be found / accessed and so on.
Especially with the following modules I had some issues:
front-6.x-1.2.tar.gz
tcontact-6.x-1.1.tar.gz
The language interface comes in very handy and allows you to look for strings on a page and immediately translate them. If you are really going multilingual, you may consider using the transliteration module as well when you are storing files etc.
Greetz,
Joachim
I am helping someone with a Drupal 6 installation, and they are very distressed by the performance of the site, even though they are only in the phase of defining content types. Just loading the Modules list can take over 30 seconds, and importing a content type took close to 3 minutes.
This is installed on a large shared UNIX system, and I am running other D6 installations on the same server with no real problems (some slowness, but nothing quite this bad). I spent some time this afternoon disabling all of the non-core modules on the site, and was able to get the load time for the Modules list page down to about 5 seconds. As I re-enabled groups of modules, it seemed that the one that incurred the greatest performance hit was the CCK family of modules (a 15-20 second increase in page load time for the Modules list).
Again, I have other sites on this server that are also running CCK (and most of the same other modules) and not experiencing anything like this. The main difference is that this very slow site has a ton of content types and CCK fields defined -- 46 separate content types, and 162 CCK fields.
I'm drawing a conclusion that there is a direct connection between site performance (at least in certain operations having to do with creating and editing content types) and number of content types and custom fields, but I have not been able to determine exactly what the impact of this content types and fields is, and whether there is anything you can do to mitigate their impact.
I did install the Devel module, and found that the biggest performance drain on the Modules page is in the queries having to do with cache_menu, but I'm not sure if that's linked directly to the number of content types and/or fields.
Any guidance is appreciated!
Thanks,
Paul
First off: The modules page is indeed a wicked beast, as it completely flushes all of Drupal's internal caches and rebuilds them to ensure that freshly-installed modules have the latest data. It's not a good predictor of site performance (since usually only specific administrative tasks flush those kinds of caches), though it is annoying.
Second: Importing content types ALSO flushes those caches, because CCK wants to make sure that everything is up to date as well. It's sub-optimal, but there you have it.
Finally: The number of CCK fields and content types you have DOES affect how much work gets done when caches are flushed and rebuilt. CCK pulls in all the information about all of the defined content types and their fields, builds a data structure to describe them all, and uses that cached version for later reference. With hundreds of fields and dozens of content types, rebuilding that cache of data takes longer, exacerbating the delays you're seeing on the modules page and when importing new content types.
The good news (such as it is) is that this particular issue doesn't have too much impact on the site's overall performance, just the administrative actions that flush those caches.
This is the same answer I made on another Drupal question; if Eaton's answer didn't solve your problem, maybe you should have a look at the Views module and dynamic menu rebuilding.
Every time, the menu is rebuild, leading to 100's or even 1000's of queries.
Depending on how the joins are made, you could end up with two similar joins, on the same tables, leading to doubling the number of queries.
More information can be found here
At the company I work for, we have an intranet that provides employees with access to a wide variety of documents. These documents fall into several categories and subcategories, and each of these categories have their own web page. Below is one such page (each of the links shown will link to a similar view for that category):
http://img16.imageshack.us/img16/9800/dmss.jpg
We currently store each document as a file on the web server and hand-code links to these documents whenever we need to add a new document. This is tedious and error-prone, and it also means we lack any sort of security for accessing these documents. I began looking into document management systems (like KnowledgeTree and OpenKM), however, none of these systems seem to provide a categorized view like in the preview above.
My question is ... does anyone know of any Document Management System that allow for the type of flexibility we currently have with hand-coding links to our documents into various webpages (major and minor , while also providing security, ease of use, and (less important) version control? Or do you think I'd be better off developing such a system from scratch?
If you are trying to categorize the files or folders in the document management system, That's not a difficult task. You only need to access to admin panel to maintain the folders or categorize the folders
In Laserfiche, You can easily categorize your folders regarding the departments and can also be subcategorized them
You should look into Alfresco. It's extremely extensible and provides a lot of ways of accessing the repository.
Note: click the "Developers" tab for the community edition.
My question is ... does anyone know of
any Document Management System that
allow for the type of flexibility we
currently have with hand-coding links
to our documents into various webpages
(major and minor , while also
providing security, ease of use, and
(less important) version control?
Or do you think I'd be better off developing such a system from scratch?
Well there are companies that make a living selling doc management software. Anything you can get off the shelf is going to be a huge time saver, and its going to be better than anything you could reasonably develop by hand.
I've used a few systems:
Sharepoint: although I hear some people don't like it, I didn't either ;)
HyperOffice worked really well for my company of around 150 employees and has all the features you describe.
Current company uses Confluence, I like it :) But its probably one of those tools whose pricetag isn't worth it, especially if you're only using a subset of its features like doc management.
I haven't used it, but one guy I know raves about Alfresco, a free and open source doc management system. I looked at its website, seems simple enough to use.
We also faced a similar problem. However version control was more on our priority and we did look into many solutions in and around. We found Globodox extremely easy to install and use and more important the support team was absolutely fantastic
Try Mayan EDMS, it's Django based, and open source, used it as a base and build the custom features you wish on top of it.
Code location: https://gitlab.com/mayan-edms/mayan-edms
Homepage at: http://www.mayan-edms.com
The project is also available via PyPI at: https://pypi.python.org/pypi/mayan-edms/