Examen: Kandidatexamen 180hp Handledare: Kristina von Hausswolff
Teknik och samhälle Datavetenskap
Examensarbete
15 högskolepoäng, grundnivå
Ruby and PHP Development: A Comparative study of
Development and Application using Content Management
Systems RefineryCMS and Concrete5
Ruby och PHP Utveckling: En jämförande studie av utveckling och applicering med content management systemen RefineryCMS och Concrete5
Abstract
With many options to choose from when designing and developing websites, it can be difficult for a beginner developer to know what to choose. This thesis compares how easy it is for a beginner to learn and use the two Content Management Systems (CMS)
Concrete5 and RefineryCMS to build a web application. Concrete5 uses PHP and RefineryCMS uses Ruby and the ease of learning the basics of these programming languages is also discussed.
To compare the two CMSs, different steps were documented and compared. The implementation was done on a MacBook Pro, OS X 10.9.2, late 2011 model. Relevant features were also compared according to the Authoring Tool Accessibility Guidelines 2.0.
The results showed a significant difference between the two CMSs, even though both had their benefits and drawbacks. In conclusion, Concrete5 was better for building a basic website under the writer’s conditions, thanks to the many features, modules, packages, plugins and templates available, and because it required less time and effort to install. This conclusion is limited to the writer’s conditions and it is possible that RefineryCMS could have worked better than found, if the conditions had been different.
Sammandrag
Med flera alternativ att välja mellan för att designa och utveckla webbsidor kan det vara svårt för en nybörjarutvecklare att veta vad man ska välja. Detta examensarbete jämför hur enkelt det är för en nybörjare att lära sig och använda de två Content Management Systemen (CMS) Concrete5 och RefineryCMS för att bygga en webbapplikation.
Concrete5 använder PHP och RefineryCMS använder Ruby och lättheten i att lära sig grunderna i dessa programmeringsspråk diskuteras också.
För att jämföra dessa två CMS, dokumenterades olika steg. Implementationen utfördes på en MacBook Pro, OS X 10.9.2, sen 2011 modell. Relevanta delar av funktionaliteten jämfördes även med hjälp av Authoring Tool Accessibility Guidelines 2.0.
Resultaten visade en signifikant skillnad mellan de två CMS:en, även om båda har sina för- och nackdelar. Sammanfattningsvis ansågs Concrete5 som det CMS:et med bättre aspekter för att bygga en enkel hemsida med de förutsättningar som fanns och tack vare de många funktioner det erbjöd användaren. RefineryCMS kanske kunde ha fungerat bättre om det var under andra förutsättningar, vilket inte kan dras som en slutsats i denna uppsats.
Acknowledgements
I would like to thank Kristina von Hausswolff for her help and guidance throughout this thesis. I would also like to thank Kibria Ali who participated as co-observer in the
Table of contents 1. INTRODUCTION ... 1 1.1. BACKGROUND ... 1 1.2. THE QUESTION ... 2 1.3. PURPOSE ... 2 1.4. LIMITATIONS ... 2 1.5. #GRATEFUL365 ... 3 2. THEORY ... 4 2.1. PHP ... 4
2.2. RUBY ON RAILS ... 4
2.3. MVC CYCLE ... 5
2.4. CONTENT MANAGEMENT SYSTEMS ... 6
3. PRIOR WORK ... 8
4. METHODS ... 9
4.1. CASE STUDIES ... 9
4.2. COMPARATIVE STUDIES ... 10
4.3. AUTHORING TOOL ACCESSIBILITY GUIDELINES 2.0 ... 11
4.4. METHODS DISCUSSION AND CREDIBILITY ... 11
5. RESULTS ... 12
5.1. DESIGN SPECIFICATION OF #GRATEFUL365 ... 12
5.2. IMPLEMENTATION OF #GRATEFUL365 ... 13
5.3. CASE 1 -‐ CONCRETE5 ... 13
5.4. CASE 2 -‐ REFINERYCMS ... 15
5.5. COMPARISON TABLE ... 18
6. DISCUSSION ... 22
7. CONCLUSION ... 23
List of figures
Figure 1: The MVC cycle ... 6
Figure 2: Concrete5 pre-‐content ... 14
Figure 3: Concrete5 editing and adding subpage ... 15
Figure 4: RefineryCMS changing sitename ... 17
List of tables Table 1: Websites using PHP ... 4
Table 2: Comparative table of Concrete5 and RefineryCMS ... 19 List of abbreviations
AMP Apache MySQL PHP
CMS Content Management System
CoC Convention over Configuration
DRY Don’t Repeat Yourself
Full-stack Customizable on every layer
Gem Extension for Ruby
Hashtag Metadata tag
Htaccess HyperText Access
HTML Hypertext Markup Language
IIS Internet Information Server JSON JavaScript Object Notation
MAMP Mac Apache MySQL PHP
MVC Model View Controller
OAuth Authorization Framework
Open-source Universal access and contribution in development projects
PC Personal Computer
PHP PHP: Hypertext Processor
SEO Search Engine Optimization
URL Uniform Resource Locators
1. Introduction
As usage of the Internet is increasing, so are the content management systems (CMS) for creating webpages. Today, there is a wide range of different CMSs to choose from, based on different kinds of frameworks, programming languages and purpose. A different approach to using a premade CMS is to create your own CMS, as Simpson (2005) pursued in his comparative study on a range of different open-source CMSs. The categories are the freely available systems on the market and the homemade CMSs. The study conducted by Simpson (2005) is of descriptive nature and is not going into detail about the features of each CMS. There are few studies of CMSs to create social webpages today. The majority of the studies are within the field of education, and creation of Course Management Systems, which can be made using a CMS, as Wong et.al (2010) wrote in their study. Wong et.al (2010) introduced the system to their University with great success.
As far as the topic of specific systems and how they are implemented and maintained, there are not many studies available at this current time when searching online databases. To give the less experienced developer a clearer view of how a CMS works and how to use it to implement a social website, the project #Grateful365 was created.
The idea behind #Grateful365 is that users will express their gratitude for something in a post on a social network and tag it with #Grateful365, thereby inspiring others to be grateful for what they have too. Users can post new items for 365 days or use the hashtag to imply that they are grateful for the posted item every day of the year. More about #Grateful365 can be found under chapter 1.5. #Grateful365.
1.1. Background
The rapid growth of web applications on the Internet has shown that users are relying on web-based applications to carry out everyday tasks, such as banking, emailing and social networking. Today, there are many types of technologies available to allow users to have quick access to services.
According to the Internet World Stats (2012) 34.3 % of the world’s population used the Internet in 2012, whereas only 5.1 % used the Internet in 2000. That is a 566.4 % growth from 2000 to 2012, and the number of users has been increasing each year.
As these web applications handle more and more of people’s daily lives, it is important to be able to design websites with high security, functionality and usability. Over 975 million people visited the popular social networking website Facebook on 31st December 2012 (Internet World Stats, 2012).
The market for software applications is growing bigger, and it is a market where products can be easily distributed and delivered quickly, due to the nature of software. Web applications can be modified and bugs can be fixed with updates,
which makes it profitable. Web-based software is easy to maintain, and easy to distribute, which makes it a growing market.
With the growing market for web applications, tools for creating them are getting more popular among both individuals and businesses (Simpson, 2005). These tools are called Content Management Systems (CMS), and there is a wide range of different systems for every purpose. There are many CMSs and they are all built on different frameworks and programming languages.
There are hundreds of programming languages out there, and there are language families like the C programming languages and some are Object Oriented. It is a sea of programming languages to choose from for a beginner, but which one is more useful when designing and coding a web application? Many languages are dependent on each other, and it is essential to know more than one language if a programmer is going to be able to work fluently. However, if one would use a CMS there would be less programming required to build a website.
1.2. The Question
The starting-point of the question is that the conditions for programming are met. The conditions is that the developer have a fundamental knowledge of programming and is looking to build a website like #Grateful365.
The Question will be as followed:
Under the given circumstances, which of the two Content Management Systems Concrete5 and RefineryCMS performs better in different aspects, and which Content Management System is recommended for a beginner developer looking to develop a basic website?
1.3. Purpose
The purpose of this thesis is to reach out to the beginner developers that are looking to build a website from scratch and needs help to start. There are not many studies available to the public about working with a CMS; this study will bring up ways to work with two different CMSs. This thesis is to direct the developer into making the right choices and start building websites.
1.4. Limitations
This thesis has been delimited to two popular programming languages, PHP and Ruby, and to carry out the experiments two CMSs have been chosen to implement the social web application. This thesis scales down the functionalities of the web application and only a few functionalities will be evaluated and implemented. The following features are being implemented; fetching data from online databases, switch between different pages, load up images in a mosaic pattern and a contact form.
Due to time constraints, only a few features of the CMS’s were covered in this thesis. The capacity of the server used to host the thesis project provided a limitation on how many images can be fetched and uploaded on the website, as
well as on other features such as creating user accounts and uploading images directly to the website.
Only the basics of the programming languages Ruby and PHP were learned in order to carry out the programming and implementation of the web application #Grateful365.
1.5. #Grateful365
#Grateful365 is a social web application where showing appreciation for everyday life is the main feature. The user can upload a picture or text to the website and show appreciation to someone or something by adding the hashtag #Grateful365 to the post. A hashtag is composed by a word or a phrase, which is prefixed by the hash symbol “#”. It is a form of a metadata tag, which assigns a keyword or a term to a piece of information so it will be easier to find it again by searching or browsing. The creator of the item often chooses the tags informally or personally. The posts that are created will be displayed in a mosaic pattern on the website. Hashtags from social web applications such as Instagram will be imported and displayed on Grateful365.org as well as the content created by users of the web application.
The hashtag #Grateful365 has been used by users on different social communities as Instagram (Instagram, 2014) and Twitter (Twitter, 2014), and as per June 2014 there are around 9 000 posts with that hashtag, where 7 643 of the posts are on Instagram.
2. Theory
This section will give a brief introduction to PHP, Ruby and the MVC cycle. The two CMS Concrete5, which is based on PHP, and RefineryCMS, which is based on Ruby is described to get the reader familiar with the languages and systems used in this thesis. Lastly, this section will give a brief overview of previous studies and research within this field.
2.1. PHP
PHP is an acronym for PHP: Hypertext Preprocessor and has been growing rapidly in popularity amongst the programmers since the launch in June 1995 (MacIntyre, 2005). It is open source software and in 1996 database integration was added. PHP is a very popular and powerful language through its increasing sets of functionalities (McIntyre, 2005). According to MacIntyre (2005), big web environments like Facebook, Flickr and Wikipedia use PHP (see Figure 1) in development of their social web applications.
PHP is a scripting language that is mostly used on the server side according to MacIntyre (2005), which can be utilized to create Hypertext Markup Language (HTML) information dynamically. PHP is generally connected to web servers such as Apache or Internet Information Server (IIS). Once it has generated proper HTML, it sends the HTML creation to the web server for delivery to the requesting client. Furthermore you can also use PHP in other areas such as command line and desktop PC.
The table down below will show a sample of websites that use PHP and their purpose, as well as a Uniform Resource Locator (URL). Due to SEO and sites making use of semantic URLs (also known as pretty URLs), it has become difficult to identify the scripting language used. However, if semantic URL structure is not being used on a website, one can simply look at the address bar in an Internet browser and view the extension at the end of the URL. For php files, it usually ends in ".php".
Website Purpose URL
Facebook Social networking www.facebook.com
Flickr Photography and blogging www.flickr.com
Wikipedia Online encyclopedia www.wikipedia.com
Table 1: Websites using PHP
2.2. Ruby on Rails
Ruby is an object oriented, open source programming language that runs on the framework Rails. This makes Ruby on Rails a software development
environment, and the overall aim with Ruby on Rails is to increase productivity and make it more fun (Kay, 2005).
2.2.1. Ruby
Ruby as a programming language has been around since 1993 and was initially popular in Japan. With the release of the Rails framework that is built around Ruby in 2004, Ruby got more popular and is now widely used and growing around the world. Ruby has a very clean syntax, and it is as useful for creating small ad hoc scripts, as it is useful for creating bigger full-scale applications. In Ruby you use direct-execution and dynamic typing, which allows an incremental workflow. Matsumoto, the creator of Ruby designed the programming language in a way so that it would have a minimum of excess verbiage. Once one is familiar with Ruby’s syntax and its style, one can easily read the code in somewhat of a natural spoken language, making it easier to understand and maintain.
2.2.2. Rails
According to Kay (2005) Rails is a full-stack, open-source programming framework that is implemented in Ruby and used for writing database-oriented web applications quickly and easily. The creator of Rails is David Heinemeier Hansson, who based it on a project management tool that he had written called Basecamp (Kay, 2005).
In a full-stack framework all layers are built to work together so the programmer does not have to repeat code, which is called Don’t Repeat Yourself (DRY) (Kay, 2005), and can use a single language from top to bottom. To achieve DRY, the framework relies on these guiding principles stated below.
The first is that there is less software, resulting in fewer lines of code. This makes the code easier to understand, maintain and enhance, it also speeds development. The second principle is Convention over Configuration (CoC), which means Rails does not use configuration files. Instead it uses information already contained in the application code and database. To make it clearer below is a citing of Hansson (Kay, 2005).
“This means the end of XML (Extensible Markup Language) files telling a story that has already been told in code. It means no compilation phase: make a change,
see it work.”
2.3. MVC cycle
The MVC cycle is an architectural pattern that divides the application logic and labor into three categories called the model, view and controller (MVC). The model represents the data and the information the application works with, the view represents the user interface and the controller directs all actions and interaction between model and view (Barazi & Carneiro, 2010). These three parts are individual entities, which means that they need not affect each other.
The MVC cycle is a typical architectural pattern used for implementing user interfaces in software development.
The MVC works in a cycle and the control flow usually works as follows (see Figure 2):
v The user interacts with the interface and generates an event, for example submits a form.
v The controller receives the input from the interface. v The controller then updates the information in the model.
v Then the controller updates the View and shows an updated interface for the user.
v The interface awaits further interaction from the user, and then the cycle repeats itself.
Figure 1: The MVC cycle
2.4. Content management systems
A CMS offers a way to keep your website updated in an organized way. It will let you edit, manage, create and publish content, instead of going through the traditional way of editing your HTML code. The characteristics of almost all CMS is according to an article in Journal of Visual Communication in Medicine (2008) is that they have default themes, which can make websites look similar to one another. There is however many plugins and extensions that can be modified and applied to a website. It is possible to customize virtually every element of a layout and manage protocols.
2.4.1. RefineryCMS
RefineryCMS is an open source CMS that is written in Ruby. RefineryCMS supports Ruby on Rails 3.2.
The four key principles according to RefineryCMS (Refinerycms, 2014) are “The Rails Way” which means that whenever possible RefineryCMS embraces conventions used in Rails. The second principle is the end-user focused interface, which is claimed to be simple, bright and attractive. The third principle is their “awesome developer tools” which make it easy for users to add features and change the look and feel of the front end. The last principle is to encourage and help other Ruby developers, RefineryCMS has an active community forum (Ruby-forum, 2014) where users can turn for assistance from other RefineryCMS users.
2.4.2. Concrete5
Concrete5 is an open source CMS. It is used for publishing contents on the Internet. It is designed to be easy to use, even for those with minimum technical skills. One of the main features of Concrete5 is the in-context editing, which allows the user to edit content directly on the page. It mainly uses PHP for development and is one of the highest ranked CMSs out there by the community (webhostingsearch, 2013).
3. Prior work
Prior to this thesis, several studies were conducted using CMSs for different purposes, e.g. research education (Wong et.al, 2010), trends in academic libraries (Connell, 2013) and also for website designs (Simpson, 2005) as well for spreading information on the Internet to different professional groups (Mooney & Baenziger, 2007).
Earlier studies of this subject has proven that the subject of CMS has been and is important to the technology field as well as to education, and also to spread information and use as a tool to analyze trends and data (Connell, 2013). Although these studies are of CMS, they are not specific for the practical uses of CMSs as a tool for web development. A comparative study of three Learning CMSs was conducted by Iglesias et.al (2010), however this study takes up learning a CMS, and the results are not based on the functionalities of the CMS itself.
4. Methods
In this section, the methods used for comparing and analyzing the two CMSs and the programming languages for the thesis are explained and discussed, as well as how the two cases were chosen.
4.1. Case studies
According to Bell (2005) a case study is an appropriate approach for the individual researcher to study an aspect of a problem more in-depth. As cited by Bell (2005), “The more a study contains a specific proposition, the more it will stay within reasonable limits”. When researching researchers often quantify their research and miss important things, which is why it is important to look into details and provide description. The thesis will be going through details of the two CMSs as well as comparing them at the same time, according to Bloor & Wood (2006) the purpose of a case study is to provide a description through a detailed example.
4.1.1. Choice of language and CMSs
PHP and Ruby were chosen based on a study by Dwarampudiet.al(2010), where different languages were compared. This study was conducted with a wide range of different programming languages available today and also their differences based on different criterias chosen by Dwarampudiet.al(2010). The study conducts a comparison of programming languages that are similar to one another.
When choosing between programming languages, criterias such as flexibility, compilation time and size of projects impact the choice. According to Dwarampudiet.al(2010) PHP and Ruby with Ruby on Rails are the best-preferred languages when it comes to Web application Development. Ruby is more preferred in projects where security, performance, readability and flexibility are prioritized (Dwarampudiet.al, 2010). The preference of PHP is because it is very widely used due to its simplicity, huge repository, documentations and lightweight syntax (Dwarampudiet.al, 2010), though it lacks security. Because of the nature of this thesis and #Grateful365 being a web application, these two languages were chosen to be studied further.
The CMSs chosen are based on the choice of programming languages. The choices of Concrete5 and RefineryCMS were made by a research online on different CMSs.
The keywords for the research are the following: Ø Top 10 CMS
Ø CMS + Ruby + Rails
Ø Content Management Systems + PHP
The most ordinary ones that had been covered in earlier studies are Wordpress, Joomla and Drupal, which are all PHP-based (Simpson, 2005). They are all based on different philosophies, however. When it comes to the administration sections
of Joomla and Drupal, it becomes difficult to understand for a user, which makes it difficult to learn. Wordpress is a CMS that is quite limited in marketing and sales abilities. Concrete5 was the only CMS that stood out by allowing in-page editing of blocks and followed the MVC pattern as well as being object oriented (Concrete5, 2014).
RefineryCMS is claimed to be the most popular Rails CMS by the community of Ruby-programmers (Geek-madness, 2012). The advantages of RefineryCMS is that it gives the developer full control over the design and the layout, as well as access to each of the Controllers.
4.1.2. Observations
These observational studies were carried out on a MacBook Pro 13”, late 2011 model, running Mac OSX 10.9.2 also known as Mavericks. The writer’s experience and observations are the primary data-source for the thesis’ result, since data will be collected and analyzed on the spot as the thesis is being written.
The writer of the thesis will be a part of the observation during the whole project, and the writer’s part in the thesis might change throughout the project as becoming more of an object than an observer (Barajas et.al, 2013). The more difficult part according to Barajas et.al (2013) is to remain objective to the observation, and to be able to understand the project as an object, and be able to tell an outsider about it without taking part. As the writer in this case will be conducting the experiments and observe the information as an observer and an object this will become a difficulty to not be critical based on former experiences (Bryman, 2008).
These observations will be of unstructured character (Bell, 2005), with the observer as an object and conducting the experiments for observation. A third party will be involved in observing sessions to make this as objective and unbiased as possible.
4.2. Comparative studies
A comparative study is according to Grix (2004) good to do in a case study, as every research has to be compared at some point, and to compare is natural both in studies and in life. This thesis will conduct a descriptive study and use comparative methods to compare the two cases Concrete5 and RefineryCMS.
4.2.1. The Method of Difference
The comparison of the two different systems will be conducted by using the method of difference (Denk, 2002). The differences between the two systems will be documented and presented in a table in chapter 4.5 where the difference is noted in the table with a comparison.
4.2.2. Most Similar Systems Design
The comparative analysis will be done using the Most Similar Systems Design (MSSD) method, which was developed to be a structure to analyze the method of
difference (Denk, 2002). This method is conducted by identifying the difference to be able to explain it. This will be presented in a table in chapter 4.5.
4.3. Authoring Tool Accessibility Guidelines 2.0
ATAG 2.0 is created for developers to provide guidelines for designing web
content authoring tools, to make them more accessible for all authors (W3, 2013). The parameters for the study in this thesis will be based on ATAG 2.0 as well as the writer’s own experiences and knowledge.
4.4. Methods discussion and credibility
As the results will be based on experiments that are conducted with little or no knowledge in the field of Ruby and PHP programming, this thesis might be of interest to beginners and students. The choice of methods is based on the writer’s pool of knowledge in this project. All literature and articles used are written by experts within the field, or published by credible journals on online databases. This gives it credibility in the contents.
Case studies are of an unstable character where it can be difficult for the writer to remain objective and crosscheck information. Another issue with case studies is according to Bell (2005) the issue that generalization is never possible. To minimize these issues of generalization and remain objective in the study, a third party will be involved in observing sessions and testing of the front end of the systems.
A comparative study of two programming languages has a risk of being highly opinionated, and the subject has been debated over centuries. Each and every person has their own preferences to which programming language is better; therefore this thesis will be strictly objective to how these languages perform on the writer’s computer with the given conditions. The third party will aid in the review of how the languages perform, to avoid personal opinions of PHP or Ruby, and the CMSs, Cocrete5 and RefineryCMS, this is to give the problem two viewpoints and can be analyzed from a more fair way. This work has the aim to aid a developer in choosing a system to work with, and can therefor be generalized even though the attempt of making it more objective.
5. Results
This section will cover the design and implementation of the #Grateful365 web application and provide an analysis and comparison of the process using the PHP-based Concrete5 CMS and the Ruby-based RefineryCMS.
5.1. Design specification of #Grateful365
The #Grateful365 is a nonprofit portal for all the posts with #Grateful365 tags from Instagram. These posts will be visible on the websites homepage. To create a nonprofit website that will please visitors it is important to have a way for the contributors of the nonprofit website and the visitors to contact the administrators (Van Duyne, Landay & Hong, 2001).
The following steps are part of the design specification: v Create basic pages
v Create theme
v Display Instagram posts on homepage The details of each step are described below.
5.1.1. Creating basic pages
A website is conducted up by different pages that will satisfy a different need from a visitor, so to test the functionality of the CMS, three pages for the Grateful365 web application will be created. These pages will be filled with content accordingly. The pages that will be implemented are the following:
ü Home: The homepage will be the first parent page that the user will view on the front end of the web application. This page will contain a mosaic of posts that are retrieved from Instagram. The mosaic pattern will consist of image-posts.
ü About: This page will have a summary of the founders of the #Grateful365 project, a short story of how it started and what kind of service the web application is offering.
ü Contact: All the essential information on how to reach the founders of the #Grateful365 project will be displayed on this page. There will also be an email form to fill in with questions or suggestions for improvement.
5.1.2. Create theme
To attract visitors and to also keep a consistency with color scheme throughout the website, a theme is important so a layout for the #Grateful365.org website will be drawn and wireframes for the user-interface done, so that it will be a consistent theme between the two cases.
5.1.3. Display Instagram posts
All the posts that are publicly visible on Instagram that has the hashtag #Grateful365 will be fetched as a query and be displayed on the websites homepage with the plugin masonry, which will arrange them in a mosaic pattern.
The parameters of this query will be set to 20 as a maximal number of posts shown on the webpage.
5.2. Implementation of #Grateful365
The following steps are needed for the implementation: v Initial stack setup
v CMSs setup
v Create “Home”, “About” and “Contact” pages, and format the pages for the front end
v Pull Instagram data and display it on the homepage The details of each step are described below.
5.2.1 Initial setup
Running Concrete5 and RefineryCMS requires different setups, e.g. regarding programming language and database server. The used stacks are described in the case sections.
5.2.2. Content Management System setup
To be able to use both of the CMSs, a setup is required, which can be done locally.
5.2.3. Back end interface
A user account was created on both CMSs to be able to set up the pages Home, About and Contact. In the following sections, the process of setup and formatting of the pages in each CMS will be discussed, as well as the user experience and overall interface.
5.2.4. Display Instagram data
To be able to make use of and get all the visible Instagram posts, an Instagram account is needed. So the first step in retrieving data from Instagram is to create an account on Instagram. After the account has been created, this address is visited “instagram.com/developer”.
5.3. Case 1 - Concrete5
5.3.1. Initial setup
A Concrete5 application requires PHP, MySQL and a web server in order to function. A quick and simple solution to meet these requirements is to use an AMP stack.
An AMP stack is a collection of applications that work together in order to run a web server. This collection includes the following applications:
ü Apache: A web server ü MySQL: A Database server
With all three applications working together, one can create a website making use of these applications in various ways. For example, one can create a website using PHP to display dynamic content, use MySQL to retrieve stored data such as blog posts, and make use of modules that comes with Apache like the rewrite module, that allows SEO-friendly URLs (also known as pretty URLs).
For this project, MAMP will be used (Mac Apache MySQL PHP) to build #Grateful365 using Concrete5, as this is one of the only Mac-compatible stacks (Concrete5, 2014). The alternative stack is known as XAMPP (Any OS, Apache, MySQL, PHP, Perl). The MAMP stack should be sufficient for a Concrete5 website to work.
5.3.2. Installing Concrete5 CMS
By creating a database, a place to store data is created. The database is created in PHPMyAdmin that is provided in the welcome screen of MAMP (see figure. 5). The created database was named grateful365php.
The next step after creating a database for the CMS is to download the Concrete5 zip-file and extract it to MAMP’s htdocs directory. When testing the website in a browser it displayed a white page.
By adding an error reporting function to the index.php file the problem was figured out, and the browser now said there was a missing file after being refreshed. Assuming that the extraction process was corrupted or interrupted, a new version of concrete5.zip was downloaded and the process above was repeated. The testing of the website worked after installing the new concrete5 version. An observation made by the co-observer in this error is that it is not the CMS’s that is at fault for this error, and so it is not accounted in the total time of installation.
Figure 2: Concrete5 pre-content
After going through the installation process and creating a user-account, the website was filled with some example-content to see what the website on the front end looked like. The installation proceeded without any errors.
5.3.3. Backend interface
The first impression of Concrete5 is their user-friendly interface. The back-end is incorporated with the front-end, and all the changes can be made without needing to go into the dashboard.
By clicking the edit button (see figure. 5), options like add a subpage and edit this page are displayed, along with other options like properties for the entire sitemap. Concrete5 offers in-context editing, and the user can change the content in a HTML-editor with the “What you see is what you get” style.
Figure 3: Concrete5 editing and adding subpage
5.3.4. Display Instagram data
To display the Instagram posts on Concrete5, the file default.php, which can be found within the default directory, had to be edited. PHP code was added to detect if the current page is the home page, and if it is the homepage, it will fetch the contents of the JSON from Instagram’s API and loop through the JSON to display the image posts (Stack overflow, 2010).
5.4. Case 2 - RefineryCMS
5.4.1. Initial setup
Running a RefineryCMS on a local machine is different and will not work with the MAMP stack. The following items are required for initial setup:
ü RVM: Ruby Version Manager to allow installation of multiple Ruby versions
ü Ruby: The programming language
ü Rails Gem: The framework required to run a RefineryCMS site ü A separate MySQL database server
ü The mysql2 gem: A gem (an extension for Ruby) required to communicate with the database server and provide numerous useful functions
Since a MySQL database server is already provided in the MAMP stack used for Concrete5, it was thought possible to use the same database with Ruby, however after continuous trial and error, this idea was abandoned and it was decided that a separate MySQL database server should be used instead. The time it took for this is not accounted in the total time, as a observation made by the co-observer that this is not the CMS’s fault for the errors.
To install the external MySQL database server, a download was required and after installation the MySQL server was enabled in System Preferences.
5.4.2. Installation of RefineryCMS
Before installing the Refinery gem, a directory folder for the CMS had to be created somewhere on the local hard drive. This could be done manually by creating a new folder in the chosen directory, however this could also be done using the Terminal. This code will create a shortcut in the chosen directory.
'sudo ln -s /usr/local/mysql/lib/libmysqlclient.18.dylib /usr/lib/libmysqlclient.18.dylib’.
After creating the shortcut, an attempt to install a Refinery gem was made, however this failed, as the requirements were not met. The imagemagick library was not installed, and the Terminal prompted a message saying imagemagick had to be installed.
To install imagemagick, the following command was run on terminal: 'brew install imagemagick’. Three attempts were made to run the command, because of issues with the server from where imagemagick was being downloaded. After the third attempt imagemagick installed correctly.
After the issue with imagemagick was solved, another attempt to install the RefineryCMS gem was made. This proceeded without any errors.
Next process was to create a new RefineryCMS project, but without a database installation. As the default for RefineryCMS is set to sqlite3, when mysql2 is the one to be used for this project, changes had to be made in the source code. The following command was executed: ‘refinerycms grateful365 --skib-db’ in Terminal. This command did not execute successfully due to another missing gem, which was ExecJS. This gem was installed successfully, but the grateful365 project had to be deleted and created again. After that being successfully executed, Terminal ran the RefineryCMS command again. This time it completed successfully. Within the project directory, the "config/database.yml" file had to be edited, for the database to work with RefineryCMS. The files adapter and database name for all three environments (development, live and user) were set, as well as the MySQL login details for the file. The "config/application.rb" file also had to be edited, to replace the database gem used. Originally this was ‘sqlite3’ this was changed to ‘mysql2’.
The command ‘rails s’ was typed into Terminal to run the server, however the server failed to start because of a MySQL issue.
After restarting the Mac, and running the "rails s" command, the server was responding and working. RefineryCMS uses a micro webserver called WEBRick, which covers the basic web server functionality, but is less powerful than Apache To test to see if the website was up and running on the server, the following address was typed into the browser: ‘http://localhost:3000/refinery’
However it displayed an error saying, “Page not found”. This happened due to the database installation being skipped. To try and solve the problem, the following command was run in a new terminal window:
‘rake db:migrate’
After running this command, WEBRick server was restarted by pressing "ctrl + C" in the first terminal window. Afterwards, the "rails s" command was run again in the terminal, to start the server. After refreshing the page in the browser, the webpage was up and running.
The final issue was the website name. There was no setting in the backend system that allowed an administrator to change the company name. When trying to solve this issue, time was spent researching online to find a solution. After researching online a resource that instructs to add code to the ‘application/controllers/application_controller.rb’ was found (Stack overflow, 2011).
Code was added to this file, and after adding a site name to the config by editing line 4, the file was saved and the server was restarted. The site name was now changed to “#Grateful365” after restart of the server. It was assumed that there would be settings provided in the backend interface, however this is not the case, and can be very tricky for administrators who do not understand Ruby to make site configurations.
RefineryCMS took approximately 1 hour and 25 minutes to install from beginning to end (this time does not include the time spent trying to use the MySQL server set up in the MAMP stack for Concrete5).
5.4.3. Backend interface
The interface of the content system was easy to understand and to browse through, even for beginners, although it was difficult to edit the site name.
The formatting options for this CMS was not based on in-context like Concrete5. In RefineryCMS formatting occurs in a HTML window where you write the code for the page content.
5.4.4. Display Instagram data
To display the posts in the home page, the default home page view needs to be overwritten, to do this the following command needs to be executed ‘rake refinery:override view=refinery/pages/home’. This command places the home page view in the app/views/refinery/pages directory (RefineryCMS, 2014).
5.5. Comparison table
In this section, the results from the implementation process for Concrete5 (PHP) and RefineryCMS (Ruby) will be displayed based on the different parameters stated below. The writer and the co-observer observed all the results together.
Parameter ATAG 2.0
guideline description
Case 1 Concrete5 Case 2
RefineryCMS Comparison
Accessible templates and pre-content
The CMS should provide templates and pre authored content to reduce effort required for authors and improving accessibility B.2.4- B.2.5
When starting with this CMS, a premade web layout is accessible, and customizable from their dashboard and in-content editing. With a wide range of premade templates to choose from, and also an accessible function to create a template of your own.
This system is starting off with an empty layout, where the author can add pages and content in the dashboard and HTML-editor. There is no pre-content or templates in this CMS. Implementing your own template is difficult.
Difference
Automatic
processes The CMS needs to ensure that automatically specific content is accessible B.1.1.
From the dashboard the author can generate automatically created web page with layout and pseudo content, as well as edit it directly from the front-end view.
This system has no automatically processed content, as the content needs to be added in the HTML-editor by the author.
Difference
Accessible
content editor The CMS need to support the author in producing content B.2 The CMS should guide the author to produce accessible content B.2.2
There is no active support in the system when getting started to produce content, however there is a guide available with frequently asked questions and guide through the features available.
There is no active support in this CMS, though a guide to the features is available.
User-friendly
layout N/A This CMS administer a front-end control, with very little need to use the dashboard and has an almost non-existent back-end view. With the many features it can be
confusing to find the exact feature.
This CMS is very simple, where everything is managed from one dashboard and the HTML-editor.
Difference
Programming
required N/A There is very little programming required to install, have many functions and packages and templates can be easily created and requires more coding.
To install this CMS programming
knowledge is required and it is time
consuming, command line had to get involved to get things working and more use of the terminal.
Difference
Time spent on
initial setup N/A The time spent on this CMS is very minimal, and the guidance was easy to follow.
Time spent: 35 min
This CMS requires a lot of time, and knowledge of Ruby, aswell as how to use the Terminal on a Macbook. Time spent: 1 h 25 min Difference Time spent on
learning CMS N/A This CMS took longer time to learn, due to its many features being scattered around the CMS.
Time spent: 3 h
Learning this CMS was simple due to its minimal features and simple back-end editing with everything in one place. Time spent: 1 h 20 min Difference
Table 2: Comparative table of Concrete5 and RefineryCMS
5.5.1. Accessible templates and pre-content
There are several benefits of providing accessible pre-authored contents for developers such as reducing effort required to develop a website (w3, 2013). Such content could be clip arts, widgets and templates for themes.
The two cases were very different from one another when it comes to pre-content on the CMS itself. After careful consideration by the writer and co-observer the conclusion is that there is a difference between these two cases, the conclusion is that Concrete5 is superior when it comes to providing pre-authored content and
accessible templates. RefineryCMS is a simple CMS with an out of the box feel which gives the programmer freedom to develop more open and freely.
5.5.2. Automatic processes
This parameter states that if a system automatically generates content it has to be accessible. If the automatically generated content includes accessibility problems, it will impose additional repair tasks on the developer, and the time it takes to create a page will increase (w3, 2013).
Concrete5 had automatically generated content, which it was possible for the developer to edit in block. The problems with this feature of the CMS is that it is difficult to generate the wanted features on the page without having to edit a lot in the auto generated content. This can be time consuming, but also effective if only the basics are desired.
RefineryCMS lacked any kind of automatic content, and the developer is directed to a HTML page where the contents of the desired page have to be manually coded. This gives the developer more flexibility in layout and design, though it can be time consuming.
5.5.3. Accessible content editor
By guiding the developer from the outset towards the creation and also maintenance of the web content, one can minimize the problems that will occur and fewer repairs are required (w3, 2013).
In this case the two systems gave an equal comparison, it both lacked a guide as to how to edit the content from outset to finished creation. There is however a guide that can be found online for each of these CMSs. In terms of how easy it is to follow and understand the guides provided, Concrete5 was significantly better. Many of the basic functionalities like changing website name in RefineryCMS was difficult to find. A research had to be conducted in order to change the website name on RefineryCMS.
5.5.4. User-friendly layout
To be able to learn a CMS quickly as well as navigate easily, a user-friendly layout is a necessity. By having easy to navigate to functions on the CMS less time will be spent searching, and minimize the problems that will occur. It is important to have a clear hierarchy and show the user of the CMS where to look for different functionalities, what to do and when to do it (Schlatter & Levinson, 2013). Furthermore the same authors write about the importance of consistency in layout, how color, typography and controls should be consistent.
The layout of Conconrete5 is based on in box, front end editing and provides many functionalities within the same screen. The hierarchy of the functionalities are scattered and there are many levels of functionality pages. This may confuse a developer as to here to find the functionalities he or her is looking for. As for consistency in layout, the set of color is defined, and the interface elements are the same throughout the whole system.
RefineryCMS has a simple layout and there are fewer layers to the functionality menus than on Concrete5. This makes it easy for a developer to search for the desired functionality in this system. Although it provides fewer functions than Concrete5, it is consistent in layout and has a clear hierarchy of functionalities.
5.5.5. Programming required
The two cases in this parameter gave a different comparison to how much programming was required to set up and use.
Concrete5 had more functions and required more structure, therefore it required more programming; however it was simple to work with this system. Concrete5 made it simple to work with themes and plugins; which made it easier to start development with this system.
RefineryCMS required more time on the terminal, slowing down the overall development. There was slightly less coding involved with the theme and plugin development for RefineryCMS, but it was not simple to work with this system. Overall, both require some programming knowledge to work with the systems, however for RefineryCMS, a developer needs to understand the functionality of the Ruby language, the Ruby on Rails framework and RefineryCMS, whereas Concrete5 requires an understanding of the PHP language and the CMS.
5.5.6. Time spent on initial setup
There was a big difference on the time spent on the initial setup for the two cases. Due to the requirements of RefineryCMS and the lack of gems on the computer used for the thesis, it took longer to install than Concrete5.
5.5.7. Time spent on learning CMS
Due to the many layers of functionalities and menus in Concrete5 it took approximately three hours to learn the whole system, and to create a webpage without running into problems. RefineryCMS was fairly easy to understand and to learn, though some functionalities were missing from the front end of the CMS. These functionalities are changing name of website and in box editing. You cant see how your page looks like until you save the HTML page and update your website on RefineryCMS.
5.5.8. Pre-knowledge of PHP and Ruby
The writers knowledge of PHP prior to this thesis gave Concrete5 a slight advantage in the time spent on learning the language, although Ruby was fairly easy to learn. Ruby is object oriented and the writer had pre-knowledge of other object programming languages such as Java.
6. Discussion
The experimentation of the two CMSs was not completed as planned from the beginning of the thesis. Due to time constraint, features such as Twitter posts and user login and social network sharing was abandoned, for time being. The Twitter implementation was attempted, but the API was not compatible with Concrete5. Concrete5 is generally more complicated to work with when implementing API packages, which is a big drawback. RefineryCMS requires less code to modify, but required more involvement with the command line to get things working.
The question first asked in this thesis was if Concrete5 or RefineryCMS was easier to work with when it comes to learning, programming and using to create a web application. The two systems were in general very different from one another and had their own benefits and drawbacks.
For beginners to be able to code in either CMS, they need to learn the basics of either PHP or Ruby. Concrete5 was easy to install and it takes less time in general to work with. The installation process of RefineryCMS was the part that took the longest time amongst these two CMS, but Ruby should be slightly easier to learn due to its similarity with a natural spoken language. The writer of the thesis initially had more knowledge of PHP, and found Concrete5 easier to work with. The co-observer though, noticed this by observing that not everybody would know PHP or Ruby when reading this thesis.
The front end of Concrete5 is user-friendly and its in-context editing feels fresh and is a way to make the CMS fun to use even for beginners and non-technical people. The templates for RefineryCMS were much more difficult to implement than for Concrete5, because of the programming in the source code, while there is premade templates in Concrete5.
Concrete5 is better fitting for websites with more images, as the user-interface is designed in such a way so its easier to add pictures to the website. Concrete5 will work for most websites and is easy to work with, once the developer has become familiar with PHP. It can be customized in many ways, and the community is big and helpful. The writer and the co-observer agreed these features of the CMS are the pros of Concrete5, after observing all the other tests in chapter 4.
The answer to the question of which CMS is better to build a web application with depends on many factors. It is possible that the conclusion could be affected in another direction, if factors change, such as the hardware and operating system, which were not within the scope of this thesis.
7. Conclusion
The final conclusion is that Concrete5 is better to create social web applications, due to the ease of layout design, in-context editing and less time required for installation and starting up. These features make up for the extra time spent on learning Concrete5.
The final conclusion is that Concrete5 had better aspects to build a basic website with the conditions the writer had with the MacBook pro 10.9.2. On the other hand, RefineryCMS could have worked better than what was covered and found if the writer had different conditions, which cant be drawn to a conclusion in this thesis.
8. Recommendations for future work
Due to time restraint, functionalities like retrieving Twitter posts, user login on the website, and social network sharing were abandoned. These features can be of interest to implement in future work to further test the CMSs.
The following cases are of interest to implement in future work with #Grateful365 to maximize the use of each CMS as well as the benefits of the website towards the visitors:
• Implement a user database and enable visitors to create a user account. This also requires great security on the website to keep the user information safe from attacks.
• Implement interaction with the visitors other social media account such as Twitter, Facebook and Instagram.
• Enable the user to upload images directly onto the website, and a donation function for charity, so the visitor can choose to pay a small amount to charity each time a new image is being uploaded.
• Embedding Google Adsense for monetisation. This is possible by allowing Google to place adverts on the website.
References
Printed sources:
Ø Barazi, R.A. & Carneiro, C. (2010). Beginning Rails 3. Springer.
Ø Bell, J. (2005). Doing your Research Project. A guide for first-time researchers in education, health and social science. Berkshire: Oxford University Press
Ø Bloor, M & Wood, F. (2006). Keywords in Qualitative Methods, A Vocabulary of Research Concepts. London: Sage Productions
Ø Bryman, A. (2011). Samhällsvetenskapliga metoder. Malmö: Liber AB Ø Connell, R. (2013). Content Management Systems: Trends in Academic
Libraries. Information Technology and Libraries (2013).
Ø Denk, T. (2002). Komparativ metod – förståelse genom jämförelse. Lund: Studentlitteratur
Ø Dwarampudi, V., Dhillon, S., Shah, J., Sebastian, N & Kanigicharla, N. (2010). Comparative study of the Pros and Cons of Programming languages Java, Scala, C++, Haskell, VB. NET, AspectJ, Perl, Ruby, PHP & Scheme – a Team 11 COMP6411-S10 Term Report. Cornell University Library (2010).
Ø Grix, J. (2004). The Foundations of Research. New York: Palgrave MacMillan
Ø Iglesias, A., Moreno, L., Martinez, P & Calvo, R. (2010). Three Open-Source Learning Content Management Systems: A Comparative Study. Conputer Science Department, Universidad Carlos Ill de Madrid, Getafe, Spain (2011).
Ø Kay, R. (2005) QUICK STUDY: Ruby on Rails. Computerworld (2005) 39, 48. 26.
Ø MacIntyre, P. (2005). PHP: The Good Parts. O’Reilly Media.
Ø Mooney, S & Baeziger, P. (2007) Extensible open source content management systems and frameworks: a solution for many needs of a bioinformatics group. Oxford University Press (2007).
Ø Rienecker, L. & Jörgensen, P. (2011) Att skriva en bra uppsats. Malmö: Liber AB
Ø Schlatter, T & Levinson, D. (2013) Visual Usability: Principles and Practices for Designing Digital Applications. Elsevier Science
Ø Siegert, K. (2008). Content Management Systems in Website Design. Journal of visual communications in medicine (2008) 120-121.
Ø Simpson, D. (2005). Content for One: Developing a Personal Content Management System. ACM, SIGGUCCS’05 (2005).
Ø Van Duy, D., Landay, JA. & Hong, JI. (2002). The design of sites: patterns, principles, and processes for crafting a customer-centered Web experience. Boston: Pearson Education, Inc.
Ø Wong, G., Chow, W., Wong, K., Chow, S., Lam, J & Cheung, H. (2010). Needs Assessment and Design of Course Management System (CMS) using Open and Community Source Frameworks in Post-secondary Institutions. ACM, SIGGUCCS’10 (2010).
Electronic sources:
Ø Concrete5, 2014. A letter to PHP developers. [online] Available at:
http://www.concrete5.org/about/our_philosophy/a-letter-to-php-developers/
[Accessed 10-08-2014
Ø Concrete5, 2014. In page editing. [online] Available at:
http://www.concrete5.org/documentation/editors-guide/in-page-editing/
[Accessed 10-08-2014]
Ø Concrete5, 2014. Installing concrete5 on a mamp local server. [online] Available at:
http://www.concrete5.org/documentation/how-tos/designers/installing-concrete5-on-a-mamp-local-server/[Accessed
19-03-2014]
Ø Geek-madness, 2012. RefineryCMS best CMS ever. [online] Available at:
http://geek-madness.blogspot.se/2012/04/refinerycms-best-cms-ever.html
[Accessed 08-08-2014]
Ø Internet world stats, 2012. Internet usage in America. [online] Available
at: http://www.internetworldstats.com/stats2.htm[Accessed 18-03-2014]
Ø Internet world stats, 2012. Internet usage in Asia. [online] Available at:
http://www.internetworldstats.com/stats3.htm [Accessed 18-03-2014]
Ø Internet world stats, 2012. Internet usage in Europe. [online] Available at:
http://www.internetworldstats.com/stats4.htm [Accessed 18-03-2014]
Ø Internet world stats, 2012. Internet usage statistics, the big picture. [online] Available at: http://www.internetworldstats.com/stats.htm
[Accessed 18-03-2014]
Ø RefineryCMS, 2014. About. [online] Available at: <http://refinerycms.com/about> [Accessed 23-03-2014]
Ø RefineryCMS, 2014. Installation prerequisites. [online] Available at:
http://refinerycms.com/guides/installation-prerequisites [Accessed
10-04-2014]
Ø RefineryCMS, 2014. Overriding views [online] Available at:
http://refinerycms.com/guides/overriding-views[Accessed 19-03-2014]
Ø Ruby Forum, 2014. Forum. [online] Available at:
https://www.ruby-forum.com/ [Accessed 20-02-2014]
Ø Stack over flow, 2010. Using Ruby to on Rails to fetch and parse JSON from another web service. [online] Available at:
http://stackoverflow.com/questions/4519895/using-ruby-on-rails-to-fetch-and-parse-json-from-another-web-service[Accessed 19-03-2014]
Ø Stack overflow, 2011. Library not loaded: libmysqlclient. 16.dylib error when trying to run ‘rails server’ on OS X 10.6 with mysql2 gem. [online] Available at: http://stackoverflow.com/questions/4546698/library-not-loaded- libmysqlclient-16-dylib-error-when-trying-to-run-rails-serv
[Accessed 21-03-2014]
Ø Stack overflow, 2011. Site name on refinery. [online] Available at:
http://stackoverflow.com2011/questions/6940479/site-name-on-refinerycms
[Accessed 19-03-2014]
Ø W3C, 2013. Authoring Tool Accessibility Guidelines (ATAG) 2.0. [online] Available at: http://www.w3.org/TR/ATAG20/ [Accessed 09-05-2014]
Ø Webhosting search, 2013. The 20 best CMS for 2013. [online] Available at:
http://www.webhostingsearch.com/articles/the-20-best-cms-2013.php
[Accessed 15-02-2014]
Ø Wikipedia, 2014. Hashtag. [online] Available at:
http://en.wikipedia.org/wiki/Hashtag [Accessed 18-03-2014]
Computer Program:
Ø MySQL, 2014. MySQL (2.1.1). [database server] MySQL. Available at: <http://dev.mysql.com/downloads/mysql/>
Ø RefineryCMS, 2014. RefineryCMS (3.8). [Computer program] RefineryCMS(Distributor). Available at:
