Review

5 reasons why the Drupal CMS is not ready for the enterprise

By Hiveminds ⋅ October 20, 2008 ⋅ Post a comment ⋅

Many Open Source content management systems written in PHP want to be recognized by the business industry as being "enterprise" ready. This is not only a mark of prestige and status but places them in a position where large companies are ready to invest in the software as a platform for their projects. Drupal is now trying making its move to be enterprise ready but has a long way to go.

Design Patterns

Drupal is a content management system built on PHP and is noted for its flexibility. But it is a flexibility that comes at a price. In its present state Drupal (version 6/7) is not scalable. Well, it is scalable but it is not easy to do and those that do it are either very secretive about how they accomplished the task or are too embarrassed to show their ugly solutions. Drupal is based on the front controller pattern and suffers from all of the drawbacks of such a pattern while complicating it with an adherence to procedural coding. A front controller is a simple method for guiding all requests for web pages through the same system. Because many different requests pass through the front controller, it can be performance sensitive. Placing logic in the front controller which is not used for all requests will add unnecessary overhead to some requests.

There is also a helper pattern the application or page controller. This usually an array or text file of some sort. In the Drupal CMS it is an array that is implemented by the menu system. Though an application controller works well with front controller this is where compatibility with other design patterns end. Front controllers do not play well or get along with sibling design patterns. This is because front controllers are by design created using the Singleton pattern meaning that only one instance of the front controller can exist. It also brings with it some other baggage like emulating a registry and not being extensible. Bringing another design pattern into a front controller environment like Drupal is almost impossible. This is bad because you need those other patterns to help solve difficult issues or when programming extensions and third-party applications that may run under Drupal. You can't just say that you will offload something to the registry pattern when you need a registry or the factory pattern when you need to handle forms. You can read more about the why not's and cons of implementing a front controller in PHP here.

Changing to a different design pattern like MVC, which seems to be the holy grail of web application design nowadays and starting over is not going to hurt since there is no backwards compatibility in Drupal versioning. There is however a wall of stubbornness to be climbed. That wall is thinking that the use of Classes and other available OOP PHP tools can be emulated in a procedural fashion. OO design with PHP in large applications is something that is avoidable but at a great cost. A cost that becomes very apparent when trying to find out where something happens within the core code and testing. If Drupal were a fully object oriented application it could make use of helper classes to overcome many of its shortcomings.

So Drupal is not an MVC front controller like Java Struts. But it seems to be slowly finding its way there. If you have been following the development of Drupal over the last few years you will notice that ideas that have come into the CMS are those that already existed in Struts. Take a look at the phpMVC project and then study the latest version of Drupal in development. You will see the similarities and you can in fact write a roadmap for Drupal by using the diagrams for phpMVC. You might even notice that Drupal is moving to be parallel to another MVC front controller CMS, Joomla!. The latest version of Joomla! 1.5 MVC is a nice piece of work. The difference is that Drupal developers are trying do something similar using only procedural code and without any forced conventions for code creation or even a plan.

Duct Tape

One of the things that PHP developers try to do to offset the overhead of having thousands of rows of code loaded in per request is to use conditional includes. This may work okay for the core structure of a CMS but it does it does not help much when an end user adds in dozens of contributed modules. This is true because many developers are lazy and do not want to take the time to add in the logic that conditional includes require. They may also be put off by the fact that complex business logic is very difficult to implement using conditional includes. If you are building a large shopping cart system with dozens of supporting modules adding in another hundred or so small includes to shave overhead is probably the last thing you will be thinking about. Trying to maintain the system afterwords is an large and time consuming task. I feel for the groups that have to maintain and upgrade things like the Drupal e-commerce modules with every new release.

Database Architecture

Another reason that Drupal is not scalable is because all the content for the application is in a single database table. Here is a true life story. The company I work for is seriously thinking of taking student.se over to Drupal. During a recent update to a newer version of the site I sat down with the websites administrator and went through the system. The very first thing I asked about was how the database looked. Migrating users is always a pain and I wanted to get an idea of how dirty the system was. He replied back " Which one? There are five of them." Drupal is not designed to be spread over multiple databases. When I say this I mean multiple databases not database servers. To put it simply there is just no way of spreading the load that is put on the Drupal node table without some code breaking re-factoring. You may just as well start from scratch. If you put in 10 different node types and the number of rows for each type is between 100, 000 and 600,000 you find yourself with a single table with millions of rows that is constantly being used, updated and searched.

