OP needs a progressive install

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
domineaux's picture

I no longer have OP installed, except on one site.

It is practical to give up, because so many issues don't make it viable. In my situation, I have a large number of sites to maintain and OP site defeats purpose.

I would love to work with OP and through issues over time, but I would really need a backdoor.

By backdoor I mean the ability to drop back incrementally, but with module dependencies that cannot be done.

First I think OP should start as a "clean drupal" similar to Acquia Drupal.

Second, there should be a clearly defined upgrade path for adding to OP functions.

Third, if there are issues you should be able to disable modules to return to working drupal installation.

Fourth, it would be best to use well supported drupal modules where possible in lieu of proprietary modules.

Five, updating has enough issues, but if there are dependencies with modules it can mean your websites can be vulnerable to security problems.
That is, until OP team has altered the OP install to compensate for dependency and provides updates.

Six, you must remember the module developers are working on their own constantly updating and fixing.
It is tough enough for them to keep up with their one module, much less taking on all their stuff and your own.

Seven, Updating should be done as it is with a normal drupal installation. Run status report, cron and then download and install updates.
OP should have a separate update process that doesn't or isn't affected by third party modules when updating.

I realize so much work has gone into OP and I want to be respectful.

My time is at a premium and I just cannot rebuild sites once they are underway when annomalies and issues make the sites unworkable.

I have one site now on OP 2.2, but I have been reluctant to work with it.

It will take several days to get it fully setup and I'm unsure to spend that time.

I can spend the same time on a regular Drupal site, and know I will have a competent working site.

It will not be as full featured, but everything will work.

I do think the OP concept is viable, it just needs to facilitate site developers better.

We face issues with every drupal module we install. We never know issues can associate with them.

IMO, it is best practice to look at the issues queues before installing any module.

By that I mean, if the module isn't being support it is probably best to not install it.

Even now the feeds modlule is giving some people havoc, and it can create some issues within the nornal drupal install.

I had to rebuild a drupal installation just trying to remove it. LOL

I have read where others have viable installs on shared servers, which is my situation.

Please don't be discouraged by this post, you have an excellent idea and your OP will be a very important application when you have worked through problems.

I look forward to that day, but I see it further away with each update of other modules.

Somehow, you have got to insulate OP from dependencies to drupal 3rd party modules (for sure).

Comments

I agree...

IrishGringo's picture

I had some OP sites up, but replaced them for more standardized DRUPAL installs. I try not to do custom modules just so I don't have to support them. I was counting on OP to be a collection of "best Practices" and standards. But I get the sense that OP is overly customized for small collection of people.

I am going to try op2.2 once more.. and try to keep it as simple as possible.

But FYI.. the reason I am considering OP as oppose to doing a custom Drupal site is:
1... Standards Based... so I don't have to re-invent any wheels.
2... Calais
3... Watch what the pros are doing and learn from them.

I second that thought. I have

heavy_engineer's picture

I second that thought. I have one site in pre-production thats about 30% of the way through evaluation. This morning i upgraded 1.7 to 2.0 then to 2.2. Up till then i assumed that OP was a bunch of standard modules with some special sauce. Seems i was a bit mistaken! Alarm bells started ringing when i had to manually delete files during the upgrade and enable/disable modules.

I guess i have been spoilt using Aegir and Drush make etc - additionaly in the context of Aegir (mass hosting) i don't think i could offer openpublish to customers just in case i had to do manual 'stuff' to it on a regular basis. Additionally if some of the modules (i haven't investigated yet) aren't maintained on d.o. or on a feature server somewhere then its another round of coding to automate someone else security alerts etc but its not the end of the world.

In an ideal world (and i guess i had incorrectly assumed this) OP would be built using Drush make - i guess it can so long as the special sauce is standardised and available somewhere - but im not even sure this is the case for Managing news or Open Atrium either

Systems architecture and Drupal development - www.initsix.co.uk

Thank you for a long,

irakli's picture

Thank you for a long, thoughtful list.

Actually Larry Garfield has written a blog post today that, for me, resonates with the topic at hand: http://www.garfieldtech.com/blog/architectural-priorities and shows that some of the concerns are not OpenPublish-specific, but are present in Drupal per se and are a result of trade-offs.

As for my personal opinion, I will have to think about the list a little more, before I can respond.

Thank you.

.............................................
http://twitter.com/inadarei

OpenPublish

Group organizers

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week