Is Drupal right for you?

Drupal is a highly configurable, modular content management system. Before you can answer if Drupal is right for you, consider a couple of questions: Which type of Drupal user are you, and what are your needs?

Below is a list of common user types followed by Drupal features. If the features meet your needs and you have the skill-set required to implement them, Drupal might be a perfect system for you. (See the list at the bottom of this page for more on required skills.)

I'm a Blogger and I need...

* single- and/or multi-user blogs
* to categorize content
* commenting
* trackbacks
* custom style and layout using sample or custom themes
* image and/or other media support using contributed modules (i.e., plug-ins)

Skills needed: end-user, administrator

I'm evaluating Drupal for my organization/company and we need...

* customizable user roles and permissions
* robust security model
* scalability
* to configure and extend functionality to meet specific business needs
* a support infrastructure (documentation, community, etc.)
* to categorize content
* additional features/functionality

Skills needed: evaluator, end-user

I'm a community organizer and I need...

* community members to easily share ideas (blogs, forum, files, etc.)
* members to have tools to help them self-organize
* a site that can evolve as the community evolves (keeping up with the state-of-the-art of interactive web sites)
* a support infrastructure (documentation, community, etc.)
* customizable user roles and permissions
* a site that is safe on the web (security, spam, trolls, etc.)
* a special distribution of Drupal and contributed modules that come preconfigured with community relationship management tools like CivicSpace.

Skills needed: evaluator, end-user, administrator, site developer (to some extent)

I'm a small business owner and I need...

* to set up the site myself
* custom style and layout using sample/custom themes
* customizable user roles and permissions
* a system that is scalable and adaptable to the needs of my changing business
* to categorize content
* a support infrastructure (documentation, community, etc.)
* e-commerce support for
o shopping carts
o premium paid content subscriptions
* to configure and extend functionality to meet specific business needs

Skills needed: evaluator, end-user, administrator, site developer (to a limited extent)

I build or design websites for clients and I need...

* to create a custom look and feel with my own themes
* additional features/functionality
* to easily provide support to my clients
* access to a community of designers and developers

Skills needed: evaluator, administrator, site developer, developer (to some extent)

I'm a programmer and I need...

* a robust, well-designed, modular system that I can customize and extend
* well documented APIs
* system and architecture documentation and coding standards
* access to a community of other developers
* a rich feature list

Skills needed: administrator, programmer

Do you know what type of Drupal user you want to be? If you do, review the skill sets below to see what you'll need to get started:

* Evaluator: Familiar with web terminology and concepts.
* End-user: familiar with browsing, clicking, submitting web pages, selecting options.
* Administrator: Manage roles, select themes, categorize web pages (content), configure module settings, install and upgrade software and databases, apply security fixes.
* Site designer/developer: Install software, design style and layout (with css and minimal php), build and deploy websites, evaluate contributed modules, work with LAMP.
* Programmer: program in php, administer databases, program through a well-defined API, design database objects, evaluating existing solutions and apply patches, collaborate with other developers

Now is a good time to learn more about Drupal. The Case studies section examines typical types of sites that use Drupal and gives links to real sites of each type. This section includes a listing of hundreds of Drupal sites.

All Drupal handbook pages are © copyright 2000-2006 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike2.0. Read more...

Drupal VS. Mambo 1

Originally written for Xaneon Development by Arto Bendiken Now, when making any comparison such as this, the first thing to realize is that it’s unlikely that one tool will fit every need and purpose. To an extent, comparing Mambo and Drupal is comparing apples to oranges. They are two very different systems, with widely differing goals and intended audiences. They just both happen to fit under the convenient heading of “content management systems”, meaning you can create decent websites with either one of them. Also, the people on our team probably don’t represent the broad cross-section of Mambo users out there; our needs don’t necessarily fit their needs. We are. for the most part, people with strong technical backgrounds. Some of our reasons for abandoning Mambo may not resonate at all with the “average user”, if there is such a person. Unless you are a programmer, or have an equally deep technical understanding, take everything we say with a grain of salt. Let’s start off with some background: we’ve used Mambo for a long time, and we’ve written a multitude of components, modules and mambots for various versions of Mambo, as well as contributed patches and improvements to existing Mambo add-ons. Most of our own projects were coded for internal purposes or limited distribution only, but some, like our popular XE2 component, which provided Search Engine Friendly (SEF) URLs for Mambo, were released to the Mambo community under open-source terms. It was only recently, in the last few months, that we “became aware” of Drupal and overcame the initial threshold of trying it out. Funnily enough, this was mostly to steal some good ideas from their SEF implementation; instead, Drupal ended stealing us away from Mambo. So it goes sometimes. Read on for what caused us to abandon all the time and effort we had invested into the Mambo platform… Drupal VS. Mambo 2

Drupal VS. Mambo 2

General Comparison Mambo has, for a long time, been ahead of competing CMS projects with regards to marketing. Mambo’s public image is pretty, appealing and very marketable to management. Mambo has no doubt benefited from the sponsoring company and trademark owner Miro’s advertising dollars in this regard. Of course, this was all before the recent hostile project takeover by Miro; while there are people who will argue that any publicity is good publicity, we’ll just have to sit and see how this particular move will play out. Drupal, in contrast, has been a community project from the start. There’s been no single strong corporate sponsor (though that’s changing with entities such as CivicSpace throwing their weight behind the project) to hold sway over the project, and the overall image has been somewhat less glitzy and more downplayed. Where Mambo Shines Mambo is certainly “easy on the eyes”: most people react very favorably to seeing the administration interface for the first time. Another aspect where Mambo is definitely ahead of the game is in installation friendliness, as well as add-on management (installation and uninstallation of components, modules, etc.) In comparison, Drupal requires one to manually unzip add-ons on the server, possibly create the necessary SQL tables from supplied scripts, and there is no friendly installation “wizard” to guide you through first-time installation. (This is all evolving, though; it shouldn’t be many months before there is a comprehensive installation system available in Drupal.) If the above points are very important considerations to you, as they certainly might be to less technically-savvy users, then you may not really benefit from this article. As stated, our team hails from a quite different user segment. Drupal VS. Mambo 3

Drupal VS. Mambo 3

Technical & Architectural Differences Now we come to the real meat of the matter. During our sojourn into the dark art known as Mambo SEF, we’ve necessarily become quite familiar with the internal workings of Mambo. To be candidly honest, it’s not exactly impressive. Mambo is a very limiting design. Pretty much the only “hook” into Mambo’s core, to allow any significant third-party extension to Mambo’s base functionality without modifying the core files, is the SEF support. (A cynical person might argue that even this “hook” exists only for the benefit of a certain commercial SEF extension developed by a former core developer.) When we originally designed Xaneon Extensions for Mambo, the most interesting aspect for us was to provide a general “core extension” framework which would allow multiple components to utilize XE2 to tap into the core without disturbing the SEF support or interface. Essentially, a “multiplexing” of the one and only core hook, for the benefit of all. XE2’s own code is very extensible, allowing other developers or site administrators to override functionality as they need to. Hopefully someone else will take this idea, or even our code, and run with it. Drupal’s architecture, in comparison to Mambo’s, is like a breath of fresh air. First off, reading through the core code was a pleasant experience: it’s not only cleanly designed, and with extensibility constantly in mind; it’s also well commented and documented. The design is incredibly flexible from the view point of an add-on developer coming from Mambo: there is no need for separate “components”, “modules” and “mambots”, as one Drupal module can perform the tasks of each, and much more besides. There is a general-purpose, all-pervasive “hook” system in place, allowing modules to override functionality in the entire lifecycle of content objects (known as “nodes” in Drupal), as well as perform actions at certain points in the handling of page requests. Application Programming Interface In Drupal there is actually an API for modules to use; this is a very important point. One reason for the inconsistent quality of Mambo components, and the proliferation of non-standard user interfaces, is no doubt that there are no standards, or at least no significant high-level programming interface that would facilitate the creation of third-party add-ons. Essentially, to create a Mambo add-on, one needs to start from scratch and reinvent the wheel every time. It gets frustrating after a while, even though the developer may learn to refactor and reuse some of his code. Drupal VS. Mambo 4

Drupal VS. Mambo 4

Nowhere are the above-mentioned design considerations more visible than in two add-on features we consider absolutely essential for both Mambo and Drupal: internationalization (i18n) and search engine friendly (SEF) URL addresses. Both require fairly low-level “hooks” into core functionality to function. Internationalization There is i18n support available in both systems, but in both Mambo and Drupal some patches are required to the core; this in our opinion is inexcusable, in both cases. Only unilingual users and websites would not need i18n, and those kind of websites are a luxury on the European side of the Big Pond, at least. However, compare the patching required, and how the add-on is implemented in each case: that is, in Mambelfish versus Drupal’s i18n module. In such a comparison, Drupal’s clean design shines through very favorably: the i18n module is much less of a “dirty hack” than what’s required for Mambo, and builds upon the superb localization feature of Drupal. In fact, Drupal’s i18n patch is only about two dozen one-line code additions, and would be trivial to integrate into the Drupal core in a future release, should Drupal’s project leadership decide to do so. More so, now having lots of practical experience building multilingual sites with both Mambo and Drupal, Drupal’s i18n works very well and as it is intended to, and feels fully integrated into the system, not “hackish” in any way. This is not, however, intended to knock down the developer of Mambelfish; having reviewed the code and contributed patches to Mambelfish, we think he’s done pretty much the best job that’s possible in the constraints Mambo’s architecture places on him, and should rather be commended for his ingenuity in providing an adequate solution to a difficult problem. Drupal VS. Mambo 5

Drupal VS. Mambo 5

Search Engine Friendly URLs This is a subject that has become intimately familiar to us. One of our earliest requirements for a CMS was adequate support for free-form, human-readable URLs. At the time we started to use Mambo, there really wasn’t any solution to this aside from some hacks shared in the Mambo forum, and a commercial SEF add-on for Mambo developed by one of the core developers. To solve the problem, we wrote Xaneon Alias Manager 1.0, which allowed us to define friendly URLs manually for all of Mambo’s content pages. While it worked quite well, and hundreds of websites are still using XAM today, it was a labor-intensive solution for larger sites. Eventually, out of dissatisfaction with having to maintain the friendly URLs manually grew Xaneon Extensions 2.0 (XE2) for Mambo, which introduced automated friendly URLs for both content items and component-generated paths. Unfortunately, while achieving a good measure of automation, the component’s complexity skyrocketed. Mambo itself is simply not designed for friendly URLs, and what’s worse, most of the third-party components for Mambo don’t take any measures to even try to support friendly URLs. As a result, writing a “perfect” SEF solution for Mambo is an incredibly labor-intensive task. We welcome anyone to try it as a Sunday-afternoon exercise… Over the last year, many people have privately expressed their concerns to us about the fact that a Mambo core developer is charging for a SEF component that should, in their view, be integrated in Mambo’s core. From our own “inside perspective”, we can, on one hand, understand this developer charging for his component, since we know the work involved in developing a comprehensive Mambo SEF solution. (Come to think of it, charging for ours might have motivated us to actually finish it.) On the other hand, we must agree that Mambo should come with significantly better SEF support out-of-the-box, and that the current situation is curious, to say the least. We do believe the (former) core team to be in serious error on this matter. Fortunately, the situation with Drupal is much better. SEF support, on a level comparable to our Alias Manager component, is fully integrated into the Drupal core, and there is an open-source add-on available which adds automated friendly URLs in a manner comparable to XE2. There are a few small convenience features we are considering implementing and contributing, but already Drupal’s SEF support is more integrated and usable than we could ever achieve in Mambo without patches to the core. It simply works as intended, and the code and solution is elegant. Drupal VS. Mambo 6

Drupal VS. Mambo 6

Multiple Sites with One Installation Imagine if you could set up several sites with just one installation; all installed add-ons and themes would be instantly available for use in all these sites, and any security patches you need to apply (after all, all software has bugs, as we know all too well), need only be applied once. And, to make it all even sweeter, imagine if you selectively share the configuration settings and databases tables between these sites so that, for instance, you could share user accounts between some sites, or maintain only one large content archive, selectively using and sharing articles between your sites. Wouldn’t this be great? Guess what. Drupal does all of the above, and it works perfectly. It’s not too bad to set up, and once done, saves a bunch of time and effort. We figured out a way to do most of the above in Mambo as well, since XE2 has some access to the relevant PHP variables before handing control over to Mambo’s core. The multi-site support in current beta versions of XE2 is buggy, but the concept should be sound. It would take a lot of work to bring it up to Drupal’s current level, though. Fine-Grained Access Control As far as access controls go, this is simply a no-contest. We all know how lacking Mambo’s access control scheme is; hopefully there will one day be an improvement to it. Drupal allows us to define arbitary roles (for instance, “moderator”) for users, and assign permissions to these roles on a module-by-module basis (for example, one selection is “moderate comments”). It’s intuitive, very fine-grained and very flexible. There is even a module available that will automatically handle giving a user a new role after they’ve paid for a subscription with PayPal, as well as many other add-ons that allow true micromanagement of the website’s access control policies, should that be necessary. Drupal VS. Mambo 7

Drupal VS. Mambo 7

Other Considerations Let’s just say the list of goodies Drupal delivers us is pretty long. We haven’t even discussed Drupal’s templating system (keywords: XHTML, CSS, total customizability, and optionally, Smarty) or the unlimited content hierarchies you can create with the built-in Drupal module called, appropriately enough, “taxonomy”. We could go on for two dozen pages. It wouldn’t be difficult at all. But we don’t need to convince anyone, and our reasons aren’t necessarily reasons why someone else would switch. It would be silly to get religious about something like a content management system. As always, just pick the right tool for the job at hand. For us, that has for now in most cases proven to be Drupal. In Conclusion The bottom line is simply that Drupal allows us to be significantly more productive. In our experience, we are able to put together complex sites in a fraction of the time it would have taken us with Mambo. We can use Drupal modules such as Flexinode, which brings to mind some of the power of Lotus Notes, to quickly solve needs that would have cost us a lot of custom programming (or buying a custom component) in Mambo. We can take advantage of Drupal’s excellent templating to produce truly unique-looking sites with not much effort. This site, xaneon.com, is at the moment still a Mambo installation, running our Xaneon Extensions for Mambo. It’s the last bastion of the old, standing against the coming wave of change. It’s unlikely to hold out much longer, though… We don’t regret the time we spent with Mambo; we will always have a soft spot for it and appreciate the many friends and acquaintances we made along the way. We sympatize with the current plight of the “true” Mambo core development team and wish them the best of fortunes in their new endeavour. As we’ve stated previously, we might pop in at Open Source Matters from time to time to catch up on how the “rebel Mambo” project is doing. Goodbye, and thanks for all the fish!

Migrating from Joomla or Mambo

This guideline focus to migrate Joomla! 1.0.x to Drupal 4.7.x. Before you do migration you must understand some differences between both to make sure your migration to be successful:
Joomla! vs Drupal

1. Joomla only supports single Section/Category, while you can set same Drupal article has several Sections/Categories.

2. Joomla does not support Community Site, so the migration must be put into certain site if you already set a multi site for Drupal.

3. In this guide I assume you have a forum in your Joomla site. Drupal has built-in Forum Discussion then you don't need to install additional module

4. Blogging. Blog term in Joomla is not same as blog in Internet dictionary. 'Blog' term in Joomla is a list containing: Title, Introduction and Read More link. So, in short, 'Blog' in Joomla term is not 'Weblog'! If one asking if Joomla support Blog by default then the answer is yes, but in Joomla term of 'Blog'.

And you may ask: "I see that Joomla official site supports Blogging! Look at http://dev.joomla.org, am I missing something?" No, you're not miss read! Joomla uses bridge to include Wordpress in Joomla site.

5. Commenting is not available on Joomla by default but Drupal support comment by default.

Joomla vs Drupal Terminology

There are some different term between Joomla and Drupal. Here I listed to give you quick understanding:

