Several helpful things
The option to install OpenPublish ontop of an existing Drupal installation. This should definitely be an option.
A breakdown of the OP installation package that indicates inter-relationships between modules.
It appears to me, the closer you stay to Drupal and maintain a separate autonomous OP application you will decrease support issues significantly.
Learning how everything fits and works is pretty tedious, so some explanations along these lines would be helpful.
The OP definitely has good value. Just having a good consolidation of Drupal modules for most of the OP tasks is valuable.
The theme situation is bad, IMO.
It isn't necessary to reinvent the wheel and depart from Drupal standards, this is just frustrating for users.
The modular concept of Drupal is very adquate, and has made it the winner it is. Standard application methods sure don't hurt either.
I do not use the Acquia Drupal, which is very standardized. I don't want many of the features nor do I anticipate this is the future for Drupal.
The developers are trying to make a niche, as you are with OP. IMO, long term prospects don't look good for proprietary remakes of Drupal.
Maybe for neophyte dummies an Acquia Drupal may look great, but the thresholds for competently using drupal... are still difficult to cross.
I just don't see proprietary applications of Drupal as being the entrance door to a complex application and it's processes.
I think proprietary applications such as Acquia, OpenPublish and others should take their roots completely in a working drupal. Embellishments should be made through the modular concept of Drupal, and conventional structures of Drupal. Departures from the standardized structure and modular concept should be added to, but not integrated into the structure fo the Installation.
This is not to complain. I am interested to read other thoughts on these things, especially from OP devs.
Thanks
Comments
Excellent ideas.
I am surprised this hasn't generated more discussion.
Totally agree. OP's good...but it shouldn't be a branch solution
I'm with you, as far as my limited understanding of OP goes. I haven't started to hack the theme yet, though I know I'll need to, but it's frustrating that it doesn't seem to follow normal block control conventions...or am I missing something?
Ernest
It does not "follow normal"
It does not "follow normal" (i.e. use provided by core) block management system, because the latter is both bad for performance and scalability and is extremely limiting.
Core block management is a relatively primitive system that assumes that you have one layout across the entire website with exactly the same list of blocks and ordering of blocks. That's the fundamental assumption core block management is based on. And that assumption is horribly wrong for publishing systems like OpenPublish.
It was later "improved" by allowing to have visibility settings but visibility settings are a weak patch on a fundamentally flawed system.
You can not even assign the same block to different regions, under different conditions.
Context module was created because block management system was weak and Context is far superior to the core system. Yeah, Context gets some getting used to, maybe and we understand it may be a little frustrating initially, but we are just trying to provide the best solution available in Drupal. There's nothing more frustrating than not being able to implement a solution and that's where core block management drops you, more often than not.
.............................................
http://twitter.com/inadarei
What I see is a huge push by
What I see is a huge push by the OpenPublish development team to utilize some of the new Drupal technologies being developed by Development Seed including Context and Features. I'm also very interested in Development Seeds Spaces module and I plan on using all three in my next OpenPublish website.
I think that Dries is fairly impressed with some of the work going on with Development Seed if not also involved judging from his promoting http://openatrium.com which is an advanced intranet system. Also Dries on Drupal.com gives heed to some of Phase2 projects. Since he is the force behind the project with, from what understand, $14 million dollars in venture investment.
I tried to talk a friend into letting me set up up OpenAtrium for her to coordinate her large events planning. She said that she has been using a Google service and it's been great for her, which puts her out their in the cloud. The way, out of the box, Google serves her intranet, probably suits her needs, but OpenAtium can do something more with a little effort. OpenAtrium can be extended. Most of the major modules of Drupal whether it's video and image handling, connecting people on mobile networks using modules such as http://drupal.org/project/mobify , using CCK and Views modules to create an inventory or directory, and the barcode module to keep track that inventory or even http://drupal.org/project/mobile_codes which is a really super cool way to track that inventory, especially for someone who is managing fund raising events with millions of dollars, movie stars and celebrity chefs involved. (It's six-thirty, do you know where your movie star is???)
It's possible to create a CCK content type called, oh, let me just pull a name out of a hat, an 'article'. Create a menu for that type and allow external and anonymous access to it from outside the intranet. What you can have now is collaborating organic groups that can publish material to the public. Why stop there? Because people are busy, isn't a reason to not connect the information to itself and throughout the internet. It's no trouble at all to install http://drupal.org/project/rdf and http://drupal.org/project/opencalais into OpenAtrium.
I took an installation of OpenPublish and I stripped it of almost everything. What is that show with the Foose car person on the Discovery channel? The one where they steal some person's old car and completely strip it, then rebuild it with new paint and everything within a week? That' s been my experience with OpenPublish. There are a couple loose wires hanging out, but since we're serving a little over 16,000 pages yesterday and today to about 2000 unique visitors each day and I'm the only person who knows what they, the loose wires, are, it's really not that bad.
I need to come back to all these crazy things going on. The greatest asset and perhaps the biggest complaint about Drupal is that every module has to satisfy every little condition at the expensive of simplicity. For everything that you can think of doing there are many combinations of many different modules that can do it. The folks at Development Seed, probably encouraged and support by Dries (conjecture by me) and the big bucks that are behind him, are pushing for this feature module. I think the idea is to take eight modules combine them, configure them to do some task that no one module can do then package the whole idea to be shipped out.
Think about it from a publishers perspective. What newspaper online doesn't have a classified ad section? Drupal has a classified ad module which really lacks luster. It would be so much better to have a configuration of CCK, Views, Imagecache, Rules, Moder8 and a commerce system such as UberCart. People have done it but it's complicated and difficult to share with the community in order to get further development and feedback. It's even more complicated to package it as a module. If a person could combine modules to create a feature like a classified ad system with ability to package that feature in such a way that it can be exported from Drupal installation such as OpenAtrium (why an intranet can use a classified ad system I don't know probably would be a great way to sell the office betting pool on football) to an OpenPublish installation and it requires and warns the next person who is going to install it which modules are needed, Drupal would be amazing.
Who has that?? Elektra CMS at $1000 a pop? I don't think so. 'nough said.
Marine job board with Drupal 7 at http://windwardjobs.com
I think I'm going to develop
I think I'm going to develop modules now. The first module I'm going to build is going to extend the barcode module to not take a value submitted through a CCK form stored in the database but the User ID number of the current logged in user.
Everybody is allowed to attend the events hosted by the newspaper and they tend to be huge (and lots of fun.) Problem is that people have to either have the card already with a barcode printed on it (which there were thousands of floating around even before I started the site) that is their user id to get in or they have to register at the party then get a card with a barcode printed on a sticker on the back. We then submit all that information collected at the party into the Drupal database and create new users for the recent sign-ups at the party emailing them with a welcome email using the user import module http://drupal.org/project/user_import. The user import module will probably give way to the migrate module http://drupal.org/project/migrate which works well with both OpenPublish and OpenAtrium.
So using the event calendar with the date module in OpenPublish the person will be presented with a block (I'm praying the context module will make this work very easy for me). In the block will be a pretty button I build in fireworks that says 'Click Me For Party Access and Information'. Then they will get a page ready for print that contains the party location on a google map, the event information, nice and tidy, and most important their personal information with a BARCODE!!! I'm brilliant and the lady at the events who has to put in all this information is just going to adore me. Now I only have to make it work. Wish me luck.
Marine job board with Drupal 7 at http://windwardjobs.com
@domineaux, sorry for a
@domineaux,
sorry for a belated response. We were very busy with 1.7 and fell behind on following up on this, indeed, very important and interesting post.
I will try to answer each question:
The option to install OpenPublish ontop of an existing Drupal installation. This should definitely be an option.I understand where the desire for this comes from, but it's not really possible technically. Customized Drupal installation is a codebase, dumping another code-base on top of it (e.g. OpenPublish) would lead to the necessity of merging two codebases, which can lead to unpredicted and potentially very bad consequences.
In 1.7 we started moving towards the next best thing: implementing functionality using Features. it is not the same as installing OP on top of an existing Drupal, but definitely provides much more modularity. You could install OP Core and OP Features on top of existing Drupal and get something useful, if not the entire OP.
A breakdown of the OP installation package that indicates inter-relationships between modules.Modules listing page gives a pretty good idea about those: http://example.com/admin/build/modules
It appears to me, the closer you stay to Drupal and maintain a separate autonomous OP application you will decrease support issues significantly.We stay very close to Drupal and never modify third-party module for the sake of functionality. The only patches in OpenPublish are bug-fixes that module maintainers have not released yet. Eventually they should all clear-up.
The OP definitely has good value. Just having a good consolidation of Drupal modules for most of the OP tasks is valuable.Thank you. We sure hope it is.
The theme situation is bad, IMO.Agree. The theme was a quick demo, not supposed to be used as a base theme. It's clear that people want/need a base theme so that will be #1 priority post 1.7. When we release OP 2.0 and demo it at DrupalCon SF, it will have a much cleaner, more useful and designer-friendly theme. And this is a promise.
We have a good plan, we realize all the shortcomings and it will be cleaned-up. OP will have a good base theme.
It isn't necessary to reinvent the wheel and depart from Drupal standards, this is just frustrating for users.Not quite sure what you mean. Further down you mention Acquia Drupal. OpenPublish is not based on Acquia Drupal. There're several modules that are included in the distribution, for convenience, but installer does not even enable them by default.
It isn't necessary to reinvent the wheel and depart from Drupal standards, this is just frustrating for users.I am going to have to respectfully disagree. There is absolutely nothing in OpenPublish that is done in a "non-Drupal way".
I am guessing that you mean the use of Context instead of Drupal Core's block management?
Using Context instead of block management is not a "non-Drupal-way". Contributed modules exist exactly because "just the core" functionality is usually not sufficient or is not optimal. At least 50% of contributed modules improve core Drupal's behavior. As far as they do it according to Drupal's architecture - there is absolutely nothing wrong with it. Eventually, new major versions of Drupal learn from contributed modules and that's how we get Drupal 7, Drupal 8 etc.
We use Context because it is far superior to core block management. Not only core block management system has significant performance and scalability problems, but it is also extremely limiting. It's very hard to create varying layouts within one theme, with just core block management. This is why popular and important modules like Context and Panels exist and there's nothing wrong with them, whatsoever.
If you don't mind me saying it, I think you are just used to the accustomed way, but if you give Context a chance and try to get used to it - you will see how it is far superior.
Thank you for your comments, we appreciate them a lot. Even the ones we may disagree with :) Both Drupal and OpenPublish are open-source, community-driven software and their #1 strength is, indeed, in the community around them.
Thank you.
.............................................
http://twitter.com/inadarei