Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
PHP GUI Programming

Drupal Competes As a Framework, Unofficially 178 178

tgeller writes "Drupal developer Ben Buckman attended the BostonPHP Framework Bake-Off with the hopes of pitting the CMS against CakePHP, Symfony, Zend, and CodeIgniter. He was told that he couldn't because Drupal is 'not a framework,' a response he felt was 'coder-purist snobbery ("it's not a framework if you build any of it in a UI").' So he decided to unofficially compete in the back of the room by accepting the challenge of building a job-posting app in 30 minutes, while the official competitors did the same from the stage. He recorded the results, which are impressive. In the process he raised the question: What is a framework, anyway?"
This discussion has been archived. No new comments can be posted.

Drupal Competes As a Framework, Unofficially

Comments Filter:
  • Steak (Score:5, Insightful)

    by Anrego (830717) * on Thursday February 24, 2011 @07:15PM (#35307104)

    I’d call Drupal a tool with a framework for extending said tool rather than a straight framework.

    Why? Just what my gut tells me. At the end of the day it doesn’t really matter (save for contest qualification purposes I guess). Use what does the job for you.

  • by Megor1 (621918) on Thursday February 24, 2011 @07:21PM (#35307140) Homepage
    I'd never thought I'd see the day when PHP developers would have "'coder-purist snobbery"!
    • by sco08y (615665) on Thursday February 24, 2011 @07:35PM (#35307264)

      But seriously, if you're using PHP and you start worrying about The Rules, you've thrown out your only reason for using PHP at all.

    • by SmallFurryCreature (593017) on Thursday February 24, 2011 @11:50PM (#35309096) Journal

      The first you don't hear much about, they know the language, its stengths and its limitations and simply use it because nothing else out there can compete.

      Then you got the second kind, that will be fuming at the last bit in the previous paragraph. They are forced to use it for some reason, mostly because the latest language they wish to use simply isn't supported enough. Personally, I think these are the lesser developers, the bad photographers who think if only they get a Hasselblad they will turn into a top class photographer instead of having to use this cheapo poloraid that nobody could ever possibly use to make art.

      Personally I also think frameworks are silly. If you can lash up a site in 30 minutes, then the request simply isn't distinctive enough. Your site will be the Xth among thousands and fail. For the next job board site, you need to add something new, do it different, improve the process/experience else the monsterboards will simply keep the position they got.

      If a wizard can write your code, you are not a developer but an assembly line worker. Granted there is a living to made at this, but please, don't call yourself a developer, you are a code monkey.

      It is amusing for me to see the developers that every problem they encounter, they say: Oh if only we used tech X, this would be easy... WAY to sell your talent kiddo. It is even more amazing to see when they get away with it. Companies running everything from PHP, Perl, Python, Ruby on Rails, ASP and god knows what else, in the same company and in one extreem case, the same site... I don't care how much you hate an individual language, more then one you need a BLOODY good reason, more then two and you are insane.

      But hey, keep looking for the magical language that no longer requires you to express yourself to achieve what you want. If people could write amazing code in assembly then why can't you make the language the project uses just work?

      Really, if you claimed that you would be a better driver if only you had a proper car, every real driver would laugh at you. Instant poloroids are used by the pro's. Some serious art is produced with nothing but paper and charcoal.

      But for a website, you need the latest tech so you can never learn all its secrets. Right.

      • by gbjbaanb (229885) on Friday February 25, 2011 @08:50AM (#35311052)

        absolutely.

        I think its partly due to the 'programmers' not being able to do a good job int he current tech they use, so they blame it and then start looking for the next one - which is also why a lot of people insist that a complete rewrite is the only way to go. .. every time.

        The flaw lies not in the "legacy" code, or the "outdated" technology but in the people involved.

        While I don't give a fig for those guys, new entrants to the IT workforce are picking up the meme that "you can only do good work in the latest tech" or by getting the framework/library/language/whatever to be easier and easier instead of learning the principles and being able to do things right.

      • by Alt_Cognito (462081) on Friday February 25, 2011 @08:55AM (#35311068)

        > Personally I also think frameworks are silly. If you can lash up a site in 30 minutes, then the request simply isn't distinctive enough.

        Let me first point out that I agree with most of what you say (which is essentially that the value of a programmer is in solving problems which have not already been solved), however:

        The entire point of a framework is to give you the underlying repetitive parts so you can focus on coding the complicated domain specific pieces later.

        Frameworks and libraries are everywhere. In fact, many people judge the quality of a language by the quality of the libraries they have.

      • Really, if you claimed that you would be a better driver if only you had a proper car, every real driver would laugh at you. Instant poloroids are used by the pro's. Some serious art is produced with nothing but paper and charcoal.

        It's interesting that you bring up cars, because we're not talking about driving a car, but building one. When an automaker builds a car, they don't reinvent the wheel unless there's something wrong with the old one. Parts like steering columns, any kind of electrical part, garnishes like door handles and map lights, and even glove box doors might be borrowed from another vehicle. Automakers clearly comprehend the value of a framework. Indeed, a single chassis design might be sold under several different names. For a while Buick only had a single chassis for like seven names, but now they're back up to four chassis. The Hummer H2 is an optioned-up Tahoe with a goofy, unaerodynamic body.

        The simple truth is that you can make one website look like a dozen different websites by doing nothing but theming. On Drupal the theme literally controls the placement of everything you see. The various elements are wrapped in HTML by the theme and styled with CSS like anyone else's site. In addition, Drupal is a not uncommon choice for the backend for sites with flash interfaces (which don't even have to look like a website) because of its strong XML support.

        If people could write amazing code in assembly then why can't you make the language the project uses just work?

        And for the same reason, it's interesting that you bring up assembler, since nobody is writing websites in assembler. They're all using a framework of some kind to build their website upon.

  • by BigSlowTarget (325940) on Thursday February 24, 2011 @07:31PM (#35307222) Journal

    And the article hits Slashdot just as they take down the Drupal servers for a 12 hour migration to Git. That's some good timing.

  • by MrEricSir (398214) on Thursday February 24, 2011 @07:32PM (#35307236) Homepage

    ...it's a way to seamlessly align the holistic design-process in an integrated, next-generation infrastructure using best practices and maximizing ROI.

    Going forward, frameworks are a paradigm shift in cost-effective and value-added solution development.

  • framework (Score:3, Interesting)

    by mattack2 (1165421) on Thursday February 24, 2011 @07:35PM (#35307256)

    What is a framework, anyway?"

    What are Frameworks?

    A framework is a hierarchical directory that encapsulates shared resources, such as a dynamic shared library, nib files, image files, localized strings, header files, and reference documentation in a single package. Multiple applications can use all of these resources simultaneously. The system loads them into memory as needed and shares the one copy of the resource among all applications whenever possible.

    http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WhatAreFrameworks.html [apple.com]

    I know that's not what you were really asking...

  • It's a long way (Score:4, Insightful)

    by TheModelEskimo (968202) on Thursday February 24, 2011 @07:38PM (#35307296)
    ...from the elephantine Drupal to a use-as-you-need-it framework like Zend. So, "use the right tool for the job" is a huge part of this. Personally I err on the side of "less is more" and look at my local Drupal community and see people who are picking a kitchen sink tool because they have limited time and resources. Not the sort of example I race to follow.

    My experience with another large CMS/CMF taught me that maintenance costs (which have to be passed on to clients) really start to add up quickly with the behemoth-sized packages, if you have a very active client. And if you're developing a small site with Drupal, and think of yourself as a moderately technical person, I sincerely ask you why you're not using something like Processwire instead. The last three people I saw do this did it because Drupal was "what they knew." That's uh...interesting. Why not just learn several tools that can fit into a more flexible toolchain? Drupal has one heck of a footprint!

    The summary mentions a GUI, so it's probably worth bringing up Django -- an otherwise all-code framework that comes with its own admin panel GUI already built.
    • by GMFTatsujin (239569) on Thursday February 24, 2011 @08:12PM (#35307620) Homepage

      I'm building a site on Drupal now exactly because it's what I know.

      What, should I use something I *don't* know?

      I know other webby develop-o-matic, framworkified tools too, and it's true that I'm not super-convinced that Drupal is exactly right for the job... but getting the job done well is more important to me that getting the job done perfectly, when the "perfect" solution is something I haven't even seen yet. Like, nebulously perfect. Perfect in a way I don't yet know... and have no time to snoop out and master the way I have already with Drupal.

      Having a big, flexible toolbox is good, but at some point you say, "Yeah, this'll the job" and get to it. Let me put to use what I've learned.

      (That being said, I just subcontracted a Drupal job from a designer whose client wants five pages on the site. FIVE CRAPPY PAGES. I just about tore my eyes out with rage.)

      • by Foofoobar (318279) on Thursday February 24, 2011 @10:27PM (#35308640)
        Better design helps with a more flexible codebase. Having to code around Drupal rather than just placing controller/model/view in their appropriate directories and allowing the container to manager plugins for ACLs/etc, can create a spaghetti coded nightmare in the longrun. Sure you can whip up code samples quickly but is it a longterm, maintainable and extensible code structure? No because it lacks structure. This is something that a framework provides.

        Go GROOVY/GRAILS [grails.org]!! (my plug)
    • by dylan_- (1661) on Friday February 25, 2011 @07:58AM (#35310864) Homepage

      And if you're developing a small site with Drupal, and think of yourself as a moderately technical person, I sincerely ask you why you're not using something like Processwire instead.

      Well, I do think of myself as moderately technical, and there are two reasons:

      • We're doing another, larger site which Drupal is perfect for
      • I hadn't heard of it

      So, thanks! I'll check it out. Might be very useful.

  • by jc42 (318812) on Thursday February 24, 2011 @07:43PM (#35307338) Homepage Journal
    Easy. A framework is whatever my product has that yours (and my other competitors') doesn't.

    Oh, and if our products have a similar feature, but you use different words to describe it than I do, yours is also disqualified.

  • by nilbog (732352) on Thursday February 24, 2011 @07:56PM (#35307452) Homepage Journal

    Here is the video, in case you can't reach his smoldering server: http://vimeo.com/20286577 [vimeo.com]

  • Drupal is a pain (Score:4, Insightful)

    by pacergh (882705) on Thursday February 24, 2011 @08:01PM (#35307514)

    You may be able to argue Drupal, or even Wordpress, are frameworks. Nevertheless, Drupal is a bear to work with, fickle, frustrating, and overly complex.

    Perhaps for complex websites it's worth it, but I don't make complex websites. I make simple ones. The few times I tried to use Drupal to do so they became far from simple.

    I'd rather code from scratch than use Drupal.

    • by QRDeNameland (873957) on Thursday February 24, 2011 @08:23PM (#35307718)
      Pain. Now there's a key term in any definition of 'framework', at least in my experience.
    • by Narcocide (102829) on Thursday February 24, 2011 @08:23PM (#35307722) Homepage

      You know you're right. I know you're right. The problem is that there are so many horribly inexperienced, disorganized, and utterly belligerently incompetent web programmers out there that they give the few of us who actually know our asses from a hole in the ground a bad name. The perception amongst the broader small and medium sized business community (a.k.a. 90% of all available clients) is that if you're not using a framework you can't possibly know what you're doing. They think there's no possible way someone could be experienced enough to make a secure, efficient, and stable website simple enough that it might cost less to build it from scratch and maintain it than the "equivalent" product created via an infinite amount of Joomla or Drupal customization.

      Though it seems like nobody who has only bought websites and never made one themselves has ever survived the financial damage of making this mistake the first time, so the myth persists because none of the clients out there know their asses from a hole in the ground either.

      • by ameoba (173803) on Friday February 25, 2011 @12:53AM (#35309404)

        They think there's no possible way someone could be experienced enough to make a secure, efficient, and stable website simple enough that it might cost less to build it from scratch and maintain it than the "equivalent" product created via an infinite amount of Joomla or Drupal customization.

        What they're more concerned about is whether the next guy to come down the pipe will be experienced enough to quickly pick up your code-base & make the needed changes effectively. If you use a standard framework, you're quickly, cheaply & easily replaceable.

        • by Narcocide (102829) on Friday February 25, 2011 @08:36AM (#35311012) Homepage

          While that's true in theory, my rough estimate based from first-hand experience is that only around 15% of the deployments of these "standard frameworks" stay standard enough for that to be true. The rest of the time the client expects the full customization capability of a site written from scratch along with this supposed "easily replaceable" coder. The code base tends to end up getting chopped all to hell and by the time they're done (IF they get done) it no longer shares enough in common with the official distribution to either benefit from future updates and compatibility with 3rd party contributed modules or to benefit from any time/cost saving that standardized, reusable code is supposed to afford.

    • by ducomputergeek (595742) on Friday February 25, 2011 @03:50AM (#35309996)

      Drupal's backend management was confusing for me to use let alone trying to teach most typical users. For large, complex sites, yeah, it's something to consider. But if I'm building a personal site or a small site I can get wordpress up and running well in under 15 minutes. Even less if the account has a control panel with auto installer.

      Everytime I've tried to use Drupal it seems like I spend just as much time figuring it out and performance tuning than I do actually creating content.

    • by Crouty (912387) on Friday February 25, 2011 @04:07AM (#35310040)
      I have build Drupal sites for the last 5 years and yes, Drupal can be frustrating. But Drupal still develops fast, Drupal has just released version 7 with many usability improvements over the previous ones. The problem is everyone of us has to specialize because the day does not have enough hours to become expert in three or more systems. And once you earned some experience with one or two systems you usually can achieve the desired results quickly and IMHO Drupal is among the faster ones, because of the tons of modules and documentation for it. Plus Drupal does not make you jump through countless XML configuration hoops like some other frameworks do. Oh, and "writing from scratch" is a sure way to insecure sites. As soon as you need user registration it is just not worth taking the risk of SQL injection or cross site scripting bugs. Which you will inevitably make.
    • by -noefordeg- (697342) on Friday February 25, 2011 @04:45AM (#35310170)

      My company creates web pages (read: web systems). We only save time not using Drupal as our framework, when we are creating some kind of static advertising page. Other than that, no time saved. This is especially true for sites which are going to "stay around for a while".

      So I agree with you. Simple web pages, no Drupal.
      To sum up what kind of web pages I would consider Drupal an overkill:

      A singel page with some text and/or images.

      If the page was to look like this, I would immediately reach out to Drupal:

      Anything else than the former.

      "Drupal is a bear to work with, fickle, frustrating, and overly complex"... People say the same thing about politics, the economy, and most other things they don't have a clue about how works. Maybe you should take the time to actually learn how Drupal works. Yes, it's hard to work with, if you do not understand the concept of hooks. Almost impossible actually.

      • by pacergh (882705) on Friday February 25, 2011 @08:28AM (#35310972)

        Maybe you should take the time to actually learn how Drupal works. Yes, it's hard to work with, if you do not understand the concept of hooks. Almost impossible actually.

        I've taken enough time to learn how Drupal works to know I don't want to work with Drupal.

        Wordpress works better for basic content management that clients can easily use without calling me all the time. Plus, it's more easily theme-able than Drupal is out of the box. Add to that the ease with which my clients can change themes or add plugins and Wordpress far outshines Drupal in basic content management. (And it appears to run better, too.)

        For custom content management I either find an already in place program or roll my own. For example, had to work on a website for an academic journal. I initially tried a few CMSes, including Drupal, but each offered significant complexity on my end AND the user end. No dice.

        Then I found the Open Journal Systems (OJS). Their solution worked for my specific task. It was a bit complex, but I wouldn't have had to write my own modules to do what I needed. Plus, it was more intuitive for my users. (Although it's user-workflow is still a bit clunky.)

        For other systems, such as basic customized contact management systems, I roll my own. The rise of frameworks utilizing the MVC principle is a blessing.

        It's long been a good maxim to separate the data from the code from the layout. MVC frameworks like Rails or Cake help do that up front instead of me having to design the separation myself. Drupal? Not so much.

        I'd say Drupal, in the broadest sense, could be called a framework. Nevertheless, I don't know why you would want to use it that way. The maintenance required for custom Drupal sites -- and I mean having to field calls from users fixing or modding modules, or adding new ones, or teaching them how to use existing things, on top of fixing problems and tuning it for resources -- is beyond what I want to provide. I'd rather Wordpress or Rails.

        And, more importantly, unlike most Drupal "developers" I know I'm not a "developer;" I'm a web designer who can hack away at stuff. If a client needs a developer I tell the client to get a real developer, or choose to use a more simple solution. TCO isn't something to be sneezed at, although it can be hard to educate clients on it.

        Finally, why is it so many Drupal people say something like:

        Maybe you should take the time to actually learn how Drupal works. Yes, it's hard to work with, if you do not understand the concept of hooks. Almost impossible actually.

        Really? Here's the skinny: Drupal is supposed to make development easier. Why the heck should I have to learn what amounts to a new bloody language to make Drupal "work," to access it's "full power." Heck, I'll just learn to access the full power of PHP (or learn an MVC framework like Rails) rather than spend "the time to actually learn Drupal;" time I could better spend getting projects done with the knowledge I have.

        Access for "the concept of hooks," really? It's not bloody rocket science, I could take the time to learn it, but once again why should I? If Drupal is going to make itself so bloody hard to use, why don't I just code from scratch?

        And don't give me that malarkey about security and avoiding cross-site scripting and avoiding SQL-injections. If you're spending the time to create a complex site that needs to take advantage of the solutions that lead to possible security problems like that then you'll also have the time to read up on best practices.

  • by JohnnyBGod (1088549) on Thursday February 24, 2011 @08:17PM (#35307666)

    Drupal developer is good at using the tool he helped build! News at 11!

  • Actually... (Score:3, Interesting)

    by dandaman32 (1056054) <<dan> <at> <enanocms.org>> on Thursday February 24, 2011 @08:54PM (#35307990)

    (This post contains shameless self promotion)

    I think GUI elements are an essential part of a web development framework nowadays. I maintain a small open source CMS called Enano [enanocms.org]. It's very basic, but during the course of its development I've written a ton of GUI building-blocks, among other frameworkey things, and documented the APIs for them so that plugins can use the same features. Regarding the GUI elements, I think consistent interfaces are an important part of any web application. Thus, what better way is there than to use a good, solid framework that, among its other jobs, takes care of some of the GUI design ugliness for you? Stuff like a standard way to present and validate forms, show message boxes, log in users, provide visual feedback for a process, etc.

    In my opinion, a framework should do more than just provide a bunch of random pick-and-choose APIs that you can use. It should take care of the boring details you don't want to have to rewrite for a web app, like user account management, sessions, user data, database abstraction, that kind of thing. That's why people are writing applications using software like Drupal and Enano: they want to write a web app that does what it needs to do without having to reinvent the wheel. I'm currently using Enano as the foundation for an e-commerce site (contracted project). Yeah, eating my own dog food, but shows that it can be easy to take something like Enano/Drupal/Wordpress and use its existing, established core features to write a whole new application that uses those features.

    Yes, I've used a more traditional framework before (CodeIgniter). It's great, and I love its design for basic applications, but you still have to write your own user management and a lot of other prerequisites to create something like an e-commerce site. In contrast, I've developed the entire e-commerce plugin with about 50-60 hours of work, including a couple of very minor modifications to the core.

    • by Shados (741919) on Thursday February 24, 2011 @09:08PM (#35308116)

      Totally agreed.

      If, in this day and age, you're making a website from scratch, you're doing it WRONG. Exception only for specialized web applications that try to do "thick client" stuff on the web (let say something like gmail).

      For normal public facing sites, or intranets, if you don't use a CMS, you'll have to replicate basic stuff for nothing. Sure, stuff like ASP.NET or PHP/Ruby/Python/Whatever frameworks will handle low level authentication, data access, navigation and whatsnot, but a CMS will give you a working web sites, with all that already in a working state, and you just need to add your styles, template, and business-specific logic and you're done.

      Being a .NET dev, I use Umbraco (the best one is SiteCore by a landslide, and not just if you're a .NET dev...its just impossibly expensive. Worth it if you can afford it though). It handles all the stuff thats common to all websites, and not an inch more. Then doing anything "from scratch" that would take a few hours or days takes a few minutes, and you're not stuck with precanned impossible to modify garbage like some other major CMS will force on you: everything is easy to modify.

      There's a million CMS out there in all flavors that offer all level of abstractions and specialization, depending on your requirement. Pick one, and stop wasting your time doing garbage from scratch.

      • by denmarkw00t (892627) on Friday February 25, 2011 @12:43AM (#35309364) Homepage Journal

        First I saw:

        you just need to add your styles, template, and business-specific logic and you're done.

        and then I saw this:

        Being a .NET dev

        Now, I've only used a couple PHP frameworks and only done anything with one particular CMS (don't even remember what it was). But when I think of a framework, I think of staying out of the way. Something like CodeIgnitor or Kohana (personal favorite right now). When I think of CMS I think biiiiiggggggg. That doesn't mean they don't have a place, but if you're goal is something complex in functionality and simple in design, then a framework is the perfect middleground between From Scratch and Too Big to Handle.

        If your approach to every project is "There's a CMS for that!" then you are probably doing it wrong.

        • by Shados (741919) on Friday February 25, 2011 @08:57AM (#35311074)

          My approach to every project is "use the right tool for the right job".

          For public facing websites, the right tool will almost always be a CMS.

          For the rest, it depends: for internal web app my personal favorite is usually a composite application framework. Unfortunately, unlike CMSs, there are very few of those, and the ones that do exist tend to be immature, so I had to write my own. Some internal web app projects are suitable for CMS too though.

          If when you think CMS you think "biiiiiiiiiiiiiiiiiiig", you haven't looked at the good ones (ok, aside SiteCore: that thing is a behemoth, but it IS really awesome, as I mentionned before =P)

  • by Dishwasha (125561) on Friday February 25, 2011 @12:20AM (#35309238)

    Am I the only one to notice he went over 30 minutes?

  • by jgoemat (565882) on Friday February 25, 2011 @02:37AM (#35309798)
    Yes, lets let Microsoft compete in a spreadsheet disign competition using Excel as a base against other "frameworks".
  • by lymond01 (314120) on Friday February 25, 2011 @02:51AM (#35309848)

    Framework: A bunch of organized and easily referenced functions which make development easier.

    CMS (Drupal, Plone, Etc): Fun for users. Hell for developers.

  • by kikito (971480) on Friday February 25, 2011 @04:45AM (#35310172) Homepage

    I thought it was pretty much agreed that you could not "run" a framework. Just "use" it to build something (a website, an app...) that then you run. Significatively, there's no "content" (understanding content as "the thing that the end users usually change and use").

    Drupal can run by itself, with no modifications (granted, the default installation will not let you do much, but you still can) so to me, it might be a framework plus something else - but definitively not "only" a framework.

    I don't know the Drupal internals well enough, but if it is well designed, it should be reasonably easy to separate the "Drupal Framework" (classes that can be used to build other things) from the "Drupal website" (the "default content" that Drupal starts with).

    • I don't know the Drupal internals well enough, but if it is well designed, it should be reasonably easy to separate the "Drupal Framework" (classes that can be used to build other things) from the "Drupal website" (the "default content" that Drupal starts with).

      Just to be clear, Drupal is highly modularized. The only modules you can't turn off are the core-required set. For 6.0 that looks like this:

      Block Controls the boxes that are displayed around the main content.
      Filter Handles the filtering of content in preparation for display.
      Node Allows content to be submitted to the site and displayed on pages.
      System Handles general site configuration for administrators.
      User Manages the user registration and login system.

      Then there's a whole other set of optional core modules:

      Comment Allows users to comment on and discuss published content.
      Contact Enables the use of both personal and site-wide contact forms.
      Content translation Allows content to be translated into different languages.
      Database logging Logs and records system events to the database.
      Forum Enables threaded discussions about general topics.
      Help Manages the display of online help.
      Locale Adds language handling functionality and enables the translation of the user interface to languages other than English.
      Menu Allows administrators to customize the site navigation menu.
      OpenID Allows users to log into your site using OpenID.
      Path Allows users to rename URLs.
      PHP filter Allows embedded PHP code/snippets to be evaluated.
      Ping Alerts other sites when your site has been updated.
      Poll Allows your site to capture votes on different topics in the form of multiple choice questions.
      Profile Supports configurable user profiles.
      Search Enables site-wide keyword searching.
      Statistics Logs access statistics for your site.
      Syslog Logs and records system events to syslog.
      Taxonomy Enables the categorization of content.
      equired by: Forum (disabled), Image Gallery (enabled), Catalog (enabled)
      Throttle Handles the auto-throttling mechanism, to control site congestion.
      Tracker Enables tracking of recent posts for users.
      Trigger Enables actions to be fired on certain system events, such as when new content is created.
      Update status Checks the status of available updates for Drupal and your installed modules and themes.
      Upload Allows users to upload and attach files to content.

      So this is the set of functionality you know will work properly across all supported databases without adding any modules.

      Note that all this applies to Drupal 6. Drupal 7 as a framework is fine but if you depend on contrib modules then it is NOT READY. Further, most contrib modules are not database-independent at this point. I'd wait until at least 7.1 before I started using D7. D7 has a whole new system for database independence and most modules are still developing their own queries manually in a database-specific fashion.

      • by kikito (971480) on Friday February 25, 2011 @06:59PM (#35317936) Homepage

        Thanks a lot for your reply. I specially appreciated the bit at the end about D7. I guess I'll wait.

        Most of the modules you describe, I've already used. I just don't know the code inside them.

        "Download, uncompress on sites/all/modules, activate, if it doesn't explode, configure" that's my general approach with modules. It rarely includes a "have a peek at the code". But thanks.

        I hope you didn't type all the descriptions of each module and just copy-pasted from somewhere else. Otherwise, what a lot or work!

        • by drinkypoo (153816) <martin.espinoza@gmail.com> on Saturday February 26, 2011 @08:19AM (#35322844) Homepage Journal

          Thanks a lot for your reply. I specially appreciated the bit at the end about D7. I guess I'll wait.

          I tried it, and I would wait :)

          Most of the modules you describe, I've already used. I just don't know the code inside them.

          Me neither, they're in core. I only look at their code when the docs suck and I need to understand what the code is expecting me to do. I'm not much of a PHP guy but it's one of a whole horde of languages with similar syntax so I can muddle through. In fact I'm not much of a programmer in general. I have contributed back patches to drupal modules which were accepted though, both features and fixes. Not sure if that's scary or if I'm smarter than I think.

          I hope you didn't type all the descriptions of each module and just copy-pasted from somewhere else. Otherwise, what a lot or work!

          Copypasted from admin/build/modules

  • This is the second straight article about drupal, in no longer than a day. third in this month.

    What's in store for tomorrow ? "Drupal is excited for carnival" ?

    has slashdot became drupal's private publishing arm ?

Time-sharing is the junk-mail part of the computer business. -- H.R.J. Grosch (attributed)

Working...