1. Template in Joomla is called as Theme.
2. Component = Module.
3. Module = Block.
4. Mambot/Plugin = ? ( I don't know yet!!! )
5. Menu-Horizontal = Primary Links
6. Menu-Vertical = Navigation
7. Dynamic Article/Content= Story
8. Static Content = Page
9. Back-end = there are no back-end in Drupal!
10. SEF/SEO = Clean URL but some docs refer to SEF or SEO too.
11. Section = Category
13. Section Title = Vocabulary Name
12. Category = Sub-category or Term
14. Introtext = Teaser
15. Maintext = Body
16. Pathway = Breadcrumbs

Others parts are same, such as: forum discussion, editor, search, region, comment, subject/title, preview, html tag, view, edit, advertising/banner, log in/log out, profile, avatar, access control, logs, cache, site maintenance, RSS feed, parent-child and snippets.
Migrating Joomla Content/Items

First, you must transfer all Joomla-Sections to Drupal-Categories and transfer Joomla-Categories to Drupal-Term according to their parent. After that, you can transfer Joomla content/item from jos_content table. Drupal table for saving article is drupal.node_revisions. I am using SQLyog (www.sqlyog.com) to Export-Import these tables.
Migrating Joomla Introtext

Introtext vs Teaser, this is very important, you must know that Drupal can automatic cut the beginner of an article to introtext. The introtext is called as teaser in Drupal. Now, how to convert Joomla introtext to Drupal? You have 2 options to solve this problem:

* Automatic Teaser
Just use content=introtext+maintext and save to this Drupal table: drupal.node_revisions:teaser. After the automatic teaser created you still can changing this teaser manually using Drupal tag:

* Manually Teaser
Copy jos_content:introtext to drupal.node_revisions:teaser and jos_content:fulltext to drupal.node_revisions:body

Migrating Joomla Forum

I assume you use Joomlaboard forum for Joomla. In Drupal, forum is built-in, then you only need enable it on administer-module then show it on certain front page section using administer-blocks. You must transfer Parent-Forum Category of Joomlaboard to Drupal-Forum Container and Child-Forum Category to Drupal-Forum Category. Again, I am using SQLyog to transfer the entire forum contents, SQLyog is very easy because its GUI.
Editor

Drupal by default has no WYSIWYG Editor, mean you must type any HTML tag manually to format you article. Joomla has built-in TinyMCE editor. In Drupal, you can use users contributed modules such as TinyMCE Editor or FCKeditor. TinyMCE is light editor. FCKeditor editor support server side, mean you can browse the server to insert or upload something including files, images and flash file. Also, Fckeditor can create folder on the server.
Tips

Usually better to install Drupal in a folder such as domainname.com/drupal, so you can still access both website during this migrating. You better not convert the Joomla templates to Drupal Theme, but edit any existing Drupal theme to meet your requirement because Drupal supports theme engine (PHPtemplate) and separate templates such as comment.tpl.php, mean you can apply any format to the comment.

All Drupal handbook pages are © copyright 2000-2006 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike2.0. Read more...

Typical Drupal applications

By enabling and configuring individual modules, an administrator can design a unique site, one which can be used for a combination of knowledge management, web publishing and community interaction purposes. So that you can better understand the many possibilities, the following list of features have been organized by common web platform characteristics:

* Content management. Via a simple, browser-based interface, members can publish to a number of available content modules: stories, blogs, polls, images, forums, downloads, etc. Administrators can choose from multiple theme templates or create their own to give the site a singular look and feel. The flexible classification system allows hierarchical classifications, cross-indexing of posts and multiple category sets for most content types. Access to content is controlled through administrator-defined user permission roles. Site pages can display posts by module type or categorized content, with separate RSS feeds available for each display type. Users can also keyword search the entire site.

* Weblog. A single installation can be configured as an individual personal weblog site or multiple individual weblogs. Drupal supports the Blogger API, provides RSS feeds for each individual blog and can be set to ping weblog directories such as blo.gs and weblogs.com when new content is posted on the home page.

* Discussion-based community. A Drupal site can act as a Slashdot-like news site and/or make use of a traditional discussion forum. Comment boards, attached to most content types, make it simple for members to discuss new posts. Administrators can control whether content and comments are posted without approval, with administrator approval or through community moderation. With the built-in news aggregator, communities can subscribe to and then discuss content from other sites.

* Collaboration. Used for managing the construction of Drupal, the project module is suitable for supporting other open source software projects. The wiki-like collaborative book module includes versioning control, making it simple for a group to create, revise and maintain documentation or any other type of text.

All Drupal handbook pages are © copyright 2000-2006 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike2.0. Read more...