Caching

One of the big fixes for the front controller of Drupal is the cache everything policy adopted with Drupal 6. While caching goes along way once it's done it's done. You cannot ever hope to compensate for bad design choices by caching. The better way is to start re-factoring the design and make better choices. Caching should be a last resort. Caching is also a huge factor if you are thinking of using Drupal as a social networking application. Caching and real-time do not like each other. Users of social networking sites love those who's online, status reports, chats and other real time interaction.

Third Party Software

Getting third party software to work in a front controller environment is not easy. This is because you can't just send requests off to the application that handles them. The requests have to be filtered and massaged by the front controller. Adding in helper modules is part of what the front controller needs to get meta data on the third party application so that it can be sewn into the rest of the system. This of course brings with it more overhead. Because of the non-extensibility of procedural code the best way to allow third party software to integrate is to create loads of API's. This bring with it another set of problems, having to guess which parts of the system are to be bubbled out.

Re-factoring

Because of the design Drupal cannot be updated without effecting the entire system. You can never tell what is going to happen when a module is turned on or a bit of code changes. It kind of like putting your finger in a glass of water. The the entire glass of water is influenced and no matter where or how you place your finger this happens. There is also a lot of unseen activity and the water may have been contaminated. Something that will only be visible as time goes by and the contamination grows. If this happens there may not be much of a choice. You will have to start over with a new glass of water. This is as versus other patterns that are built like a pile of toothpicks. While the pile maybe in a chaotic order you can straighten it out with a careful touch. When you draw out one toothpick you can do it without moving the others if you are careful. You can also see how things go to some degree and even make predictions based on the visual layout of the pile.

Globals

If you have spent even a small portion of time going through the Drupal API then you know that the system lives of off the use of globals. Just about all PHP programmers worth anything have agreed that the use of globals will make your life miserable when it comes time to re-factor code. Though the use of globals is okay for small applications once you have built an enterprise size website with hundreds or thousands of pages and users then changing code becomes an insurmountable task.

Overriding Code

One of the best things about PHP frameworks created using the object oriented Class and method structure is the ability to override the core systems when necessary. Codeigniter is very impressive in the way they implement this. If you don't like the way a method in route.php( a Class )works then place your own route.php and override the core file. But in Drupal overriding code in the core is convoluted and impossible for most of the structure. This is one of the major drawbacks in using procedural coding one that very seldom gets mentioned in arguments of the Procedural Programming vs. OOP. Taking a look at two sources of database overhead the functions node_load() and user_load() you will be able to identify a common problem. They are designed to only grab a single set of objects, one row of fields from the database. The result is that if you want a hundred users or nodes you will have to create a loop. Looping causes more connections and database queries. The solution is to create your own functions and hack the core which kind of defeats the purpose of having the framework.

Update: While doing some research on which CMS to use for an upcoming project I ran across Jesse's blog. He reinforces many of my previous writings about the Drupal core problems and the article is good enough to become reason six. His follow-ups in the comments here are even more concrete. As I look at Drupal 7 development it looks as though nothing has changed.

Conclusion

Perhaps a 6 or 7 years ago Dries Buytaert, who is I believe was java programmer originally and the originator of the Drupal CMS, read great things about the front controller design and all of its pluses. But these pluses are not available in PHP. If Drupal were ported to another language other than PHP it would probably scale and serve very well in the enterprise. If PHP had some type of persistence and maybe if it worked more like Java there would be no problems. But you can find developer blogs all over the internet that repeatedly say "PHP is not Java". 

Print This PostTags: , ,

Discussion

