- Wordpress
- Drupal
- joomla
- Webservices
| HackerNews | Medium | Quora-QA | Stack-Overflow-QA | Awesome-gh | Online-Courses (lynda.com) | Official docs | |
|---|---|---|---|---|---|---|---|
| wordpress | wordpress | wordpress | wordpress | wordpress | wordpress | wordpress | wordpress |
| drupal | drupal | drupal | drupal | drupal | drupal | drupal | drupal |
| joomla | joomla | joomla | joomla | joomla | joomla | joomla | joomla |
In layman's terms, content Management Systems, or CMSs, are platforms that provide graphical interfaces for website management. This means that images, video, text, and even many elements of a website’s layout can be edited by users without the need for any coding or programming.
Broadly speaking, content management describes any system that allows people to more easily change and update content, especially on their websites. When the content (number of pages, images, etc.), and/or the number of contributors, grows large, a content management system (CMS) helps collect and create the content in ways that makes it easy to reuse.
-
A CMS allows a team of contributors to work on the same pages without conflicting (check-in/check-out and workflow control). It can schedule pages to appear and disappear at designated times, and archive the old pages with versioning and revision control.
-
Reuse of content means an item can be edited in one place and be published instantly in many places. But it also means that the different versions of the content can be formatted properly for multiple delivery channels, including the web (HTML and PDF), print, wireless handheld devices, and cell phones.
-
Smaller CMSs are for single web authors working one or a few websites. Enterprise CMSs may control hundreds of thousands of pages on hundreds of websites with many dozens of contributors. In between, there are Team CMSs for corporate departments and smaller organizations. News portal software (slash-alikes and the *nuke family) are a form of community CMS, as are weblog tools (usually for personal publishing) and Wikis (usually for teams of contributors).
-
Some CMSs edit whole web pages, others edit a content template for a page and individual content elements. Both kinds may have form-based text editing, source editing of the markup language, or WYSIWYG (what-you-see-is-what-you-get) visual editing. Smaller CMSs tend to be page-oriented and store HTML. Enterprise CMSs use content templates and usually store content elements as information chunks in XML. Some systems tag and store the information with RDF (Resource Description Framework) metadata for the Semantic Web.
First, let’s take a look at the history of content management systems to understand where they come from and what challenges they were designed to solve.
The first content management systems that were developed in the second half of the 1990’s simplified web development but still required a fairly high level of programming expertise and elbow grease. In the 90’s most websites were still being coded by hand – from the ground up, so to speak.
It became apparent during the early days of the web that website development could benefit from ‘platforms’ or ‘frameworks’ – in other words, development environments that would give sites a jump-start so that website coders had a foundation to work from. Just as modern PHP application frameworks help web developers not to “reinvent the wheel” by providing components to implement basic services, CMSs allowed faster development of message boards and basic HTML websites and obviated the need to develop websites entirely from scratch.
Some of the early CMSs such as b2/cafelog and Mambo (mentioned in the timeline above) became the basis for contemporary – and far more advanced – content management systems. Many others never survived their infancy.
While early CMS solutions assumed a fair knowledge of HTML coding and programming, CMSs turned over time (to varying degrees) towards visual-based web development. We’ll explore the origins of so-called “WYSIWYG” editors in the next section.
WYSIWYG, or “What You See Is What You Get” website building tools emerged around the World Wide Web’s sixth birthday, beginning to appear in 1996. “WYSIWYG” was originally used in reference to text editors that could display a ‘page’ on-screen that mimicked the actual paper copy that would come out of a printer. John Markoff of the NY Times (October 2007) suggests: “The first true WYSIWYG editor was a program written for the Alto [computer] called Bravo, created in 1974 by Charles Simonyi and Butler Lampson, which would ultimately lead to the development of Microsoft Word some years later.” Office productivity software offered WYSIWYG document creation as far back as the mid-70’s. WYSIWYG website creation emerged on the scene between 1996 and 1997, though it is arguable that capability of WYSIWYG website editors was seriously lacking even into the early 2000’s. Sites like Wix.com, launched in 2006 and offering cloud-based drag-and-drop website building, emerged a full decade after the first generation of WYSIWYG web development software.
Examples of early WYSIWYG web development tools are:
- Amaya – W3C’s project that was begun in 1996
- Dreamweaver – launched by Macromedia in 1997 and bought by Adobe in 2007
- GoLive – started by GoNet Communications in 1996 and acquired by Adobe in 1999
Each of the modern CMSs we are discussing offer WYSIWYG editing to some degree, though WordPress offers the easiest customizations for those who shy away from coding.
The question in our case is whether to use a ready made CMS or to create your own system using a framework. The right answer depends on the following:
- budget
- number of users you will have (long term performance concerns)
- further maintenance
- total number of details (bells and whistles) you want to provide on the site
- implementation with third party/custom APIs
- special/custom features that require high level of freedom (example: StackOverflow reward points and badgets)
- As this is a question most of us face pretty often, here are cons and pros of a ready made CMS vs a framework:
Ready made CMS
Pros
- faster start and development time if your project generally fits in what the CMS provides
- available modules and themes
- backed up by community, meaning that new features, bugfixes, support, tutorials etc. will be provided to you free of charge
- unified set of standards - it's easier to continue working on an existing CMS site than to take someone else's custom application (this is relative, but the point is that in a site that uses an existing CMS most of the things/setup will be familiar to you while in a custom app the previous developer had more freedom)
- security is something you do not need to worry that much as in a custom app
Cons
- if your requirements are very specific, you will need to override the default workflow of the system; in some cases this can be tricky and will make you spend more time than to write your own
- redundant code in modules/plugins
- performance - a ready made CMS will rarely be as fast as a custom made application
- not suitable for every large website (unless you fit in almost everything that the CMS provides)
- steep learning curve in some cases (Typo3, Drupal)
Custom application
Pros
- it's up to you to define the structure and the logic of the application
- app design is made especially for the project you are working on - so there is no redundant code
- freedom to do anything you want
Cons
- expensive - in most cases you/your client will need much more money for a custom app
- further maintenance will be harder
- changes and modifications of the structure can be very time consuming
- if you aren't using a CMF you will have to reinvent the wheel in some aspects
A content management framework (CMF) is a system that facilitates the use of reusable components or customized software for managing Web content. It shares aspects of a Web application framework and a content management system (CMS).
Below is a list of notable systems that claim to be CMFs.
| Name | Technologies |
|---|---|
| Apache Jackrabbit | Java |
| AxKit | Perl |
| Grand Central | MySQL and PHP 5 |
| Jakarta Slide | Java |
| Open Semantic Framework | Drupal, OWL, PHP, and RDF |
| Backpack for Laravel | MySQL, PHP 5.6+, PostgreSQL |
| RadPHP | MySQL, PHP 5.6+, PostgreSQL, and etc. |
| Strapi | Node.js, MongoDB, MySQL, PostgreSQL, and etc. |
List of all available CMS's
Lets explore most used CMS's wordpress, drupal, joomla in detail..
Before everything else, here is a quick overview of the three platforms (based on data by Internet Lives Stats):
| WordPress | Joomla | Drupal | |
|---|---|---|---|
| Cost | Free | Free | Free |
| Usage | 311,682 million | 26,474 million | 31,216 million |
| Free Themes | 4,000+ | 1,000+ | 2,000+ |
| Free Plugins | 45,000+ | 7,000+ | 34,000+ |
| Pros | Customizable, easy to use, tons of learning resources, excellent community & support | Easy to learn, great help portal, can be used for social networks, updates integrate seamlessly, more built-in options | More technically advanced, websites generally perform better, enterprise-level security |
| Cons | Needs code for major visual customizations, updates may cause issues with plugins | Modules are hard to maintain, middle-ground CMS (not as easy as WordPress, not as advanced as Drupal) | Users need basic knowledge of HTML, PHP, and other web development languages |
WordPress is considered to be the most suitable platform for beginners. Joomla, however, isn’t too far behind. It also has a smooth learning curve, a user-friendly interface, and modules that can make adding functionalities a breeze.
Whether you’re a new blogger or an experienced web designer, both systems are great options for you.
Without a doubt, WordPress is a lot easier to learn than Drupal. However, it is not nearly as powerful or as secure as Drupal. You don’t have to be an expert in coding to work with Drupal, but you still need a bit of experience to build something functional.
If you are new to blogging, then WordPress is the better choice for you. But if you’re experienced with HTML, then Drupal will give you better scalability.
Official links
Sites powered by WordPress
WordPress is undoubtedly the best content management system for someone who wants to set up and manage a website without having to type a single line of code. WordPress.com lets anyone set up a WordPress-powered site in minutes, even offering free hosting with a URL in the format of yoursitename.wordpress.com. Note: wordpress.com is not to be confused with wordpress.org, which hosts downloads of WordPress software, themes, and plugins for those who wish to set up a WordPress installation on their own server or web host.
From it’s humble beginnings as a simple blogging platform in 2003, WordPress has revolutionised the way websites are designed & built.
Statistics show that WordPress is the most popular CMS in the online world today. It powers 27.8% of all sites on the web; with about 50,000 new sites being created daily. However, just because it is the most popular CMS, doesn’t mean it’s the only option.
CMS usage and market shares of top 1 million sites based on stats published by BuildWith (source)
Recommended for: small and medium-sized companies, organizations, dedicated blogs
Difficulty level: no programming experience required! (but plenty of potential for experts as well!)
On 27th May 2003, creators Matt Mullenweg and Mike Little launched WordPress as a development of its predecessor b2/cafelog. B2/cafelog was a blogging platform which was written by Michel Valdrighi in PHP, for use with MySQL.
The adoption rate of WordPress rocketed in 2004 when version 1.2 was launched, featuring the ability for users to write their own plugins and share them with the blogging community.
A new theme system was launched in 2005 with version 1.5, and later that year version 2.0 included a new user interface for the admin area, allowing users more control over their sites and the ability to make changes more quickly.
In 2006 , the company founded by WordPress co-founder Mullenweg Automattic), applied to trademark WordPress and the WordPress logo. Version 2.5 was launched in 2008 with a new user interface designed by web design agency Happy Cog, followed by a usability study that led to version 2.7, which included a customisable UI.
In 2010, ownership of the WordPress trademark and logo was transferred from Automattic, the company founded by WordPress co-founder Matt Mullenweg, to the WordPress Foundation. This meant that WordPress was no longer dependent on one company and ensured it would continue to grow.
2010 also saw the launch of version 3.0 – a major update which included custom post types, a new default theme and MultiSite. Version 3.3, launched in 2011 made WordPress easier to use and more appealing to novices.
By 2013, WordPress was widely acknowledged as the world’s most popular content management system. A flurry of updates led to version 3.8, which brought WordPress a new mobile responsive user interface and more default themes.
As of February 2017, WordPress is used by 58.7% of all the websites whose content management system is known. This is 27.5% of the top 10 million websites
- Dashboard
- Posts
- All Posts
- Add New
- Screen Options
- Categories
- Tags
- Featured Image
- Publish
- Media
- Pages
- Comments
- Admin Bar
- View Site
- Add New Posts & Pages
- Edit Profile
- Logout
- Appearance
- Themes
- Widgets
- Menus
- Header
- Background
- Plugins
- Users
- Tools
- Import
- Export
- Categories & Tags Conversion
- Settings
- General
- Writing
- Reading
- Discussion
- Media
- Permalinks
Server Programming Language
- PHP 5.2.4 - Lowest supported WordPress version
- PHP 5.3
- PHP 5.4
- PHP 5.5
- PHP 5.6 - Lowest supported PHP version (Doh!)
- PHP 7.0
Web Server
- Apache
- Nginx
- LightSpeed
- IIS
- PHP itself
- (Other?)
MySQL/MariaDB Database
- Content Tables
wp_postswp_postmeta
- Taxonomy Tables
wp_termswp_term_taxonomywp_term_relationship
- Comment Tables
wp_commentswp_commentmeta
- Persistent Settings Table
wp_options
- Deprecated Table
wp_links
- Content Tables
WordPress Core
- PHP Code
- SQL Database
- Assets
- JS
- CSS
- Images
A Theme - (a WordPress-specific concept)
- One (1) at a time
- Provides "Look at Feel"
- May provide functionality (but the community frowns on it)
- HTML-centric
- Typically HTML in PHP, CSS + JS
Plugins - (a WordPress-specific concept)
- Provides "Provides Add-on Functionality"
- Sharing Icons
- Backup
- Caching
- eCommerce
- Search Engine Optimization
- Fields for Data entry of Post data
- Zero (0) or more
- Coding-centric
- Typically PHP + JS + Generated HTML+CSS + SQL
- Provides "Provides Add-on Functionality"
The following are the files and directories you will interact with most often when developing for WordPress:
/index.php
/.htacess
/wp-config.php
/wp-load.php
/wp-login.php
/wp-cron.php
/wp-settings.php
/wp-includes/
/wp-admin/
/wp-content
|-/themes
|-/plugins
|-/mu-plugins
|-/uploads
The entry point for any page/URL on a WordPress website except admin console pages.
Provides clean URLs if you are running Apache, and more advanced developers can use for other features.
Location of database login and passwords as well as some other configuration.
File to require() if you want to add a standalone .php URL to your website, e.g. http://example.com/test.php.
File that loads the admin console login page, e.g. http://example.com/wp-login.php.
File that runs any cron tasks defined by a plugin or the theme, e.g. http://example.com/wp-cron.php.
File that bootstraps WordPress. You will never run this directly. However, once you start debugging you will trace through this file repeatedly.
Directory containing "core" WordPress files used by both the admin console and the front end of the website.
Directory containing "core" WordPress files used only by the admin console (except for a few rare cases).
Directory where all site builder code goes. This is not exactly a well-named directory.
Directory where Themes are installed, including several themes installed along with WordPress core.
Each Themes will have it's own subdirectory.
Directory where Plugins are installed, including a few plugins installed along with WordPress core.
Each Plugin should have it's own subdirectory, though not every plugin will (including the example plugin hello.php which is a pet peeve for many WordPress developers!)
The plugins can be activated or deactivated by an administrator.
Directory where "Must-Use" Plugins are installed.
Fun Fact: The name "MU-Plugins" is a backronym; "MU" originally stood for "Multi-User" when WordPress had a separate multi-user version, which itself was improperly named! "WordPress Multi-User" was the functional precursor to WordPress' "Multi-Site" installation option in more recent versions.
Each MU-Plugin should have it's own subdirectory. These plugins will always be loaded and can only be _"deactivated"_by removing them.
Good candidates for MU-Plugins are plugins that the site cannot correctly operate without. For every custom WordPress site there should usually be at least one custom MU-Plugin you or your team will create.
WordPress does not load MU-Plugins automatically, you have to require() them. I frequently use a file named plugin-loader.php to include the required required() calls to load my MU-Plugins.
Note: This file name is not an official WordPress filename, this is just the name I standardized on for this need. But what this file does it something you will frequently need when building client projects.
Directory where photos and other files can be uploaded by the user. This directory should always be writable so if your theme or plugin code needs to save a file you should do so in this directory. Preferably in a sub-directory.
WordPress automatically generates year and month sub-directories for uploading files, unless it has been configured to work differently.
There are many options, some are better, some are easier, all have their tradeoffs.
- Bare Metal
- Directly install Apache, MySQL, PHP, etc. on Mac OS X
- Laravel Valet: Just PHP7 and MySQL)
- Packaged Sandboxes
- MAMP and MAMP Pro
- XAMPP
- Virtual Machines (Vagrant)
- Requires
- VirtualBox (free)
- VMWare
- Parallels
- Available Vagrant
- VVV
- Trellis
- VIP Quickstart
- Scotch Box
- Laravel Homestead
- WPLib Box
- Requires
- Containers (Docker)
- Mostly not ready for prime time (but almost)
- Hybrid
- PressMatic - $129
Official links
Popular Websites Powered by Drupal:
Experienced web developers attest that Drupal is the most powerful CMS. However, it is also the most difficult to use. Due to its flexibility, Drupal is the second most-used CMS in the world, but it is not a favorite amongst beginners.
Recommended for: business, government, education, civic engagement platforms
Difficulty level: some programming experience recommended
Originally written by Dries Buytaert as a message board, Drupal became an open source project in 2001. The name Drupal represents an English rendering of the Dutch word druppel, which means "drop" (as in a water droplet). The name came from the now-defunct Drop.org Web site, whose code slowly evolved into Drupal. Buytaert wanted to call the site "dorp" (Dutch for "village") for its community aspects, but mistyped it when checking the domain name and thought the error sounded better.
Interest in Drupal got a significant boost in 2003 when it helped build "DeanSpace" for Howard Dean, one of the candidates in the U.S. Democratic Party's primary campaign for the 2004 U.S. presidential election. DeanSpace used open-source sharing of Drupal to support a decentralized network of approximately 50 disparate, unofficial pro-Dean websites that allowed users to communicate directly with one another as well as with the campaign. After Dean ended his campaign, members of his Web team continued to pursue their interest in developing a Web platform that could aid political activism by launching CivicSpace Labs in July 2004, "...the first company with full-time employees that was developing and distributing Drupal technology." Other companies began to also specialize in Drupal development. By 2013 the Drupal Web site listed hundreds of vendors that offered Drupal-related services.
As of 2014 Drupal is developed by a community, and its popularity is growing rapidly. From July 2007 to June 2008 the Drupal.org site provided more than 1.4 million downloads of Drupal software, an increase of approximately 125% from the previous year.
As of January 2017 more than 1,180,000 sites use Drupal. These include hundreds of well-known organizations, including corporations, media and publishing companies, governments, non-profits, schools, and individuals. Drupal has won several Packt Open Source CMS Awards and won the Webware 100 [clarification needed] three times in a row.
On March 5, 2009 Buytaert announced a code freeze for Drupal 7 for September 1, 2009. Drupal 7 was released on January 5, 2011, with release parties in several countries. After that, maintenance on Drupal 5 stopped, with only Drupal 7 and Drupal 6 maintained. Drupal 7 series maintenance updates are released regularly.
On December 1, 2012, Drupal 8 started its feature completion. About three years later, on October 7, 2015 Drupal 8 first release candidate (rc1) was announced. Drupal 8 includes new features and improvements for both users and developers, including: a revamped user interface; WYSIWYG and in-place editing; improved mobile support; added and improved key contributed modules including Views, Date, and Entity Reference; introduced a new object-oriented backend leveraging Symfony components; revamped configuration management; and improved multilingual support. Drupal 8 rc1 is the collective work of over 3,200 core contributors.
Drupal 8.0.0 was released on November 19, 2015. A subsequent upgrade to it is also available in the form of Drupal 8.1.0 that brings numerous improvements, including CKEditor WYSIWYG enhancements, added APIs, an improved help page, and two new experimental modules. Experimental modules are meant for testing purposes, but are not yet fully supported.
Latest major releases
| Version | Release date |
|---|---|
| 8.4.2 | November 3, 2017 |
| 8.2.8 | April 19, 2017 |
| 7.56 | June 21, 2017 |
| 6.38 | February 24, 2016 |
| 5.23 | August 11, 2010 |
The architecture of Drupal contains the following layers
-
Users − These are the users on the Drupal community. The user sends a request to a server using Drupal CMS and web browsers, search engines, etc. acts like clients.
-
Administrator − Administrator can provide access permission to authorized users and will be able to block unauthorized access. Administrative account will be having all privileges for managing content and administering the site.
-
Drupal − Drupal is a free and open source Content Management System (CMS) that allows organizing, managing and publishing your content and is built on PHP based environments. Drupal CMS is very flexible and powerful and can be used for building large, complex sites. It is very easy to interact with other sites and technologies using Drupal CMS. Further, you will be able to handle complex forms and workflows.
-
PHP − Drupal uses PHP in order to work with an application which is created by a user. It takes the help of web server to fetch data from the database. PHP memory requirements depend on the modules which are used in your site. Drupal 6 requires at least 16MB, Drupal 7 requires 32MB and Drupal 8 requires 64MB.
-
Web Server − Web server is a server where the user interacts and processes requests via HTTP (Hyper Text Transfer Protocol) and serves files that form web pages to web users. The communication between the user and the server takes place using HTTP. You can use different types of web servers such as Apache, IIS, Nginx, Lighttpd, etc.
-
Database − Database stores the user information, content and other required data of the site. It is used to store the administrative information to manage the Drupal site. Drupal uses the database to extract the data and enables to store, modify and update the database.
more detailed architecture of Drupal7
The following detail the directories
- /core - All files required by Drupal's out-of-the-box usage (core), except for files that have an explicit reason to be included in the base (/) directory.
- /libraries - All third party external libraries leveraged by Drupal, such as a WYSIWYG editor. This folder is not included by core, but used with many contributed modules.
- /modules - The directory into which all custom (created by you) and contributed (created by community) modules go.
- Splitting this up into the sub-directories contrib and custom can make it easier to keep track of the modules. You can create subfolders for organization to match your development, storage, usage standards.
- /profile - All contributed and custom installation profiles.
- /themes - All contributed and custom themes and subthemes. Please note that subthemes do require the base theme to be installed here as well.
- sites/[domain OR default]/{modules,themes} - Site specific modules and themes can be moved into these directories to avoid them showing up on every site. Identical to Drupal 7.
- sites/[domain OR default]/files - The storage of site-specific files. This includes files uploaded by users (such as images) and site configuration (active and staged).
- /vendor - Backend external libraries that Drupal core depends on (examples being Symfony, Twig).
In addition, the folder structure in the /core directory has changed as well.
- /core/assets - Various external libraries used by core (includes jQuery, underscore, modernizer, etc.).
- /core/misc - Frontend code that Drupal core depends on.
- /core/includes - Base-level functionality that Drupal uses through other /core folders.
- /core/lib - Drupal core classes.
- /core/modules - Drupal's core modules.
- /core/profiles - Drupal's core installation profiles. These are Minimal, Standard, Testing and Testing multilingual installation profiles.
- /core/scripts - Various command line interface (CLI) scripts, mostly used by developers.
- /core/tests - Drupal core tests.
- /core/themes - Drupal core themes.
Official links
Popular Websites Powered by Joomla:
Joomla is similar to WordPress in many ways. It is also easy to use, easy to install, and can easily be expanded with the help of modules – the equivalent of WordPress plugins. As a result, it is the second-best options for beginners.
Recommended for: companies, institutions, online communities, complex websites
Difficulty level: intermediate-advanced programming/ development experience recommended
At its core Joomla is designed for online communities, though as with Drupal and WordPress it can be used to do a whole lot more such as blogs and ecommerce. Joomla has a steeper learning curve than the other CMSs we have looked at so far. According to this article on Miracle Tutorials: “You really should get a good book on Joomla if you want to set it up fast. Otherwise you end up fiddling around and getting nowhere for days.” You definitely can’t make this statement about WordPress, and likely not about Drupal either!
Joomla! was the result of a fork of Mambo on August 17, 2005. At that time, the Mambo name was a trademark of Miro International Pvt. Ltd, who formed a non-profit foundation with the stated purpose of funding the project and protecting it from lawsuits. The Joomla development team claimed that many of the provisions of the foundation structure violated previous agreements made by the elected Mambo Steering Committee, lacked the necessary consultation with key stakeholders and included provisions that violated core open source values.
Joomla! developers created a website called OpenSourceMatters.org (OSM) to distribute information to the software community. Project leader Andrew Eddie wrote a letter that appeared on the announcements section of the public forum at mamboserver.com. Over one thousand people joined OpenSourceMatters.org within a day, most posting words of encouragement and support. The website received the Slashdot effect as a result. Miro CEO Peter Lamont responded publicly to the development team in an article titled "The Mambo Open Source Controversy — 20 Questions With Miro". This event created controversy within the free software community about the definition of open source. Forums of other open-source projects were active with postings about the actions of both sides.
In the two weeks following Eddie's announcement, teams were re-organized and the community continued to grow. Eben Moglen and the Software Freedom Law Center (SFLC) assisted the Joomla core team beginning in August 2005, as indicated by Moglen's blog entry from that date and a related OSM announcement. The SFLC continue to provide legal guidance to the Joomla! Project.
On August 18, Andrew Eddie called for community input to suggest a name for the project. The core team reserved the right for the final naming decision, and chose a name not suggested by the community. On September 22, the new name, Joomla!, was announced. It is the anglicised spelling of the Swahili word jumla, meaning all together or as a whole which also has a similar meaning in at least Amharic, Arabic and Urdu. On September 26, the development team called for logo submissions from the community and invited the community to vote on the logo; the team announced the community's decision on September 29. On October 2, brand guidelines, a brand manual, and a set of logo resources were published.
Joomla versions
| Version | Release date | Supported until |
|---|---|---|
| 1.0 | 2005-09-22September 22, 2005 | 2009-07-22July 22, 2009 |
| 1.5 (LTS) | 2008-01-22January 22, 2008 | 2012-12-01December 1, 2012 |
| 1.6 | 2011-01-10January 10, 2011 | 2011-08-19August 19, 2011 |
| 1.7 | 2011-07-19July 19, 2011 | 2012-02-24February 24, 2012 |
| 2.5 (LTS) | 2012-01-24January 24, 2012 | 2014-12-31December 31, 2014 |
| 3.0 | 2012-09-27September 27, 2012 | 2013-04-01April 2013 |
| 3.1 | 2013-04-24April 24, 2013 | 2013-10-01October 2013 |
| 3.2 | 2013-11-06November 6, 2013 | 2014-10-01October 2014 |
| 3.3 | 2014-04-30April 30, 2014 | 2015-02-01February 2015 |
| 3.4 | 2015-02-24February 24, 2015 | 2016-03-01March 2016 |
| 3.5 | 2016-03-21March 21, 2016 | 2016-07-01July 2016 |
| 3.6 | 2016-07-12July 12, 2016 | 2017-04-01April 2017 |
| 3.7 | 2017-04-25April 25, 2017 | 2017-09-01September 2017 |
| 3.8 | 2017-09-19September 19, 2017 | |
| 3.9 (LTS) | 2018-01-012018 | |
| 4.0 | 2018-01-012018 |
Joomla is written in PHP, it uses Object Oriented programming techniques and MVC design patterns, it uses MySQL to store data (MS SQL version 2.5 onwards, and PostgreSQL version 3.0 onwards). Various features which make Joomla a hit include page caching, blogs, polls, language internationalization support and RSS feeds.
Joomla makes use of MVC design pattern. When Joomla processes a request, it analyses the URL to determine which component will be responsible for processing the request, and hand over the control to that component. Then as per MVC, that component pass control to the controller.
-
The controller analyses the request and determines which model and view will be used to return the results back to the user. The model encapsulates the data used by component. The data can come from a database, it can be a Joomla database or any external database or can come via web service API running on external server.
-
The model is responsible for updating database and isolating the view and controller from the functioning about how data is amended or modeled. The view is responsible for generating the output which is then sent over to the browser by the component. Once the view has produced the output, the control is taken over by Joomla framework which then loads and executes the template. The template combines the output from various components and active modules and deliver it as a single page on browser.
Apart from this, Joomla splits the traditional MVC view into view and layout. The view pulls the data from the model and then sends the data to layout which can then formats the data and present it to the user.The split mechanism allows the template to be overridden in the template. These overridden layouts are bundled with the template and give complete control to designer over all the output and any installed third party extensions.
-
Core – The core of Joomla consists of php files which provides platform functionality required to make general work. There are also some configuration files and library files for e.g. Some of the files may call Javascript library etc. And lastly, there is a database which contains vital information about configuration files in Joomla and also the content which you put into Joomla.
-
Extensions – There are five types of extensions for Joomla viz.
-
Components – Components are the largest and most complex extensions of them all, they sometime referred to as mini applications. Mostly, they have 2 parts; a site part and an administrator part. Each time a Joomla page is loaded, one component is called to render the main page body.
-
Modules – These are light weight and flexible extensions used for page rendering. These are commonly called as “boxes” as these are arranged around a component
-
Plugins – More advanced extensions and are actually event handlers. In any execution scenario, whether it is core, a module or a component, an event is triggered. When this happens, the plugins registered with the application are executed. For example, a plugin can be used to filter out a bad word.
-
Templates – Templates are basically how your Joomla website looks. It is in essence the design of your Joomla powered website. It can be used to change the look and feel of your website. Components and modules are generally shown under the templates. Templates provide maximum flexibility in regards to how you style your website.
-
Languages – It is most basic extension. It can be packaged either as a core package or an extension package. These files contains key/value pairs, these pairs provide the translation of static text strings within the Joomla Source code. Language packs also include an XML meta file which describes the language
Joomla! CMS templates use a structure of directories and files but they can vary from template to template
- Site templates (templates that change what your website looks like) can be found in the
/templatesdirectory. For example, if your template is called "mytemplate", then it would be placed in the folder:
<path-to-Joomla!>/templates/mytemplate
- Administrator templates (templates that change what the administrator section of the site looks like) can be found in the
/administrator/templatesdirectory. For example, if your administrator template is called "myadmintemplate", then it would be placed in the folder:
<path-to-Joomla!>/administrator/templates/myadmintemplate
A typical template for Joomla! will include the following directories:
- css - contains all the .css files
- html - contains template override files for core output and module chrome
- images - contains all images used by the template
- language - contains additional language files used by the template
Depending on the complexity and design of the template is may also contain:
- javascript - contains supporting JavaScript used by the template for added functionality
Typical path of a template is <root>/public_html/domain-name/template/<name of your template> which will contain the following directories and files based on your template.
/css /html /images /javascript /language component.php error.php favicon.ico index.php templateDetails.xml template_preview.png template_thumbnail.png
This is my favourite topic, I spent my past 3 years working on more than 50 different types of web-services, interfaces and API's. This is most basic and essential for any dynamic web application to work.
Web Services make up a connection technology. It is a way to connect services together into a service-oriented architecture. Primary elements of Web Services are:
- Repository
- Messaging
- Service
Of course, there is more to Web Services. The articles listed below provide an indepth overview. They cover technologies that can be used in a service-oriented architecture.
List of webservice articles
I will try to cover some brief overview as this is neccessary to complete this article.
The term "Web Services" can be confusing. It is, unfortunately, often used in many different ways. Compounding this confusion is term "services" that has a different meaning than the term "Web Services." On this site, the term Web Services refers to the technologies that allow for making connections. Services are what you connect together using Web Services. A service is the endpoint of a connection. Also, a service has some type of underlying computer system that supports the connection offered. The combination of services—internal and external to an organization—make up a service-oriented architecture.
A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
-
Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification.
-
If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.
-
The technology of Web Services is the most likely connection technology of service-oriented architectures. The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider.
Lets have a detailed look at three specifications for Web Services SOAP, REST, and JSON.
SOAP was originally part of the specification that included the Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI). It is used now without WSDL and UDDI. Instead of the discovery process described in the History of the Web Services Specification section below, SOAP messages are hard-coded or genereated without the use of a repository. The interaction is illustrated in the figure below.More on SOAP.
Representation State Transfer (REST) appeals to developers because it has a simpler style that makes it easier to use than SOAP. It also less verbose so that less volume is sent when communicating. The interaction is illustrated in the figure below. More on REST.
While both SOAP and REST use XML for interchange, JavaScript Object Notation (JSON) uses a subset of JavaScript. This is illustrated in the figure below. More on JSON.
When to Use SOAP, REST, JSON or Other Options?
There really is no "best" option for Web Services. Generally, you will use whatever your service provider supports. If you use multiple service providers, it is easily possible that you will be using all three Web Services specifications: SOAP, REST, and JSON.
Web Services Description Language (WSDL); Universal Description and Discovery (UDDI); and SOAP formed the original Web Services specification. This section provides a history.
The Web Services Description Language (WSDL) forms the basis for the original Web Services specification. The following figure illustrates the use of WSDL. At the left is a service provider. At the right is a service consumer. The steps involved in providing and consuming a service are:
-
A service provider describes its service using WSDL. This definition is published to a repository of services. The repository could use Universal Description, Discovery, and Integration (UDDI). Other forms of directories could also be used.
-
A service consumer issues one or more queries to the repository to locate a service and determine how to communicate with that service.
-
Part of the WSDL provided by the service provider is passed to the service consumer. This tells the service consumer what the requests and responses are for the service provider.
-
The service consumer uses the WSDL to send a request to the service provider.
-
The service provider provides the expected response to the service consumer.
Wiki gives more details on DL's
The repository shown in the above figure could be a UDDI registry. The UDDI registry was intended to eventually serve as a means of "discovering" Web Services described using WSDL. The idea is that the UDDI registry can be searched in various ways to obtain contact information and the Web Services available for various organizations. How much "discovery" was ever used is open to discussion. Nevertheless, even without the discovery portion, the UDDI registry is a way to keep up-to-date on the Web Services your organization currently uses. It can be used at design time and with governance. An alternative to UDDI is the ebXML Registry.
All the messages shown in the above figure are sent using SOAP. (SOAP at one time stood for Simple Object Access Protocol. Now, the letters in the acronym have no particular meaning .) SOAP essentially provides the envelope for sending the Web Services messages. SOAP generally uses HTTP , but other means of connection may be used. HTTP is the familiar connection we all use for the Internet. In fact, it is the pervasiveness of HTTP connections that will help drive the adoption of Web Services.
The next figure provides more detail on the messages sent using Web Services. At the left of the figure is a fragment of the WSDL sent to the repository. It shows a CustomerInfoRequest that requires the customer's account to object information. Also shown is the CustomerInfoResponse that provides a series of items on customer including name, phone, and address items.
At the right of this figure is a fragment of the WSDL being sent to the service consumer. This is the same fragment sent to the repository by the service provider. The service consumer uses this WSDL to create the service request shown above the arrow connecting the service consumer to the service provider. Upon receiving the request, the service provider returns a message using the format described in the original WSDL. That message appears at the bottom of the figure.
XML is used to define messages. XML has a tagged message format. You can see this in the SOAP and REST examples in the first section and in the figure above. In each of the examples, the tag has the value of Burnsville. And is the ending tag indicating the end of the value of city. Both the service provider and service consumer use these tags. In fact, the service provider could send the data shown at the bottom of this figure in any order. The service consumer uses the tags and not the order of the data to get the data values.
W3 defines webservice framework as
The XML Protocol work is the foundation for a Web Service framework within which automated, decentralized services can be defined, deployed, manipulated and evolved in an automated fashion. The purpose of this document is to outline a framework for evolving XML Protocol’s functions. This framework provides a structure for integration and a foundation for protocols that will support the needs of such service-oriented applications. The goal is a scalable, layered architecture, one that can appropriately meet the needs of both simple and extremely robust high-volume deployments. As with other Web technologies, the focus is on enabling ubiquitous interconnectivity of entities and organizations dispersed throughout the world.
While most descriptions of Web based solutions emphasize their distributed characteristics, their decentralized nature – they have distinct management and control environments and communicate across trust domains – has much more impact on architecture of this framework and the requirements of the underlying protocols. So, we focus our framework first on supporting application-to-application integration between enterprises having disjoint management, infrastructure and trust domains.
more from w3 on webservices
A list all avaialbel web services frameworks
| Server-side |
|
||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Client-side |
|
||||||||||||
| Topics | |||||||||||||
Finally.. in brief.. all these layers below...
have made this complex world..
its worth spending some time on below table..
| History of computing |
|---|
| Hardware |
| Software |
| Computer science |
| Modern concepts |
| Timeline of computing |
|
|
and this is never gonna stop... with time.
