I have applied content revisions following notes from J Burns ~ who is a freelance web-developer and uses Drupal.
There have been a number of iterations on Drupal. My notes go back to Drupal6. Drupal 7 added a few new features (please see 1 ); and is the “current one”. Drupal8 breaks backwards compatibility, but has finally joined the >1980s by going OO and using namespaces. Drupal8 also supports HTML5 and mobile. Whilst I understand inertia on big projects, I find it hard to take lack of support for these things seriously.
There is a catalogue that lists Drupal sites 2, this is useful for looking at features for Drupal. A list of case studies 3. Seasonal fluff that showed up on my linkedin.
Drupal is a CMF, mostly targeted at non-programmers who need to achieve skilled professional tasks (Content librarian is skilled language-based role, which pure technology conversations will tend to ignore.). I have researched abit 4 5 6, Drupal caters for people who want to do “programming via the mouse” (I seek to avoid controversy, so am not using the standard term ). These are the type of people who think that security is optional, and don't know enough to do high performance.
As far as you don't want to write the entire CMS everytime you build anther site, that is quite sensible. If the framework did security and scalability see 7 8 ~ which would also make sense ~ then the weakness of the website builders isn't a problem.
Comparison to other CMS
There is a service to port your site between CMSs 9, although I don't know anyone using it.
Wordpress 10 is a more narrow CMS, mostly just for blogs. There is a bigger range of tools attached to wordpress, and certainly compared to Drupal6 its easier to manage. Wordpress is still seen as stronger for non-technical users. In Drupal7 they added a large administration module, so that weakness is gone. Drupal developers assert that as they can “snap modules together” Drupal is more flexible.
Historically another CMS was Movable type 11. This is written in Perl, and invented backtracks. It seems to have been mostly replaced with Wordpress. If you need to host an eCommerce site, an option is Magento 12. This is derived from ZF1 code, but has many eCommerce features. If you need a tool to do things like inventory management in addition to “shop” features; this is an established tool.
In 2012 my Facebook was flooded with repeated adverts for Wix. I'm not sure if they should be classified as a web hosting service, or as a CMS. They allow websites to be created by the less-technical, within the Wix framework. There are many other services, offering the same concept. As an artist or designer, I avoid them; conversely they are targeting people who like powerpoint.
Another PHP CMS is Joomla. Blogger 13 is for blogs, and is written in Python. It is a rentable service only, not an installed software. Compared to Drupal; Blogger has good mobile support, both for editing and reading sites ~ including via SMS. There are many further projects that I haven't mentioned. There are surveys attempting to gauge the operational userbase for each 14 15 16. The value derived from the common projects has been analysed for freelancer.com 17, although the author says he would like a better level of granularity. Many of the people requesting a freelancer don't mention the platform, but may or may not have received a Wordpress site anyway. These analysis all say that Wordpress is a dominant player, having about 60% of the CMS market. I guess there are many more blog or simple brochure sites than anything more complex. The first link states that over sixty percent of websites do not use a CMS. To narrow the market to just e-shops, Magento is a dominant player 18. The market trending articles state that the smaller projects are collapsing (presumably Wordpress gets another plugin each time).
Drupal 7 features
There are enough features to have a CMS inside Drupal core. They are summarised 19 20, but enable content and site management; plus individualisation, comments, taxonomy. As noted above the “standard edition” is v7, which is stated being TDD 21, unlike the earlier versions. This is released with the following 22: general updates, add RDF support, improved security model, improved UX items, and added alot of documentation. There are a few new things like a module named “Features” created for this release. There is a website purely for discussing UX in Drupal7 23 but at the point of writing this doesn't display pages.
One of the features added as third party modules into Drupal7 as panels 24 25. Their exact description is confusing; but they are preorganised content which can be added into sites with partial WYSIWYG editing. To create good ones requires editing source, which some people dislike ~ this is discussed on the Stanford University blog 26.
Another feature is “views” 27 28, which seem to be a DB rasterising library. They make big use of the word “custom” to indicate that you can write your website not theirs 29; these do require some skills in PHP and SQL.
In the move to Drupal 7, they updated to jQuery 1.4 (which now is a legacy edition), added jQuery-UI; and similarly updated a few other things. Whilst that edition of Drupal isn't new, being locked to a version of jQuery that old will make problems. Edit I have been told to look at 1, there is a solution. People using Drupal approach from an entirely different perspective to me. One of the sales things about moving to Drupal7 was the addition of drag and drop in the edit screens; so admin didn't need to learn what coordinates where. This is been applied in a relatively coherent fashion, and is probably saving people alot of time. Another sales feature is the availability of “features”. This is a confusing name, but a module to provide a UI to manage the deployment and config of modules 2. EDIT Drupal7 has version control, so editing is a controlled process 3 or 4.
There are videos on youtube which seems to be the preferred format for some developers. These make poor references, and are not keyword searchable so I have skipped them.
As a tool for non-technical people, there are many articles about Drupal performance. Whilst I don't doubt they are true, they are void if you have multiple degrees in IT, a decades experience, and not using Drupal. There are some consultants selling “Drupal performance”, for example 5 6 7. If you are running a non-technical business this may be the easiest solution to improve existing infrastructure.
A common thing for CMS is to cache aggressively everything that doesn't need realtime data. In practical terms you can cache the generic HTML in a sales catalogue, the CSS, the JS; only the current stock needs to be fresh. Similarly for news sites, only the stories change. A convenient summary is 8. The biggest thing seems to be “cache for anonymous users”, which would seem to exclude Drupal from being a good sales platform. Cache invalidation is a hard problem in IT, with respect to Drupal see 9. Drupal integrates with Varnish ~ my normal front side cache 10, 11, issues list 12. Drupal also caches its own config, which isn't going to change very often.
The preceding are references on improving performance, not how fast it was. The Drupal platform is used in some moderate scale sites (bearing in mind the author does talk with people organising adverts commercially, so doing 10^10 page impressions per month.) such as 13. Media current are proud to announce that they ported The Weather Channel to Drupal 14, but fail to supply a date. In 2010, and maybe still currently, all WarnerBros records sites used Drupal, the heavist use being MyChemicalRomance 15, source 16. This also lists the Drupal site itself as being in Drupal.
As a measure for performance inside the platform, there is a hook (but using it will prove to be a challenge, see text) 17. I generally favour performance monitoring outside the server, as a response time isn't just a function of the code (webserver buffering and delays, front side caches, DNS lookup delays, DB lookup delays, SSL negotiation, kernel delays, router delays). When doing code analysis (I probably wouldn't apply this to Drupal, as you can't re-architect), one needs a higher degree of granularity than which pages are slow.
As far as getting a role involving Drupal goes, architecture is what I was reading about. The other thousand words is just context. The basic idea behind have a strong framework for making content is a good idea; if Drupal 8 was more mature, then the fact that it is compatible with much of Symfony2 is a nice feature The older versions of Drupal do represent everything that I am not keen about for PHP.
By this far into a CMS, you have probably heard the word “hooks”. Drupal 7 and below are not OO frameworks (although there are a few objects for some things). Functionality is achieved by triggering the event that runs the registered hooks. Drupal users (i.e. web dev) are reminded about management problems from editing the core libraries; but may add another hook into the event with much less side effect. The hooks for Drupal 7 are listed 18. As Drupal is a common platform, other people have written some documentation 19 20. The hooks are implemented using a rigid function naming structure and the PHP API function_exists. This is quite fast for PHP to execute, although doesn't scale that well for a large number of modules.
The output of Drupal is skinnable (as with many CMS), and that is controlled by themes. Each module may define or utiltise its own or third party theme 21. The menu module controls the routing i.e. which module implements a given URL. As a walk through more than reference, this question 22 is worth reading. There is some notes targeted at OO people 23, for the non-OO codebase. As with every long-lived project, there is escalating complexity; and architects attempting to solve this effect 24. There are fairly few numerical performance results; but review 25.
For some things Drupal feels like a pre permanent-internet project. Major updates are done via tarball not git update 26. In terms of change management, this is brittle and not Agile. I suppose Vagrant and similar are really important if your technology background is manual cp and tar -zxf commands. They also mention patch, personally I would much rather use git than patch, as its got better reversion, and better controls. On the basis that earlier versions of Drupal had less test coverage; using patch is a very stressful solution.
As I am a software engineer, I don't start using a technology; unless I can test it. This text is avoiding Drupal8, which has proper unit tests, but is not considered useful for eCommerce yet. Drupal people are told repeatedly “do not hack core”, as the consequences will be hard to manage in the long term. The following text feels like Drupal occurred before my lecturers wrote their notes, so has older practices.
People do seem to realise that a big complex adaptable project may need unit tests ~ I quote “Since testing is still quite new in Drupal” 27, they are attempting improve quality. Testing in Drupal is complicated by the fact that there are many possible execution states 28, and so errors may not occur when you test. As Drupal is a large project, they have some process 29 30 (the first is recent, it references Drupal8 everywhere..)
In order to test new modules, they recommend using SimpleTest 31 (I previously favour PHPunit), which I have looked at. PHPunit has a better tool chain/ integration. There are various notes saying that BDD/ outside-in functional tests should be done with their normal process (and therefore Behat). For the content, people have created test modules which render the blocks or views 32 33 . I don't know if this can be integrated into a CI tool.