35 comments for “5 reasons why the Drupal CMS is not ready for the enterprise”

  1. Just about every CMS product I’ve seen, other than very specialized products such as Wordpress and Mediawiki, has serious problems.

    I don’t think PHP needs to be “more like Java.” PHP’s lack of persistence means that PHP applications are more reliable and scalable than Java applications via a “shared-nothing” approach.

    For instance, many Java webapps require constant reboots of the Tomcat application server. This doesn’t happen with PHP. Period.

    A PHP bytecode cache mitigates many of the problems involved with reparsing complicated apps.

    Posted by Anonymous | May 8, 2008, 16:41

  2. That was just a “What if” type statement. I don’t want PHP to be like Java. Just saying that any in any plans to use a design pattern that works well in one language should be carefully investigated before trying to implement the same pattern in another.

    Posted by Hiveminds | May 8, 2008, 18:49

  3. I am not an expert in design patterns … so I can’t really debate with you there.

    However, you can query multiple databases from Drupal:
    http://drupal.org/node/18429

    Also, in terms of traffic capacity, Drupal does scale well, and I’ve found it reasonably well documented:
    http://www.johnandcailin.com/blog/john/scaling-drupal-open-source-infrastructure-high-traffic-drupal-sites

    Plus Drupal has numerous sites that prove its high-traffic capacity:
    http://buytaert.net/tag/drupal-sites

    Also, you mention Joomla 1.5 as being impressive, but I have yet to find an actual high-traffic site being hosted on Joomla, nor have I heard of hundreds of sites being hosted on one Joomla installation (like Drupal can do).

    Also, *this* site is using Drupal….

    Posted by Anonymous | May 9, 2008, 00:04

  4. Actually you cannot query multiple databases by default there is db_set_active() which makes a call to the hardcoded db settings. But Drupal is not set up to handle multiple database natively.

    To explain: Let’s say you have entries of the type blog and guestbook. But you don’t want to have them in the same table or database. You want to optimize as much as possible. You can not explicitly tell Drupal that blog entries should go in db_blogs.tbl_blogpost and that db_gbooks.tbl_gbpost should handle all nodes of the guestbook type. This would require rewriting the core system to allow it to see the different databases.

    Now if this where another framework other than Drupal the system would be written so that you could first override the database handler as mentioned in the article using route.php. Then you would be able to write code that would do this on a need to have basis.

    The article you mention is just reinforcing what is mentioned here. Scaling across multiple database servers and using clusters is not the same as using multiple databases.

    As mentioned in the very first paragraphs of this article, there may be large enterprise sites using Drupal but they do not show how its done. My suspect nature tells me that they are simply using Drupal as a pretty front end to some very hardcore systems. Or perhaps they have hacked into the code so much to get everything to work that the CMS is only Drupal in name.

    No you probabaly have not heard of any Joomla sites that are huge enterprise systems. But Joomla! does not propogandize that it is such a system. Joomla! pushes excellence in the area that suites it most.

    The reason that this article exists is because one board of directors exec listened to all the propoganda surrounding Drupal and got mesmerized by the large brand names mentioning Drupal. He failed to do any research, one a code editor, ask and trust the opinions of the company programmers and made descisions based on inaccuracies. These decisions are now written in stone apparently. Because even after reading an article like this one the company will continue on trying to use Drupal and wonder “Why is it taking so long?” “Why are we spending more?”.

    Posted by a Visitor | May 9, 2008, 07:57

  5. Ideas of futures articles
    - five reasons why the Internet is dead
    - five reasons why Microsoft will disappear
    - five reasons why Apple sucks

    and son on… I’m always sceptical about post like this one with only negative sides (as articles with only positive point of view).

    Posted by Anonymous | May 9, 2008, 17:46

  6. Not everything written in this world has to be given a positive light for it to be true and accurate. Take some time and learn to program then take a closer look at the code. Then read the article again a tell us if there is anything that is not on the money.

    The items talked about here are listed to be informative not negative. There are plenty of people ansswering the question “Can I do this with Drupal” with “Yes you can”. But there are very few if not none that tell developers and user what cannot be done using Drupal. The limitations of the software is never discussed.

    Posted by Hiveminds | May 10, 2008, 09:19

  7. “those that do it are either very secrective about how they accomplished the task or are too embarassed to show their ugly solutions” (this is the point where I stopped reading because I realized you don’t know what you’re talking about)
    Seriously dude? Have you ever spoken to a drupal developer or gone to a drupal conference? Have you visted drupal.org?
    This article is basically spam. How much did microsoft pay you to write this?

    Posted by Anonymous | May 13, 2008, 18:59

  8. The author is right about a secret society. You only have to do a google search for Drupal and Sony or any other big company. You will find podcasts and fluffy articles but no stats or code, advice, pros cons or anything useful. Just “You can build stuff really really fast!”. Total crappola.

    Bravo Hiveminds!

    Posted by a Visitor | May 13, 2008, 23:05

  9. I’ve said many times — publicly, in articles I’ve written, and to the clients that we consult with — that Drupal is not a magical solution to any problem. It is a BAD solution to many problems. Crystal Reports is a terrible social publishing tool, too. No technology, no framework, no product, is made of magical unicorns and rainbows. It’s worth noting that a huge percentage of the Drupal community is made of passionate individuals who found it when looking for solutions to small-scale problems, and began participating in and giving back to the community. The tools and solutions they find essential will not be the same ones needed by, say, the New York Observer or SonyBMG. When those companies use Drupal, it will be used in different ways. Consultants and development shops who don’t acknowledge and understand this — who sell a Drupal-Or-Nothing approach to every problem they’re given, are either wearing blinders or unscrupulous.

    We just spent two days talking to a client who had started to build a data warehousing application with CCK and Views, given the community’s emphasis on those tools. They were concerned this was the wrong path and wanted reassurance from us. We offered no reassurance — that IS the wrong path! Drupal’s sweet spot, for them, was presenting quickly customizable user-facing functionality to customers, while feeding data to an external warehouse built using more traditional tools.

    Someday, they might migrate to a homebrew solution, a Django app, or any number of options for the public-facing portions. For now, though, it’s enough for them to realize that they can step back, build the “enterprise” portions of their project with tools that make sense, and use Drupal for the portions that it excels at — fast turnaround user-facing social content publishing. If that message isn’t being discussed in the Drupal community a lot, the reason is simple — there’s a large pool of people making band web sites, magazine sites, social publishing tools, etc., than there are people building high-octane enterprise systems.

    I don’t hear anyone in the Ruby community telling me that RoR shouldn’t be used to automate industrial control systems, either — but that doesn’t imply that DHH is leading a conspiracy to deceive the manufacturing industry. Is it that difficult to grasp?

    Posted by eaton | May 14, 2008, 18:04

  10. You have done a Good reaserch on this
    http://readerszone.com

    Posted by Anonymous | May 15, 2008, 12:58

  11. Reading this I was left asking what type of “enterprise ready” situation are you talking about? To say something is enterprise ready or not really needs to be taken into account of the situation. It needs to be put in context. Referring to something as an enterprise ready document management system vs. as enterprise ready intranet portal is two different things. The context is different and therefore the solution should be different. So, what is the context you are getting at?

    I, also, get a sense you are on the outside looking in with drupal and that your research has not been that in depth. For instance you speak about MVC as a holy grail in web application design and suggest drupal change to it. Drupal currently implements a form of the PAC design pattern which is further development on the MVC pattern. To change to an MVC pattern would mean removing some of the more useful features of drupal.

    I’m not saying that drupal doesn’t have it’s ugly spots. It sure does. I’m not saying that drupal isn’t the wrong solution for some problems. There are times when it certainly is. But, this writeup seems to be one missing a certain amount understanding of drupal and it’s active development and doesn’t seek to explain what he means by enterprise situations it’s not suited for.

    Posted by Anonymous | May 15, 2008, 16:55

  12. The only enterprise ready cms based on php is called eZ Publish! ;)

    Posted by Anonymous | May 17, 2008, 22:41

  13. “Enterprise Ready” is nothing special or desirable IMO.

    In my experience “Enterprise Ready” means horribly crufty arcane and inefficient platforms that are designed to support an army of expensive certified consultants that spend months/years implementing them. Let alone the huge servers required to run them on at an acceptable performance level.

    Drupals lack of enterprise readiness has far more to do with the need for excruciatingly complex staging, workflow and approval systems than anything to do with coding or design.

    Scalability? Drupal already runs on sites that get more traffic than a lot of large enterprises. The proportion that these large Enterprise sites of the web that exceed Drupals ability to scale is tiny and not worth worrying about IMO.

    BTW - Dries is still a Java developer. His recently completed PhD was to do with Java and was supervised by James Gosling himself. Drupal sure isn’t suffering from ignorance of OO design patterns (and I’m not just talking about Dries).

    Posted by Anonymous | May 18, 2008, 12:12

  14. So you are right over the world ?? It remains me the story on Techchrunch with a journalist (for obscure reasons) who did’t like Wordpress at all. Nobody says that Drupal have no limits, but your article seems more about secret revenge, blog buz publicity and ego concerns (when you says “I’m one if the one to point about problems”…). Hum instead of this personals considerations what are your solutions ? Oh I see… one talentuous programmer king of PHP, industrial solutions like Typo 3 or EZpublish ?
    But if you are honest you will find too horror stories about this solutions. And even more there are very serious articles about how bad PHP is.
    In conclusion critics are always constructive, the problem is that your article don’t bring any directions or clues and seems to be very alone.

    Oh we know… Drupal is propaganda and only you knows the truth. But seriously, what are your solutions ?

    Posted by Anonymous | May 26, 2008, 07:58

  15. I’m afraid that the rebooting hassle does not account for all java Webapps. Apps based on f.e. OSGI don’t need constant deployment reboots. Even complete enterprise ready CMS’s are becoming available based on these architecture concepts for server side programming.

    See for example this article on the serverside:
    http://www.theserverside.com/news/thread.tss?thread_id=49386

    New add-on components (OSGi bundles) can be deployed at runtime directly inside. The components can be installed and updated inside GX WebManager at runtime, without restarting the JEE application server, thanks to the power of OSGi.

    Interesting development?

    Posted by Anonymous | May 29, 2008, 12:09

  16. Scalability primarily concerns itself with the server environment(s) and hardware being used. I don’t really see the reason in saying that drupal scales badly. Bad code does not always equate to poor scalability.

    I don’t think any *PHP* developer could give an example of a similar solution which scales perfectly/elegantly either. Not without being a fan-boi of some other language/technology/framework.

    Posted by Anonymous | June 12, 2008, 14:41

  17. I sincerly hope that you are not saying that throwing enough hardware at Drupal will solve scalability problems. If so then you are not familiar with the software at all.

    As far as a mention of scalable code in PHP, you can take a look at PEAR or the Zendframework and find PHP code that scales across database clusters and multiple web servers.

    Posted by Anonymous | June 13, 2008, 08:14

  18. I’ve been working with CMS systems for 10 years

    every one that I have written, used, tested, seen demos of - they all suck.

    For 10 years I have been waiting for someone to come along and corner the market with a great product …

    It’s easy (and pointless) to bitch about any CMS

    Creating a good CMS is deeply challenging (that’s what makes it fun :)

    Drupal doesn’t stand out for its suckiness - it stands out because some things about it don’t suck.

    If Drupal isn’t the best CMS in the world - I want to know what is!

    It’s very far from perfect - but seriously - is there is a better CMS out there? (commercial or open source)

    Posted by Anonymous | June 16, 2008, 11:47

  19. Your opinion are great

    Posted by Anonymous | August 27, 2008, 21:08

  20. Before you write an article claiming that X or Y is nor is not “enterprise-ready” it would not hurt to understand what the word “enterprise system” means. An enterprise system is a system that integrates several distinct systems required to run a large organization like: its operation management, financial management, customer relationship management and other systems in one coherent, inter-connected system.

    In this regard: yes, Drupal is not an enterprise system, because nobody ever wanted it to be and nobody claims it to be; but that has exactly nothing to do with all the cliche reasons you list, like whether front-end controller is a good design pattern or not. Oh, for God’s sake, you really have nothing better to spend your time on?

    I am sorry, but your analysis stinks of “black-or-white” kind of arguments. Most things are gray! There is no black or white. You need to grow up and realize that.

    Good luck

    Posted by Anonymous | September 25, 2008, 20:45

  21. I have noticed that many tend to run at the mouth about the subject and do not mention anything about computer science code or programming. Not that I have anything against fan-boys but real you could pick up a book every once in a while and maybe come up with something more original than “you are wrong”. Maybe even read the article rather than just the title. You might learn something!

    Posted by Hiveminds | September 25, 2008, 22:20

  22. While knowing that it’ll sound as a cliché, if Microsoft software is enterprise ready then anything is.

    Drupal has limitations as well as any platform. In my personal research I haven’t found a platform/framework offering a better ROI. We take what’s good in Drupal (we feel it is plenty) and deal with what’s not. At the end our numbers make sense. We’ve had to tamper with the code for many projects, but having to write a page or two is a hell of a lot better than any alternative we’ve seen.

    I’d like to see a follow up to this Drupal review comparing CMS/Framework options with an accent on ROI.

    Good article.

    Jose Onate
    http://www.avenuewebmedia.com

    Posted by Anonymous | October 7, 2008, 08:32

  23. This site runs a version of Drupal released in 2004, what’s that, 4.4? I don’t see how you can expect to have your comments about ‘enterprise’ taken seriously if you can’t follow basic security procedures on your own website - running long unsupported versions of the software you’re talking about.

    Posted by Anonymous | October 8, 2008, 02:16

  24. Sometimes I wonder about comments like this because they are typical of people that underestimate who they are addressing and seem to think that only one particular person or group is smart, capable or inventive.

    I don’t need to update this site with the last patches, security fixes or versions of Drupal. I am quite capable of spotting security flaws and fixing them myself. I am a programmer that knows Drupal 4.4 to 7 inside and out. I can add to or comment out core Drupal code and I pretty much know the outcome before I touch the keyboard.

    That aside. Using Drupal 4.4, Wordpress, or PHPBB for this website does not disqualify my writings.

    Posted by Hiveminds | October 8, 2008, 22:24

  25. Sorry, but your last comment is some of the biggest nonsense i ever heard.

    Be smart. Delete it.

    Or you really think someone will employ you after that comment?

    Posted by Anonymous | October 13, 2008, 22:16

  26. If someone chooses not to employ me because I actually know what I am talking about and am not afraid to say it then they will not want to interview me.

    I especially will not cater to those that post anonymously asking me to do something without good cause or specific input. So what are you saying?

    1. That I cannot know Drupal well enough to fix bugs or do my own security fixes?

    2. That people are right in their pre-judgment of others skills and knowledge based on the tools or code base that they use?

    3. That I always have to have the latest version of a particular software package installed before reviewing code and designs?

    4. That you know me personally and have established through testing or have other proof that I am not capable?

    So tell me which part of the comment is non-sense? Seriously, I do not think that anyone is going call me and give me a job based only on what I write in my blog or any one comment within. That would be silly of them.

    Posted by Anonymous | October 13, 2008, 22:48

  27. What i wanted to say is, that Mr. Hivemind is perhaps not that smart as he thinks. His answer gave me that impression. So i spended 30 minutes to see whats up with the security here.

    Because intelligence will not help you in security.
    You want a proof? Then listen:

    Your DB server of hiveminds.us can be found of under http://www.hiveminds.us/dh_phpmyadmin/... (removed full link).

    The username starts with dbhiveuser… and your password has 6 chars and the last is a 3.

    My advices:

    -don’t name your db like dbhivemindz, with a ‘z’ at the end, it looks childish.

    - don’t use password with 6 chars, without any special char

    - don’t use for development a full web enabled sql server where you also stored other old DB from productive sites… there are your old but perhaps still valid passwords stored

    - don’t let your phpmyadmin unprotected and open to the web, believing it can’t be found because its hidden by some obscure url. Thats #4 or #3 on the “what can i do wrong with a public linux LAMP server installation” list.

    - don’t use the same password in every DB for your main and admin accounts. It gives the impression you use them on all sites and people can start to decode it and try it out

    - and NEVER EVER release a tar ball just out of your working place and put it online…

    … you can forget to change the settings.php where your nick & password is stored

    And now i would suggest you login to all your sites, change your password and remove the fireorb tarballs where everyone can grap your DB access out of it.

    And perhaps you upgrade your drupal sites now too. Because someone who did this major mistakes i described *perhaps* not noticed a small security flaw in some code lines here and there too. Even he is smart as you.

    Posted by Anonymous | October 14, 2008, 02:01

  28. Because intelligence will not help you in security.
    You want a proof? Then listen:

    Your DB server of hiveminds.us can be found of under http://www.hiveminds.us/dh_phpmyadmin/... (removed full link).

    Pretty much a given. Find a database server is not a breach of security. Anyone familiar with Dreamhost, Bluehost or any other large hosting company knows the paths to phpmyadmin because the hosting company posts the info in their support docs.

    The username starts with dbhiveuser… and your password has 6 chars and the last is a 3.

    Well, that is not even partially true. If you want to try and run a brute force attack then you might get in after a week or so. But of course you will not find anything worth your trouble because this is a dummy database used for refreshing the demo site, which does not exist any longer. Besides that your guess about the password is wrong so perhaps a week is a short period.

    My advices:

    -don’t name your db like dbhivemindz, with a ‘z’ at the end, it looks childish.

    There is no active database with that name. 3 years ago this site was Hivemindz.com and the db is trash left over from that. Doing google search is probably showing old cached info.

    - don’t use password with 6 chars, without any special char

    Haaha, this makes me laugh. I change my passwords every other month due to the fact that I cannot control Dreamhost.

    - don’t use for development a full web enabled sql server where you also stored other old DB from productive sites… there are your old but perhaps still valid passwords stored.

    You still have only gotten information from demo sites that have not existed in a year. What valid passwords?

    - don’t let your phpmyadmin unprotected and open to the web, believing it can’t be found because its hidden by some obscure url. Thats #4 or #3 on the “what can i do wrong with a public linux LAMP server installation” list.

    - don’t use the same password in every DB for your main and admin accounts. It gives the impression you use them on all sites and people can start to decode it and try it out

    - and NEVER EVER release a tar ball just out of your working place and put it online…

    … you can forget to change the settings.php where your nick & password is stored

    I don’t use settings.php perhaps you have gotten this from the demo of FireOrb. Which is open to anyone that wants to use it.

    And now i would suggest you login to all your sites, change your password and remove the fireorb tarballs where everyone can grap your DB access out of it.

    Now, I know you are lieing because the FireOrb tarballs are hand rolled.

    And perhaps you upgrade your drupal sites now too. Because someone who did this major mistakes i described *perhaps* not noticed a small security flaw in some code lines here and there too. Even he is smart as you.

    So far you have only gotten in where I let everyone in and that’s at and old demo on the wrong server with a publically displayed login. I think that you are over estimating yourself. A as I said before why would I take advice from some anonymous person that to this point has gotten everything wrong? I also fail to see how upgrading to software that has known flaws is going to increase my servers security. Let’s get this straight database server, web server and code security are not the same thing. It does not matter how good your code security is if your server security is bad.

    Posted by Anonymous | October 14, 2008, 06:53

  29. Oh, you removed the dbhivemindz db…

    And you also found the bad tarball.
    Clever you changed the settings.php BEFORE you call me a lier.

    Not so clever that you forgot to disable the automatic backup of the editor/patch you used.

    Now there is a ” settings.php~ ” in your new tarball, still including still full nick&password line.
    Because thats of course nonsense you have for sure nothing against it when i post it here.

    $db_url = ‘mysqli://dbhiveuser_1:cmc123@db.hiveminds.us/fireorb_firewater’

    BTW, i had the feeling you perhaps are losing the dbhivemindz DB. So i clicked on EXPORT in phpmyadmin (one reason you should not have it public avaible at web - goddamn, put a .htaccess in your phpmyadmin directory blocking access or at last using a native, unique directory password. phpmyadmin suffers since years from security flaws appearing here and there. There is a reason every website is frequently checked by a hacker bots looking for /phpmyadmin directories.)

    Should i contact the over 70 users there in? As i see there are at last 2-3 of the emails from some other admins and well known persons. I can send them their MD5 encrypted passwords or better their full DB entry. A little MD5 check with their passwords can ensure they see their valid hivemindz entries.

    Again: I am still not impressed from your security powers

    Posted by Anonymous | October 14, 2008, 14:49

  30. 1. Tarballs are archived until the scripts see that there are more than 14 or a certain time has passed (14 days). So you will always be able to find them.

    2. The dbhivemindz was use for demo.hivemindz.com and so really only contains dead emails and users and has not been on the server for 2 years so you must be getting your copy from somewhere else. Contact the 70 users if that is what floats your boat.

    3. $db_url = ‘mysqli://dbhiveuser_1:cmc123@db.hiveminds.us/fireorb_firewater’ is always going to be open to some degree. But since you insist I will remove the entry point and add a *.sql to the tarball.

    4. There are htaccess web authentication in place. The only problem is Dreamhost makes the login the same as the database login and is unchangable. I have spoken with them about this over the years but have never be able to get them to change the routine.

    5. We are still talking about server security and not sql attacks, XSS attacks and other code oriented items.

    Still you are only getting what I allow and nothing more. If you have concerns about server security then I am sure Dreamhost support can help there.

    Posted by Anonymous | October 14, 2008, 16:15

  31. Nice article but it looks like your are stepping on toes and leaving yourself open for to retaliation by way of attacks on your site.

    There’s some other talks about this but sadly nothing tech.

    Posted by Anonymous | October 21, 2008, 19:12

  32. http://coldacid.net/blog/2008/10/06/drupals-poor-design

    Posted by Anonymous | October 21, 2008, 19:13

  33. “But Drupal is not set up to handle multiple database natively.”

    This is simply not true, and the author of that comment is ignorant of Drupal. Drupal *is* setup to handle multiple databases natively. It is simply poorly documented. There is an issue open on Drupal.org to improve the documentation and clarify this point.

    You can create an array of database tables, as well as the default database connection string. Commonly this is used as a means to PREFIX tables in the same Drupal database, but it can also be used to put data in an entirely different database for a specific module or task, simply by specifying the database name and a *dot* when setting the tables array in settings.php.

    For example, here we are using a shared database for some user and profile data and then a different database for the rest. And sharing databases across different servers is the domain of MySQL, not Drupal, so this will never be something Drupal handles, nor should it or any other CMS:
    http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

    Refer to this for an example of Drupal’s core ability to handle multiple databases:
    http://drupal.org/node/291373

    Posted by Anonymous | November 7, 2008, 13:20

  34. As a Drupal developer and team manager having worked on several enterprise-level implementations of Drupal, I can assure anyone reading this article that Drupal is enterprise-ready, we have no problems, it scales easily, it isn’t “secret” or rocket science, and (as someone else has already posted) there are plenty of good examples of enterprise sites using Drupal.

    The one that most immediately springs to mind is Comic Relief. I have worked on TV show websites before, and the traffic during the commercials and straight after a popular show is so brutal it is tantamount to a denial of service attack. If Drupal doesn’t scale, how can a televised campaign attracting millions of viewers get away with using it?

    Btw, the guys who made it scale published their work:
    http://drupal.org.uk/presentations-drupal-developers-london-july-2008
    http://www.drupal.org.uk/files/AWS%20&%20Drupal.pdf

    We used a similar setup for a 100,000 user social networking site in the US, but our database configuration was a little more robust than theirs.

    No system is perfect, but Drupal is nigh on as good as it gets, in spite of its problems. Scare-mongering like this is unfounded.

    Posted by Anonymous | November 7, 2008, 13:37

  35. I was one of those that complained about the new Abandonia.

    http://en.wikipedia.org/wiki/Abandonia#History

    Looks like experience to me. This is the best reason for me to stick to writing my own scripts.

    Posted by Anonymous | November 7, 2008, 14:50

Post a comment

© 2003-2009 Hiveminds Magazine. Entries (RSS)
Powered by WordPress Theme by The Masterplan