While perusing YouTube recently, I spotted a teaser screen which said, “Do not focus on the front sight!” Naturally, I decided to check it out.
The video is from NOIR Training, a service founded by Navy SEALs which “provides world class firearms and tactical training to Military, Law Enforcement, and Civilians.”
Like the video itself, the description is direct and to the point:
All about standard pistol sights. This is required viewing before any NOIR Training pistol course.
If you have any interest in shooting handguns with iron sights, view the entire video. It contains some of the best and most-understandable explanations and descriptions you’ll find, given by a narrator as we see a series of images to coincide with his words. For example, he does a good job explaining why it can be perfectly acceptable to fire at a target without a perfect sight picture, depending on the size and proximity of the target.
Around the 3:40 mark, things get even more interesting.
This is one area we differ from conventional shooting doctrine: We advocate shooting with your eyes focused on the threat, rather than the front sight.
The reason for this is, in a real life-threatening situation, your eyes will naturally focus on the threat. Since you can shoot perfectly accurately while focusing on the threat, we believe front sight focus is an unnatural and unnecessary complication.
He then goes on to explain the difference between front sight and target focus. While front sight focus can and will allow you to shoot accurately, he says, it’s “unnatural and unnecessary.” By contrast when you focus on the target, which is the natural thing to do when faced with a threat, you can still see both front and rear sights well enough to line them up to aim.
Interesting.
He then goes on to explain why we should all learn to shoot our handguns with both eyes open — because in a real life-threatening situation, we need to keep both peepers peeled.
I hope you find this as interesting as I did. Yes, it’s basic… but even the most experienced shooters can benefit from a fresh look at the basics.
A Detailed Comparison Between WordPress And October CMS
Leonardo Losoviz
Three months ago, WordPress finally released React-powered Gutenberg to power its default content editing experience, triggering many people who are not happy with this change to look for alternatives. Some folks decided to fork and release pre-Gutenberg WordPress, however, for me this doesn’t make much sense since it still carries 15 years worth of technical debt. If I were to find an alternative to WordPress, I would try to avoid being stuck in the past, and aim for a clean cut through some mature platform built on modern foundations.
This article compares WordPress to the arguably similar yet more modern October CMS on a wide arrange of both technical and non-technical topics. The goal of the article is not to convince people to stick to WordPress or to switch to October CMS, but simply to demonstrate what aspects must be taken into account before concluding the move to a different platform. The same comparison could (and should) also be done with other platforms before making a sensible decision.
Why October CMS
I found out about October CMS when it won an award, after which I went into research mode and spent a good deal of time digging deep into this CMS — from the perspective of both a user and a developer. As I gained knowledge on this CMS, I felt confident that I could provide an objective evaluation of its features as contrasted to WordPress. I chose this CMS for the comparison over alternative options such as Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo, and others, for the following reasons:
I know how this CMS works (unlike Grav);
It is free and open source (unlike Statamic and ButterCMS);
At five years, it is “relatively” new (unlike Joomla and Drupal);
It is a dynamic (not static) content generator and based in PHP (unlike Jekyll and Hugo).
I believe that October CMS is a good candidate because it is based on Laravel which is a framework used for building modern applications. After seven years of existence, it has received positive approval from developers (as evidenced by its sizeable community and ecosystem), and marks a distinct contrast over coding in WordPress, i.e. WordPress is mostly procedural programming while Laravel is decidedly object-oriented programming.
What’s The Difference Between The Two?
Below I will compare WordPress and October CMS on different categories and highlight what, I believe, is good and not so good about them. However, I will not pick a winner, since that’s not the objective of the article and, in any case, there is no “best” or even “better” CMS: each CMS has its own set of strengths and weaknesses that will make it more or less suitable for each task, project, company, team, and anything else. Moreover, a project may benefit from using more than one CMS, such as using some CMS to manage and provide data, and another CMS to render the view. To decide which of the dozens of CMSs out there is most suitable for your own needs is entirely up to you.
In addition, this article could never draw definitive conclusions since it is only concerned with a subset of all possibilities. For instance, we can also find online comparisons such as “WordPress vs Drupal vs Joomla”, “WordPress vs Static Site Generators” and even “WordPress vs Medium”. Because none of these articles sees the full picture, then none of these comparisons can ever be conclusive, and should not be treated as such.
Let’s start with the comparison.
Philosophy And Target Group
It is no coincidence that WordPress powers nearly 1 in 3 websites. Ever since its inception, it has strived to be extremely user-friendly and has done so successfully, removing friction for technical and non-technical users alike as well as for people from all backgrounds — irrespective of their education and economic levels. WordPress’ founder Matt Mullenweg expressed that WordPress’ motto of “Democratize Publishing” for the current era meant the following:
“People of all backgrounds, interests, and abilities should be able to access Free-as-in-speech software that empowers them to express themselves on the open web and to own their content.”
WordPress is easy to use for everyone and its inclusivity is evidenced on the development side too: It’s not uncommon to find people without a programming background (such as marketers, designers, bloggers, sales people, and others) tinkering with their WordPress installations, designing their own themes and successfully launching their own websites. WordPress is user-centric, and the needs of the users trump those of the developers. In WordPress, the user is king (or queen).
“October makes one bold but obvious assumption: clients don’t build websites, developers do. The role of a client is to manage the website and convey their business requirements. The web developer, and the industry itself, revolves around mediating these factors.”
In the words of its founders, the CMS’ mission is to “prove that making websites is not rocket science.” Being based on Laravel, October CMS can claim to have strong foundations of reusable, modular code that can produce properly-architected applications, maintainable in the long term and fully customizable without requiring hacks — the type which attracts serious programmers. October CMS can also provide a great user experience, however, it is not as simple or frictionless as that provided by WordPress. Users may need to be explained how to use certain functionality before being able to use it. For instance, embedding a form from some plugin has a lengthy explanation on how to do it, which is more cumbersome than the self-evident, drag-and-drop functionality provided by several form plugins in WordPress.
Installation
WordPress is famous for its 5-minute installation, even though many people point out that (taking into consideration all the plugins that must be installed) a typical installation requires 15 minutes or more. In addition, WordPress also offers the Multisite feature, which allows us to create a network of multiple virtual sites under a single installation. This feature makes it easy for an agency to administer the sites of multiple clients — among other user cases.
Installing October CMS is also very smooth: The Wizard installation itself takes even less than five minutes, and if you install it through the Console installation, it is even faster. You can do the latter by simply navigating to the target directory and then executing curl -s https://octobercms.com/api/installer | php (after which we need to input the database configuration, otherwise it behaves as a flat-file CMS). Once the installation has been completed, we will have a fully functioning website, but still quite bare (if you add the time needed to install and configure the required plugins, you can expect it to take at least 15 minutes).
Installing October CMS with the Wizard is a breeze. (Large preview)
Security
WordPress has been accused of being insecure due to the high amount of vulnerabilities that are constantly found. This forces users to have the software for the CMS and all installed plugins always up to date to avoid security exploits. Among the main issues is WordPress’ support for older versions of PHP which are not supported by the PHP development community anymore (WordPress currently supports PHP 5.2.4, while the latest fully supported PHP version is 5.6). However, this problem should be resolved in April 2019 when WordPress will officially start supporting PHP versions 5.6 and upwards.
Otherwise, WordPress is not necessarily insecure because of itself, but because of its high popularity, which makes it a primal target for hackers. However, this plays both ways: WordPress ubiquity means that its security team must really take their job seriously by constantly looking for exploits and fixing them as soon as possible, otherwise up to a third of the web is at risk. The stakes are just too high.
October CMS, on the other hand, doesn’t have a reputation of being insecure. However, since there are roughly 27,000 live sites that use October as compared with WordPress’ millions, we can’t judge the two of them on the same terms. Nevertheless, the team behind October CMS does take security seriously, as evidenced by the Wizard installation’s prompt to input the CMS backend URL, set as /backend by default but changeable to anything else, as to make it more difficult for hackers to target the site. In contrast, changing WordPress’ login and backend URLs from /wp-login.php and /wp-admin respectively to something else must be done through a plugin. In addition, October CMS can function as a flat-file CMS (i.e. without a database) and avoid database-related vulnerabilities such as SQL injection.
Technology Stack
Both WordPress and October CMS run on the traditional LAMP stack: Linux, Apache, MySQL, and PHP. (However, only PHP is fixed: we can also use Windows, Nginx, MariaDB, and others.) October CMS can also behave as a flat-file CMS, meaning that it can do without a database, however, at the cost of forgoing many functionalities (such as blog posts and users) the only functionality that is guaranteed is pages, which is considered to be the basic unit for the creation and publishing of content and shipped as a core feature.
Concerning the language stack, sites built with both WordPress and October CMS are based on HTML, CSS, and JavaScript (note that PHP is used to generate the HTML). October CMS also makes it easy to use LESS and SASS files.
Programming Paradigm
WordPress follows a functional programming paradigm, based on calculating computations by calling functions devoid of application state. Even though WordPress developers do not need to stick to functional programming (for instance, for coding their themes and plugins), the WordPress core code inherits this paradigm from 15 years of preserving backwards compatibility, which has been one of the pillars to WordPress’ success but which has the unintended consequence of accumulating technical debt.
Programming in WordPress could be characterized as HDD which stands for “Hook-Driven Development”. A hook is a mechanism that allows changing a default behavior or value and allowing other code to execute related functionality. Hooks are triggered through “actions” which allow executing extra functionality, and “filters” that allow modifying values.
Hooks, which are widespread across the WordPress codebase, are one of the concepts that I most like from coding in WordPress. They allow plugins to interact with other plugins (or with a core or theme) in a clean way, providing some basic support of Aspect-Oriented Programming.
Good news is that Laravel (and in consequence October CMS) also supports the concept of hooks, which is called “events”. Events provide a simple observer implementation, enabling code to subscribe and listen for events that occur in the application and react as needed. Events make it possible to split a complex functionality into components, which can be installed independently yet collaborate with each other, thus enabling the creation of modular applications.
Dependence on JavaScript Libraries
The latest version of WordPress incorporates React-powered Gutenberg for its default content creation experience. Hence, WordPress development now relies by and large on JavaScript (predominantly through React), even though it is also possible to use other frameworks or libraries (as evidenced by Elementor Blocks for Gutenberg which is based on Marionette). In addition, WordPress still relies on Backbone.js (for the Media Manager) and jQuery (legacy code), however, we can expect the dependence on these libraries to wither away as Gutenberg is consolidated as the new norm.
October CMS depends on jQuery, which it uses to implement its optional AJAX framework to load data from the server without a browser page refresh.
Pages, Themes and Plugins
Both WordPress and October CMS treat a page as the basic unit for creating and publishing content (in WordPress case, in addition to the post), support changing the site’s look and feel through themes, and allow to install and extend the site’s functionalities through plugins. Even though the concepts are the same in both CMSs, there are a few differences in implementation that produce somewhat different behavior.
In WordPress, pages are defined as content and stored in the database. As a result, page content can be created through the CMS only (e.g. in the dashboard area), and switching from one theme to another doesn’t make an existing page become unavailable. This produces an overall frictionless experience.
In October CMS, on the other hand, pages are static files stored under the theme directory. On the positive side from this architectural decision, page content can be created from an external application, such as text editors like Sublime or Visual Studio Code. On the negative side, when switching from one theme to another, it is required to manually recreate or copy the pages from the current to the new theme, or otherwise, they will disappear.
Significantly, October CMS resolves routing through pages, hence pages are used not just as containers for content but also for functionality. For instance, a plugin for blogging depends on a page for displaying the list of blog posts under a chosen URL, another page to display a single blog post under another chosen URL, and so on. If any of these pages disappear, the associated functionality from the plugin becomes unavailable, and that URL will produce a 404. Hence, in October CMS themes and plugins are not thoroughly decoupled, and switching themes must be done carefully.
October CMS enables the creation of content from external applications. (Large preview)
Core vs Plugin Functionality
WordPress attempts to deliver a minimal core functionality which is enhanced through plugins. WordPress relies on the “80⁄20 rule” to decide if to include some functionality in its core experience or not. If it benefits 80% of the users it goes in, otherwise, it belongs to plugin-land. When adding plugins to a site, they can lead to bloat if too many plugins are installed. Plugins may also not work well with one another, or execute similar code or load similar assets, resulting in suboptimal performance. Hence, whereas launching a WordPress site is relatively easy, a bigger challenge is its general maintenance and being able to preserve an optimal and performant state when adding new features.
The WordPress plugin directory claims to have almost 55,000 plugins. (Large preview)
Likewise, October CMS also attempts to deliver a minimal core functionality, but on steroids: the only guaranteed functionality is the creation and publication of pages, and for everything else we will need to install one plugin or another, which is expressed as:
“Everything you need, and nothing you don’t.”
The objective is clear: most simple sites are only composed of pages, with possibly no blog posts, users or login area. So why should the application load resources for these when they are not needed? As a consequence, functionalities for blogging, user management, translation and several others are released through the plugin directory.
Searching for ‘Rainlab’ in October’s plugins directory displays plugins created by October CMS’ team. (Large preview)
October CMS also includes certain features in its core which (even though they are not always needed) can enhance the application significantly. For instance, it provides out-of-the-box support to upload media files to Amazon S3 and accesses them through the Rackspace CDN. It also includes a Media Manager which is mostly used through plugins, e.g. for adding images into a blog post. (Pages can also use the Media Manager to embed media files, however, the CMS also ships with an Assets section to upload media files for these which seems more suitable.)
I believe that October’s opinionatedness can perfectly enable us to produce an application that is as lean as possible — mostly concerning simple sites. However, it can also backfire and encourage bloat, because the line of what is needed and what is not is an arbitrary one, and it’s difficult to be set in advance by the CMS. This difficulty can be appreciated when considering the concept of a “user”: In WordPress, website users and website admins belong to the same user entity (and through roles and privileges we can make a user become an admin). In October CMS, these two are implemented separately, shipping in core the implementation for the website administrator which can log in to the backend area and modify the settings, and through a plugin the implementation of the website user. These two types of users have a different login process and a different database table for storing their data, thus arguably breaching the DRY (Don’t Repeat Yourself) principle.
This problem arises not only concerning the behavior of an entity but also what data fields it must contain. For instance, should the website user data fields be predefined? Is a telephone field required? What about an Instagram URL field, considering that Instagram got kind of cool only recently? But then, when building a professional website shouldn’t we use a LinkedIn URL field instead? These decisions clearly depend on the application and can’t be decided by either CMS or plugin.
The October CMS plugin called User implements users but without any user field, on top of which plugin User Plus adds several arbitrary user fields, which are possibly not enough, so plugin User Plus+ adds yet other user fields. When, where and how do we stop this process?
Another problem is when there is no room to add new capabilities to an entity, which leads to the creation of another, extremely similar entity, just to support those required capabilities. For instance, October CMS ships with pages, and allows to create “static pages” through a plugin. Their nature is the same: both pages and static pages are saved as static files. The only difference between them (as far as I can tell) is that static pages are edited with a visual editor instead of the HTML editor, and can be added to menus. In my opinion, only structural differences, such as having one entity saved as a static file and the other one stored in the database, could justify creating a second entity for a page (there is a pull request to do this), but for simple features, as is the case currently, it constitutes development bloat.
In summary, a well implemented October CMS application can be very lean and efficient (e.g. by removing the database when not needed), but on the contrary it can also become unnecessarily bloated, forcing developers to implement several solutions for similar entities, and which can be very confusing to use (“Should I use a page or a static page?”). Because neither WordPress or October CMS has found a perfect solution for removing bloat, we must design either application architecture with care to avoid down-the-road pain.
Content Creation
Gutenberg makes two important contributions to WordPress: It uses components as the unit for building sites (which offers several advantages over coding blobs of HTML), and it introduces an entity called a “block” which, once Gutenberg Phase 2 is completed (presumably in 2019), will provide a unified way to incorporate content into the site, thus enabling a simpler user experience as opposed to the more chaotic process of adding content through shortcodes, TinyMCE buttons, menus, widgets, and others.
Since WordPress 5.0 Gutenberg is the default content creation experience. (Large preview)
Because Gutenberg blocks can produce and save static HTML as part of the blog post, then installing many Gutenberg blocks doesn’t necessarily translate into bloat on the website on the user side, but can be kept restricted to the admin side. Hence, Gutenberg can arguably be considered a good approach to produce websites in a modular way, with a simple yet powerful user experience for creating content. Possibly the biggest drawback is the (unavoidable, but not easily so) requirement to learn React, whose learning curve is rather steep.
If React components are the basic unit for creating content in WordPress, October CMS is based on the premise that knowing good old HTML is enough for building sites. Indeed, when creating a page, we are simply presented an HTML (Markup) editor:
If the page were solely static HTML, then there would be no need for a CMS. Instead, October CMS pages are written using Twig templates which are compiled to plain optimized PHP code. They can select a layout to include the scaffolding of the page (i.e. repetitive elements, such as the header, footer, and so on), can implement placeholders, which are defined on the layout to allow the page to customize content, and can include partials, which are reusable chunks of code. In addition, pages can include content blocks, which are either text, HTML or Markdown files that can be edited on their own and can attach components which are functionalities implemented through plugins. And finally, for whenever HTML is not enough and we need to produce dynamic code, we can add PHP functions.
The editor is all about HTML. There is no TinyMCE textarea for adding content in a visual manner — at least not through the default experience (this functionality belongs to plugin-land). Hence, having knowledge of HTML could be considered a must for using October CMS. In addition, the several different inputs for creating content (pages, layouts, placeholders, partials, content blocks, components, and PHP functions) may be very effective, however, it is certainly not as simple as through the unified block interface from WordPress. It can even get more complex since other elements can also be added (such as static pages and menus, and snippets), and some of them, such as pages and static pages, seemingly provide the same functionality, making it confusing to decide when to use one or the other.
As a result, I dare say that while pretty much anyone can use a WordPress site from the admin side, October CMS is more developer-friendly than non-technical user-friendly, so programmers may find it a joy to use, but certain other roles (marketers, sales people, and the like) may find it non-intuitive.
Media Manager
Both WordPress and October CMS are shipped with a Media Manager which allows adding media files to the site effortlessly, supporting the addition of multiple files simultaneously through a drag-and-drop interface and displaying the images within the content area. They look and behave similarly; the only notable differences I found are that WordPress’ Media Manager allows to embed image galleries, and October’s Media Manager allows to manually create a folder structure where to place the uploaded files.
October CMS ships with a powerful Media Manager. (Large preview)
Since the introduction of Gutenberg, though, WordPress’ media capabilities have been enhanced greatly, enabling to embed videos, pictures and photo galleries in place as compared to within a TinyMCE textarea (which only provides a non-accurate version of how it will look like in the site), and unlocking powerful, yet easy-to-use features as shown in this video.
Internationalization
WordPress core uses gettext to enable the translation of themes and plugins. Starting from a .pot file containing all strings to translate, we need to create a .po file containing their translation to the corresponding language/locale, and this file is then compiled to a binary .mo file suitable for fast translation extraction. Tools to perform these tasks include GlotPress (online) and Poedit (downloadable application). Conveniently, this mechanism also works for client-side localization for Gutenberg.
Poedit allows to translate strings for themes and plugins for WordPress. (Large preview)
WordPress currently doesn’t ship any solution in core to translate content, and will not do so until Phase 4 of Gutenberg (targeted for year 2020+). Until then, this functionality is provided by plugins which offer different strategies for storing and managing the translated content. For example, while plugins such as Polylang and WPML store each translation on its own row from a custom database table (which is clean since it doesn’t mix content together, but slower since it requires an additional INNER JOIN of two tables when querying the database), plugin qTranslate X stores all translations on the same field from the original database table (faster for querying the data, but content mixed all together can produce wreckage on the site if disabling the plugin). Hence, we can shop around and decide the most suitable strategy for our needs.
October CMS doesn’t ship the multilingual functionality through its core, but as a plugin created by the October CMS team that guarantees a faultless integration into the system. From a functional point of view, this plugin delivers what it promises. From a development point of view, it is not quite ideal how this plugin actually works. In WordPress, a page is simply a post with post type “page” and there is a single translation mechanism for them, but in October CMS, there are entities “page”, “static page” and “blog post” and, even though quite similar, they require three different implementations for their translations! Then, the content from a “page” can include message codes (e.g. codes called nav.content, header.title, and so on), each of which contains its translations for all locales as a serialized JSON object in database table rainlab_translate_messages. The content from a “static page” is created into a new static file per locale, however, all translated URLs for all locales are stored not in their corresponding file but instead on the default language’s file. The content for the “blog post” is stored as a serialized JSON object with one row per locale in database table rainlab_translate_attributes and the translated URL is stored with one row per locale in database table rainlab_translate_indexes. I don’t know if this complexity is due to how the plugin was implemented or whether it is due to October CMS’ architecture. Whichever the case, this is another instance of undesired bloat on the development side.
Plugin Management
Both WordPress and October CMS offer a sophisticated plugin manager which allows to search for plugins, install new plugins, and update currently-installed plugins to their latest version — all from within the backend.
October CMS enables to keep all plugins up-to-date effortlessly. (Large preview)
Dependency Management
October CMS uses Composer as the package manager of choice, enabling plugins to download and install their dependencies when being installed, thus delivering a painless experience.
WordPress, on the opposite side, hasn’t officially adopted Composer (or any PHP dependency manager) because the community can’t agree if WordPress is a site or a site dependency. Hence, if they require Composer for their projects, developers must add it on their own. With the switch to Gutenberg, npm has become the preferred JavaScript dependency manager, with a popular developer toolkit depending on it, and the client-side libraries being steadily released as autonomous packages in the npm registry.
Interaction With The Database
WordPress provides functions to retrieve database data (such as get_posts) and store it (such as wp_insert_post and wp_update_post). When retrieving data, we can pass parameters to filter, limit and order the results, in order to indicate if the result must be passed as an instance of a class or as an array of properties and others. When the function doesn’t fully satisfy our requirements (e.g. when we need to do an INNER JOIN with a custom table) then we can query the database directly through global variable $wpdb. When creating a plugin with a custom post type, the code will most likely be executing custom SQL queries to retrieve and/or save data into custom tables. In summary, WordPress attempts to provide access to the database through generic functions in the first stage, and through low-level access to the database in the second stage.
October CMS employs a different approach: Instead of connecting to the database straight away, the application can use Laravel’s Eloquent ORM to access and manipulate database data through instances of classes called Models, making the interaction with the database also be based on Object-Oriented Programming. It is high-level access; just by following the rules on how to create tables and set-up relationships among entities, a plugin can retrieve and/or save data without writing a line of SQL. For instance, the code below retrieves an object from the database through model Flight, modifies a property, and stores it again:
$flight = Flight::find(1);
$flight->name = 'Darwin to Adelaide';
$flight->save();
Upgrading The Data Model
Another reason for WordPress’ success (in addition to not breaking backward compatibility) has been its database architecture, which was engineered to enable applications to grow over time. This objective is accomplished through “meta” properties, i.e. properties that can be loosely added to a database object at any moment. These properties are not stored in a column from the corresponding entity table (either wp_posts, wp_users, wp_comments or wp_terms), but instead as a row in the corresponding “meta” table (wp_postmeta, wp_usermeta, wp_commentmeta or wp_termmeta) and retrieved doing an INNER JOIN. Hence, even though retrieving these meta values is slower, they provide unlimited flexibility, and the application’s data model rarely needs to be re-architected from scratch in order to implement some new functionality.
WordPress provides unlimited flexibility for upgrading the application’s data model. (Large preview)
October CMS doesn’t use meta properties but instead can store several arbitrary values, which are not directly mapped as columns in the database tables, as a serialized JSON object. Otherwise, when an object needs some new property, we need to add a new column on the corresponding table (which is the reason behind plugins User Plus and User Plus+, mentioned earlier on). To update the application’s database schema, October CMS relies on Laravel’s Migrations, which are sets of instructions to execute against the schema (such as add or drop a column, rename an index, etc) and which are executed when upgrading the software (e.g. when installing a plugin’s new version).
Headless Capabilities
Both WordPress and October CMS can be used as headless, i.e. treating the CMS as a content management system that makes content accessible through APIs, which allows to render the website on the client-side and can power other applications (such as mobile apps). Indeed, WordPress is steadily heading towards headless, since the Gutenberg content editor itself treats WordPress as a headless CMS (and, as a consequence, Gutenberg can also work with any other CMS too, as Drupal Gutenberg demonstrates).
A headless system needs to implement some API to return the data, such as REST and GraphQL. WordPress supports REST through WP REST API (merged in core), exposing endpoints under some predefined route /wp-json/wp/v2/...; October CMS supports REST through plugins RESTful and API Generator, which allow to create custom endpoints and, as a consequence, support versioning as part of the endpoint URL and can offer a better security against bots. Concerning GraphQL, WordPress supports it through WPGraphQL, while October CMS currently has no implementations for it.
Quite importantly, a headless system needs to offer powerful content management capabilities. As mentioned earlier on, WordPress has a very solid database architecture, offering a plethora of data entities (users, posts and custom posts, pages, categories, tags and custom taxonomies, comments) over which the application can be reasonably well modelled, meta properties to extend these data entities (enabling the application to upgrade its data model accordingly and without major changes), and with plugin Advanced Custom Fields filling the gap to construct relationships among the data entities. In addition, plugin VersionPress allows to version control the database content using Git. Hence, WordPress is undoubtedly a good fit for managing content, as demonstrated in severalprojectsinthewild.
On its part, and as mentioned earlier on, October CMS can omit the database and behave as a flat-file system, or it can have a database and behave as a hybrid, storing the content from pages as static files and blog posts (and others) on the database. As a consequence, content is not centralized, and its management involves a different approach. For instance, while we can use Git to version control pages, there is no support to version control the database per se; the solution to this is to populate data into the database through Seeders which, being code, can be put under version control and executed upon deployment. In addition, October CMS doesn’t offer a baked-in database model featuring predefined data entities that can support the needs of most applications. Hence, more likely than not the application will need custom development to implement its data model, which means more work, but also means that it can be more efficient (e.g. accessing a property from a column is faster than from a row in another table through an INNER JOIN, which is the case with WordPress’ meta properties).
CLI Support
Both WordPress and October CMS can be interacted with from the console through a Command Line Interface (CLI): WordPress through WP-CLI and October CMS through Laravel’s Artisan. In addition to Laravel’s commands, October CMS implements several custom commands for updating the system, migrating the database, and others. These tools make it very convenient to access the site from outside a browser, for instance for testing purposes.
Managed Hosting
It is not a problem finding a managed hosting provider for a WordPress site: given WordPress’ market share, there are dozens (if not hundreds) of providers out there vying with each other for the business, constituting a very dynamic market. The only problem is finding the most suitable provider for our specific sites based on all of their offerings, which can vary based on price, quality, type (shared or dedicated services), bandwidth and storage size, customer support, location, frequency of renewal of equipment, and other variables which we can navigate mainly through reviews comparing them (such as this one, this one or this one).
Even though nothing near as many as WordPress, October CMS still enjoys the offering from several hosting providers, which allows for some consideration and selection. Many of them are listed as October Partners, and several others are found DuckDuckGoing, but since I haven’t found any independent review of them or article comparing them, the task of finding out the most suitable one will take some effort.
Marketplace, Ecosystem And Cost
WordPress’ commercial ecosystem is estimated to be USD $10 billion/year, evidencing how many people and companies have managed to make a living by offering WordPress products and services, such as the creation of sites, hosting, theme and plugin development, support, security, and others. Indeed, its size is so big it is even bloated, meaning that it is very common to find different plugins solving the same problem, plugins that underdeliver, underperform or have not been updated for years, and themes which seem to look-alike each other. However, when creating a new site, the size and variety of the ecosystem also means that we will most likely find at least one plugin implementing each of the required functionalities, enabling us to save money by not having to develop the functionality ourselves, and the availability of customizable themes enables to produce a reasonably distinctive-looking site with minimal effort. As a consequence, we can easily create and launch a WordPress site for less than USD $100, making WordPress a sensible option for projects of any budget.
Being relatively new (only five years so far), OctoberCMS certainly doesn’t enjoy anything near WordPress’ marketplace and ecosystem sizes, however, it has been growing steadily so its size is bound to become bigger. Currently, its marketplace boasts 600+ plugins, and only a handful of themes. Concerning plugins, the October CMS team is requesting the community to put their effort into the creation of original plugins, delivering functionality not yet provided by any other plugin.
Hence, even though 600+ plugins doesn’t sound like much, at least these translate into 600+ different functionalities. This way, even though it is not possible to choose among several vendors, at least we can expect to have those basic website features (such as blogging, comments, forum, integration with social media, e-commerce, and others) to be covered. Also, since October’s founders are personally reviewing all submitted plugins and judging them according to quality guidelines, we can expect these plugins to perform as expected. As another plus, October plugins can incorporate elements from Laravel packages (even though not all of them are compatible with October, at least not without some hacks). Concerning themes, the low number of offerings implies we will most likely need to develop our own theme by hiring a developer for the task. In fact, I dare say that the theme in October CMS will most likely be a custom development, since themes and plugins are not thoroughly decoupled (as explained earlier), with the consequence that a market for easily-swappable themes is more difficult to arise. (This is a temporary problem though: once this pull request is resolved, pages will be able to be stored in the database, and swapping themes should not disrupt functionality.)
In my opinion, because of the smaller offerings of themes and plugins, creating a simple site with OctoberCMS will be more expensive than creating a simple WordPress site. For complex sites, however, October’s better architecture (Object-Oriented Programming and Model-View-Controller paradigms) makes the software more maintainable and, as a consequence, potentially cheaper.
Community
Being a part of and having access, WordPress’ community represents one of the most compelling reasons for using WordPress. This is not simply as a matter of size (powering nearly one third of all websites in the world, there are so many stakeholders involved with WordPress, and its community is representatively big) but also as a matter of diversity. The WordPress community involves people from many different professions (developers, marketers, designers, bloggers, sales people, and so on), from all continents and countries, speaking countless languages, from different social, educational and economic backgrounds, with or without disabilities, from corporate, not-for-profit and governmental organizations, and others. Hence, it is quite likely that, for whatever problem we encounter, somebody will be able to help on any of the support forums. And contributing to WordPress is pretty straightforward too: The Make WordPress group congregates stakeholders interested in supporting different projects (accessibility, design, internationalization, and many others) and organizes how and how regularly they communicate — mostly through some dedicated channel on its Slack workspace.
Furthermore, the WordPress community is real and tangible: it doesn’t exist just online, but it gathers offline in WordCamps and meetups all over the world; in 2018, there were a total of 145 WordCamps in 48 countries with over 45,000 tickets sold, and a total of 5,400 meetup events from 687 meetup groups. Hence, it is likely that there is a local chapter nearby which anyone can join to ask for help, learn how to use the platform, keep learning on a regular basis, and teach others as well. In this sense, WordPress is not just a CMS but, more importantly, it’s also people, and considering to leave WordPress should never be done only on its technical merits but on the power of its community, too.
WordCamp Kuala Lumpur 2017 drew more than 200 attendees, coming from several countries. (Large preview)
October CMS’ community is nothing near in size or diversity as WordPress’, even though it has been growing steadily following the increasing popularity of the software. October provides a support forum to ask for help, however, it is not very active. A Slack workspace exists which is pretty active and where, quite importantly, October’s founders participate regularly, helping make sure that all enquiries are properly addressed. This channel is a great source for learning low-level tips and tricks about the software, however, it is geared towards developers mainly: There are no channels concerning accessibility, design, internationalization, and other topics as in the WordPress community, at least not yet. Currently, there are no conferences concerning October CMS, but there is Laracon, the conference for the Laravel community.
Maintainers And Governance
Can we trust that the software will be maintained in the long term, so that if we decide to start a project today, we will not need to migrate to some other platform down the road? How many people are taking care of developing the software? And who is deciding in what direction the software moves towards?
Powering one-third of all sites in the world, WordPress is not short of stakeholders contributing to the software; hence we need not fear that the software will fall into decay. However, WordPress is going through internal deliberations concerning its governance model, with many members of the community expressing that decisions concerning WordPress’s direction are being taken unilaterally by Automattic, the company running WordPress.com. Center stage of this perception was the decision to launch Gutenberg, which many members disagreed with, and which suffered a lack of proper communication by the project leads during its development and release. As a consequence, many community members are questioning the role of “benign dictator”, which has been historically granted to WordPress’ founder and Automattic’s CEO Matt Mullenweg, and researching different governance models to find a more suitable one for the future of WordPress. It is yet to be seen if this quest produces any result, or if the status quo perseveres.
Decisions concerning October CMS’ direction are mainly taken by founders Alexey Bobkov and Samuel Georges and developer and community manager Luke Towers, which keep the project going strong. October CMS doesn’t have the luxury of having a governance problem yet: Its current concern is how to make the project sustainable by generating income for the core software’s maintainers.
Documentation
WordPress documentation in its own site is not extremely comprehensive, but it does the job reasonably well. However, when taking all of the documentation about WordPress into account from all sources, such as general sites (Smashing Magazine, CSS tricks, and many others), specialized sites (WPShout, WPBeginner, and many others), personal blogs, online courses, and so on, there is practically no aspect of dealing with WordPress that hasn’t already been covered.
October CMS doesn’t enjoy anything near the many third-party courses, tutorials or blog posts about it as much as WordPress does, however, the documentation on its site is reasonably comprehensive and certainly enough to start coding. October founders also regularly add new documentation through tutorials. One aspect that I personally enjoyed is the duplication of Laravel’s documentation into October’s documentation for everything of relevance, so the reader must not fill the gaps by him/herself and having to guess what is October’s domain and what is Laravel’s. However, this is not 100% perfect. October’s documentation uses terms originating from Laravel, such as middleware, service containers, facades and contracts, without adequately explaining what these are. Then, reading Laravel’s documentation in advance can be helpful (luckily, Laravel’s documentation is decidedly comprehensive, and Laravel’s screencasts, Laracasts, are another great source of learning, not just concerning Laravel but web development in general).
Conclusion
I set out to discover what features may be enticing for developers looking for alternatives to WordPress by comparing WordPress to a similar CMS, which I defined as being free and open source, based in PHP and producing dynamic content, and enjoying the support from some community. From the CMSs fulfilling these conditions, I chose October CMS for the comparison because of the knowledge I got about it, and because I appreciated its clean and modular coding approach as provided by Laravel, which could offer a fresh and modern perspective for building sites.
This article did not intend to pick a winner, but simply analyze when it makes sense to choose one or the other CMS, highlighting their strengths and weaknesses. There is no “best” CMS: only the most suitable CMS for a specific situation. Furthermore, anyone looking for a CMS to use on a particular project with a specific team and given a certain budget, should do some research and compare all the offerings out there to find out which one is most suitable for the particular context. It’s important not to limit to a few CMSs as I’ve done here in this article, but instead give a chance to all of them.
On a personal note, as a developer, what I found in October CMS is really appealing to me, mostly its ability to build modular applications as provided through Laravel. I would certainly consider this CMS for a new website. However, in the process of writing this article I also “rediscovered” WordPress. Being so popular, WordPress receives more than its fair share of criticisms, mostly concerning its old codebase and, since recently, the introduction of Gutenberg; however, WordPress also has certain excellent features (such as its super-scalable database model) which are seldom praised but should be taken into account too. And most importantly, WordPress should not be considered on its technical aspects alone: in particular, the size of its community and ecosystem places it a level or two above its alternatives. In a nutshell, some projects may benefit from sticking to WordPress, while others may better rely on October CMS or another platform.
As a final note, I would like to remark that exploring how another CMS works is a very rewarding activity on its own, independent of the decision reached concerning whether to use that particular CMS or not. In my case, I had been working for years on WordPress alone, and delving into October CMS was very refreshing since it taught me many things (such as the existence of PHP Standards Recommendations) which I had not been exposed to through WordPress. I may now decide to switch CMSs, or stick to WordPress knowing how to produce better code.
Whether it’s too many family photos or an ever-expanding movie collection, you’re going to need enough data storage. If you need a safe place to save your data, using a network-attached storage device is the way to go, but high-quality NAS devices can be costly.
Thankfully, you can build your own at a much lower cost if you’re using software like FreeNAS, OpenMediaVault, and Amahi, but which is best for your DIY NAS? Let’s compare them and find out.
FreeNAS is probably the best known NAS operating system out there. It’s been in development since 2005 and has over 10 million downloads to its name. It’s also got the biggest development team, thanks to corporate backing from its parent company, iXsystems.
Unlike our other two contenders, FreeNAS is based around FreeBSD, a Unix-based cousin to the Linux kernel, used in Amahi and OpenMediaVault. It uses the OpenZFS file system, which supports pooled and scalable storage.
FreeNAS has features you’d find in enterprise-level NAS devices, like data snapshots and practically unlimited storage limits. Whatever your disk management, FreeNAS supports it; RAID, hot-swapping, and disk striping are all supported under the OS.
It covers almost every data sharing protocol, such as Samba and NFS. This means it’ll work great with devices running any OS—Windows, macOS, and Linux included. It also supports integration with cloud storage providers like Amazon S3 and Google Cloud out of the box.
Want to add other features? FreeNAS has support for third-party plugins to expand your NAS capabilities further. You can even control virtual machines and Docker containers through the FreeNAS web interface to turn it into a server. The web interface isn’t complicated to use, thanks to a clear breakdown of features, and it’s the most modern of the three.
It’s well supported, regularly updated and the active development means you get cutting edge features when they’re stable enough for release. The downside? This isn’t an OS for low powered systems.
FreeNAS recommends at least 8GB of RAM and a multi-core processor as a minimum. You should also invest in reliable storage drives to keep your data safe. If you don’t want to DIY it, the company offers it’s own NAS devices for sale.
OpenMediaVault has a strong NAS pedigree. It’s been around since 2009 and was created as a successor to FreeNAS by one of its original developers when that project was facing a major re-write. It’s open source, so it’s completely free to use and distribute and has had over 4 million downloads.
Unlike FreeNAS, OpenMediaVault is based around Debian, one of the best Linux distributions thanks to its stability and active development. Talking of active development, OpenMediaVault gets minor updates on a monthly basis, with major releases occurring nearly every year.
OpenMediaVault and FreeNAS have some crossover features, such as storage monitoring, Samba/NFS file sharing, and RAID disk management. However, it doesn’t have some of the more advanced features that FreeNAS has, like hot-swapping or the OpenZFS file system. As it’s Debian-based, ext4 is the default file system, but you can install others like JFS or XFS.
Using Debian as it’s base means that OpenMediaVault installations get to take advantage of the large number of Debian packages available. You don’t get cloud integration included as standard with OpenMediaVault, but you can add this with additional plugins, or by using a relevant Debian package.
You can set up a web server, BitTorrent client, or even a Plex media server if you wanted to, thanks to OpenMediaVault plugins.
There’s only one primary developer for OpenMediaVault, but others play a small part in developing patches and creating plugins. One of OpenMediaVault’s best features, compared to FreeNAS, is it’s low system requirements. You can run OMV on low-powered devices like the Raspberry Pi, where you can combine it with media software like Plex to create a Raspberry Pi Plex server.
FreeNAS and OpenMediaVault are both NAS-focused, but Amahi is a little different. It doesn’t try to just be a NAS operating system—it wants to be the only Linux media server OS you’ll ever need.
Amahi is based around Fedora, another well known Linux distro. Stable releases of Amahi are based around stable Fedora releases, the latest being Amahi 11 matching Fedora 27. Five main developers form a core team keeping Amahi up-to-date and with new features.
It’s not a technical OS, and the web interface is designed to be simple for end users. You can install “apps” that extend Amahi, from media server software like Plex to game servers.
You can use Amahi as a VPN server for your network, set up a local wiki or calendar for your family, and turn it into a backup server for all of your PCs. It supports all the standard file sharing protocols like Samba and NFS as standard, and these can be easily configured in the web interface.
On a technical note, Amahi uses typical Fedora file systems such as ext4 and XFS. Amahi even competes with some of the enterprise-level features that FreeNAS supports, with storage pooling using Greyhole. This combines all of your storage into one to help prevent data loss.
Stable updates and a wide feature set make Amahi a good choice for beginners who want a NAS server that does everything.
Which of these would make the best operating system for a NAS device? That depends on your own requirements, as they each have their own strengths and weaknesses. Choose the best NAS software for your own needs:
FreeNAS: Best for enterprise users or home users with lots of storage.
OpenMediaVault: Best for home users and small businesses, especially with low powered equipment.
Amahi: Best for users looking for a full media server experience with NAS features included.
Whether you choose FreeNAS, OpenMediaVault or Amahi, you’ll have software that’s in active development, well supported and with plenty of available features. You’ll just need to make sure you choose the best parts for your own server to make sure it’s reliable to use as an always-on storage solution.
Scientists have developed an "acoustic meta-material" that can catch certain frequencies passing through the air and reflect them back toward their source. When a loudspeaker was placed into one end of a PVC pipe with a 3D-printed ring of the metamaterial, the ring "cut 94% of the sound blasting from the speaker, enough to make it inaudible to the human ear," reports Fast Company. From the report: Typical acoustic paneling works differently, absorbing sound and turning the vibrations into heat. But what’s particularly trippy is that this muffler is completely open. Air and light can travel through it — just sound cannot. The implications for architecture and interior design are remarkable, because these metamaterials could be applied to the built environment in many different ways. For instance, they could be stacked to build soundproof yet transparent walls. Cubicles will never be the same.
The researchers also believe that HVAC systems could be fitted with these silencers, and drones could have their turbines muted with such rings. Even in MRI machines, which can be harrowingly loud for patients trapped in a small space, could be quieted. There’s really no limit to the possibilities, but it does sound like these silencers will need to be tailored to circumstance. "The idea is that we can now mathematically design an object that can blocks the sounds of anything," says Boston University professor Xin Zhang, in a press release. You can see a demo of the noise cancellation device here.
Throughout this tutorial for beginners you’ll learn to use Laravel 5.8 – the latest version of one of the most popular PHP frameworks – to create a CRUD web application with a MySQL database from scratch and step by step starting with the installation of Composer (PHP package manager) to implementing and serving your application.
Note: Laravel 5.8 is recently released and this tutorial is upgraded to the latest version.
Laravel 5.8 New Features
Let’s start our tutorial by going through the most important features introduced in this version.
The hasOneThrough Eloquent relationship.
Better email validation,
Auto-Discovery Of Model Policies provided that the model and policy follow standard Laravel naming conventions
DynamoDB cache and session drivers,
Added support for PHPUnit 8.0 for unit testing,
Added support for Carbon 2.0, an easy to use PHP API extension for DateTime,
The Laravel 5.8 version has also corrected numeroous bugs and introduced many improvements of the Artisan CLI.
Check out the official docs for details features of Laravel 5.8
Prerequisites
This tutorial assumes you have PHP and MySQL installed on your system. Follow the instructions for your operating system to install both of them.
You also need to be familiar with Linux/macOS bash where we’ll be executing the commands in this tutorial.
Familiarly with PHP is required since Laravel is based on PHP.
For development I will be using a Ubuntu 16.04 machine so the commands in this tutorial are targeting this system but you should be able to follow this tutorial in any operating system you use.
Installing PHP 7.1
Laravel v5.8 requires PHP 7.1 or above so you need the latest version of PHP installed on your system. The process is straightforward on most systems.
On Ubuntu, you can follow these instructions.
First add the ondrej/php PPA which contains the latest version of PHP:
Next, install PHP 7.1 using the following command:
$ sudo apt-get install php7.1
If you are using Ubuntu 18.04, PHP 7.2 is included in the default Ubuntu repository for 18.04 so you should be able to install it using the following command:
$ sudo apt-get install php
This tutorial is tested with PHP 7.1 but you can also use more recent versions like PHP 7.2 or PHP 7.3
Installing the Required PHP 7.1 Modules
Laravel requires a bunch of modules. You can install them using the following command:
As of this writing Composer 1.8 will be installed on your system. You can make sure your installation works as expected by running composer in your terminal:
$ composer
You should get the following output:
______
/ ____/___ ____ ___ ____ ____ ________ _____
/ / / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__ ) __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
/_/
Composer version 1.8.0 2018-12-03 10:31:16
Usage:
command[options] [arguments]
Options:
-h, --help Display this help message
-q, --quiet Do not output any message
-V, --version Display this application version
--ansi Force ANSI output
--no-ansi Disable ANSI output
-n, --no-interaction Do not ask any interactive question
--profile Display timing and memory usage information
--no-plugins Whether to disable plugins.
-d, --working-dir=WORKING-DIR If specified, use the given directory as working directory.
-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
Laravel is a web application framework with expressive, elegant syntax. We believe development must be an enjoyable and creative experience to be truly fulfilling. Laravel attempts to take the pain out of development by easing common tasks used in the majority of web projects, such as:
Note: Make sure you have PHP 7.1 installed on your system. Otherwise, composer will use Laravel 5.5 for your project.
You can verify the installed version in your project using:
$ cd laravel-first-crud-app
$ php artisan -V
Laravel Framework 5.8.19
Installing the Front-End Dependencies
In your generated project, you can see that a package.json file is generated which includes many front-end libraries that can be used by your project:
axios,
bootstrap,
cross-env,
jquery,
laravel-mix,
lodash,
popper.js,
resolve-url-loader,
sass,
sass-loader,
vue.
Note: You can use your preferred libraries with Laravel not specifically the ones added to package.json.
The package.json file in your Laravel project includes a few packages such as vue and axios to help you get started building your JavaScript application.
It also includes bootstrap to help you get started with Bootstrap for styling your UI.
It include Laravel Mix to help you compile your SASS files to plain CSS.
You need to use npm to install the front-end dependencies:
$ npm install
After running this command a node_modules folder will be created and the dependencies will be installed into it.
Note: You need to have Node.js and npm installed on your system before you can install the front-end dependencies.
Creating a MySQL Database
Let’s now create a MySQL database that we’ll use to persist dat ain our Laravel application. In your terminal, run the following command to run the mysql client:
$ mysql -u root -p
When prompted, enter the password for your MySQL server when you’ve installed it.
Next, run the following SQL statement to create a db database:
mysql>createdatabasedb;
Open the .env file and update the credentials to access your MySQL database:
You need to enter the database name, the username and password.
At this point, you can run the migrate command to create your database and a bunch of SQL tables needed by Laravel:
$ php artisan migrate
Note: You can run the migrate command at any other points of your development to add other SQL tables in your database or to later your database if you need to add any changes later.
Creating your First Laravel Model
Laravel uses the MVC architectural pattern to organize your application in three decoupled parts:
The Model which encapsulates the data access layer,
The View which encapsulates the representation layer,
Controller which encapsulates the code to control the application and communicates with the model and view layers.
Model–view–controller is an architectural pattern commonly used for developing user interfacesthat divides an application into three interconnected parts. This is done to separate internal representations of information from the ways information is presented to and accepted from the user.
Now, let’s create our first Laravel Model. In your terminal, run the following command:
$ php artisan make:model Contact --migration
This will create a Contact model and a migration file. In the terminal, we get an output similar to:
Model created successfully.
Created Migration: 2019_01_27_193840_create_contacts_table
Open the database/migrations/xxxxxx_create_contacts_table migration file and update it accordingly:
<?php
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateContactsTable extends Migration
{
/*** Run the migrations.
** @return void
*/
public function up(){
Schema::create('contacts', function(Blueprint $table){$table->increments('id');
$table->timestamps();
$table->string('first_name');
$table->string('last_name');
$table->string('email');
$table->string('job_title');
$table->string('city');
$table->string('country');
});
}
/*** Reverse the migrations.
** @return void
*/
public function down(){
Schema::dropIfExists('contacts');
}}
We added the first_name, last_name, email, job_title, city and country fields in the contacts table.
You can now create the contacts table in the database using the following command:
$ php artisan migrate
Now, let’s look at our Contact model, which will be used to interact with the contacts database table. Open the app/Contact.php and update it:
After creating the model and migrated our database. Let’s now create the controller and the routes for working with the Contact model. In your terminal, run the following command:
Laravel resource routing assigns the typical "CRUD" routes to a controller with a single line of code. For example, you may wish to create a controller that handles all HTTP requests for "photos" stored by your application. Using the make:controller Artisan command, we can quickly create such a controller:
This command will generate a controller at app/Http/Controllers/PhotoController.php. The controller will contain a method for each of the available resource operations.
Open the app/Http/Controllers/ContactController.php file. This is the initial content:
<?phpnamespaceApp\Http\Controllers;useIlluminate\Http\Request;classContactControllerextendsController{/**
* Display a listing of the resource.
*
* @return \Illuminate\Http\Response
*/publicfunctionindex(){//
}/**
* Show the form for creating a new resource.
*
* @return \Illuminate\Http\Response
*/publicfunctioncreate(){//
}/**
* Store a newly created resource in storage.
*
* @param \Illuminate\Http\Request $request
* @return \Illuminate\Http\Response
*/publicfunctionstore(Request$request){//
}/**
* Display the specified resource.
*
* @param int $id
* @return \Illuminate\Http\Response
*/publicfunctionshow($id){//
}/**
* Show the form for editing the specified resource.
*
* @param int $id
* @return \Illuminate\Http\Response
*/publicfunctionedit($id){//
}/**
* Update the specified resource in storage.
*
* @param \Illuminate\Http\Request $request
* @param int $id
* @return \Illuminate\Http\Response
*/publicfunctionupdate(Request$request,$id){//
}/**
* Remove the specified resource from storage.
*
* @param int $id
* @return \Illuminate\Http\Response
*/publicfunctiondestroy($id){//
}}
The ContactController class extends Controller class available from Laravel and defines a bunch of methods which will be used to do the CRUD operations against the Contact model.
You can read the role of the method on the comment above it.
Now we need to provide implementations for these methods.
But before that, let’s add routing. Open the routes/web.php file and update it accordingly:
Using the resource() static method of Route, you can create multiple routes to expose multiple actions on the resource.
These routes are mapped to various ContactController methods which will need to implement in the next section:
GET/contacts, mapped to the index() method,
GET /contacts/create, mapped to the create() method,
POST /contacts, mapped to the store() method,
GET /contacts/{contact}, mapped to the show() method,
GET /contacts/{contact}/edit, mapped to the edit() method,
PUT/PATCH /contacts/{contact}, mapped to the update() method,
DELETE /contacts/{contact}, mapped to the destroy() method.
These routes are used to serve HTML templates and also as API endpoints for working with the Contact model.
Note: If you want to create a controller that will only expose a RESTful API, you can use the apiResource method to exclude the routes that are used to serve the HTML templates:
Let’s now implement the controller methods alongside the views.
C: Implementing the Create Operation and Adding a Form
The ContactController includes the store() method that maps to the POST /contacts API endpoint which will be used to create a contact in the database and the create() that maps to the GET /contacts/create route which will be used to serve the HTML form used to submit the contact to POST /contacts API endpoint.
Let’s implement these two methods.
Re-open the app/Http/Controllers/ContactController.php file and start by importing the Contact model:
use App\Contact;
Next, locate the store() method and update it accordingly:
public function create()
{
return view('contacts.create');
}
The create() function makes use of the view() method to return the create.blade.php template which needs to be present in the resources/views folder.
Before creating the create.blade.php template we need to create a base template that will be extended by the create template and all the other templates that will create later in this tutorial.
In the resources/views folder, create a base.blade.php file:
$ cd resources/views
$ touch base.blade.php
Open the resources/views/base.blade.php file and add the following blade template:
Fill out the form and click on the Add contact button to create a contact in the database. You should be redirected to /contacts route which doesn’t have a view associated to it yet.
R: Implementing the Read Operation and Getting Data
Next, let’s implement the read operation to get and display contacts data from our MySQL database.
Go to the app/Http/Controllers/ContactController.php file, locate the index() method and update it:
public function index()
{
$contacts = Contact::all();
return view('contacts.index', compact('contacts'));
}
Next, you need to create the the index template. Create a resources/views/contacts.index.blade.php file:
$ touch index.blade.php
Open the resources/views/contacts/index.blade.php file and add the following code:
Finally, we’ll proceed to implement the delete operation. Go to the app/Http/Controllers/ContactController.php file, locate the destroy() method and update it accordingly:
public function destroy($id)
{
$contact = Contact::find($id);
$contact->delete();
return redirect('/contacts')->with('success', 'Contact deleted!');
}
You can notice that when we redirect to the /contacts route in our CRUD API methods, we also pass a success message but it doesn’t appear in our index template. Let’s change that!
Go to the resources/views/contacts/index.blade.php file and add the following code:
There are countless products available that help you track your sleep, giving you insights into your sleep patterns and quality. But there’s been nothing to help snoozers identify sleep apnea, a potentially-serious condition that could traditionally only be diagnosed by a sleep clinic. Now, health device maker Withings has released a new update to its sleep tracking mat that could help users recognize the symptoms of this disorder.
Around 22 million Americans suffer from sleep apnea, which is characterized by pauses in breathing, or periods of shallow breathing, during sleep. As well as symptoms of fatigue, sleep apnea can result in headaches and depression, and in serious cases, stroke and heart failure. The update to Withings’ sleep tracking mat ($100) will monitor breathing disturbances during the night, and give users educational content about the signs of sleep apnea via the Health Mate app.
The update also helps set the company’s sleep mat apart from its competitors — Apple’s Beddit Sleep Monitor, for example, costs $150 but doesn’t have this function. But this is just the first step for Withings in this area. The company says it’s working on even more advanced diagnostics for sleep apnea, and aims to have medical-grade certified tracking for the condition in place by the end of the year.
It’s the first Monday back at work after daylight saving time and hopefully you don’t have to make a PowerPoint presentation today. If you do, it surely can’t be worse than what “Saturday Night Live” stars Kate McKinnon and Aidy Bryant came up with this weekend.
The late-night comedy took a run at Microsoft’s presentation program, in a skit starring actor Idris Alba and cast member Mikey Day as employees for the software giant, helping some office workers brush up on the PowerPoint skills.
“We don’t even use computers, just the phone, so we will see,” said Bryant, playing one of two receptionists charged with making a mock presentation. It only got worse from there.
With each slide, the receptionists fell further and further into despair, saying they had no idea what they were doing with PowerPoint. “This is not my world! … Honestly I’m at the point in my life where I feel that I can’t learn.”
Check out the video above, and take some time to brush up on your own skills today.
Learning to type quickly and accurately is an essential skill. Whether you are learning for the first time, upgrading to touch typing or an alternate keyboard layout, repetition is key to improvement. But repetition with practice can feel like a drag.
Let’s face it—playing games is way more fun. So we went out and picked seven excellent typing games that will challenge you.
Why Should You Play These Typing Games?
There are numerous websites and pieces of software to help improve your keyboard skills. Many of them employ game mechanics, but can’t claim to be computer games. Many typing games are lacking in content and do not give a satisfying experience when compared to mainstream games—but there are exceptions.
This article will focus on fully fledged games that feature typing. Some are speed typing games, others are word games requiring fast keyboard skills, and there are even some arty indie typing experiences.
1. Typefighters
Singleplayer: Yes (Play against A.I.)
Multiplayer: LAN and Online
By far the most traditional typing game on this list, Typefighters takes a well-worn idea and does it well. While there are several modes to choose from, the general gameplay stays the same.
Type the words on the screen faster than your AI or real life opponent to gain points. Whoever reaches a certain point cap or who is scoring highest when the time is up wins.
This game is pure typing. You can even navigate the menus by typing, which feels incredibly satisfying for those who know keyboard shortcuts for everything!
Multiple modes can be played against friends online and over LAN. What this game provides in comparison to standard typing instruction software is game feel. Every keystroke has a satisfying sound, and completion of words shakes the text and the screen giving excellent user feedback.
God Of Word is a wordplay and typing game of epic proportions. You play a young actor, tasked with recreating famous battles of history for the gods of Olympus. Weapons, potions, and upgrades are all essential to progress. But without quick wits and fast fingers you won’t get far!
The core gameplay consists of word scramble puzzles, along with speed typing challenges to defeat groups of enemies. Each boss (a computer controlled enemy) brings a mechanic that needs more impressive wordplay and tactics. The campaign plays out over 5 acts, with two endless modes.
The multiplayer mode allows online play against friends or other strangers and comes with a separate upgrade system to customize your character.
Do you like Bullet Hell games, horror movie themes, and adult humor? The Textorcist: The Story of Ray Bibbia is all of these things, along with being an incredibly challenging typing game. You play the titular role, a self-styled exorcist/detective tasked with investigating a string on strange possession cases.
Each battle consists of dodging vast numbers of enemy attacks while typing the words required to banish each demon. Failing to avoid attacks causes you to drop your prayer book, and you can’t continue the incantation until it is retrieved. The game is challenging from the get-go, and the ramp up to “full on bullet hell while typing Latin” is severe. Be prepared for a challenge.
Fantastic pixel artwork and pumping electronic soundtrack add to the experience. The story is incredibly dark yet comical, and this game is most certainly NSFW! Nevertheless, this is one of the most original typing games ever created, and a must for any quick-fingered gamer.
We couldn’t make a list like this without including The Typing Of The Dead. It was one of the most unusual arcade games ever devised. A near direct adaption of the popular House Of The Dead 2 from Sega, the arcade cabinets shuns guns for computer keyboards.
In-game, the characters also had keyboards (with rucksack mounted computers no less), and gun-play is replaced with typing at speed to stop the invading hordes. A mixture of quick-fire words, and (sometimes bizarre) phrases need constant vigilance to avoid getting eaten.
While the original release is now hard to run, Sega released a modern addition in 2013 in the form of The Typing Of The Dead: Overkill. The newer version retains the original’s gameplay but updates the graphics for modern hardware. There is plenty of content to keep you busy after the primary campaign, with cheap DLC bundles which add to the base game.
Lovers of all things retro will find plenty to like about Secret of Qwerty. This loving indie recreation of old school RPGs (right down to the dodgy translation of dialogue) has a crucial difference. You guessed it—typing replaces standard combat.
Like the much-loved adventure RPGs of old, you must explore a fantasy world, clear dungeons, and survive random encounters. Each battle rewards the player with XP and Gold which can be used to buy more powerful items to help you on your quest to defeat an evil wizard arch enemy. This game is a nod to much adored old games, and at a “Pay What You Like” cost, is worth your time.
Monologue is the only browser game on this list, and what it lacks in game depth it makes up for in charm and humor. You play as the antagonist who has placed their foe in the path of an oncoming train. Rush to finish your victory speech before they escape! You must type your speech correctly, as any mistake knocks you back to the start of the current word, thus wasting precious time.
Fun but straightforward graphics, jaunty old west music, and the mumbles and coughs of the player character complement the hilarious randomly generated speech. Monologue was an entry in the 2015 Train Game Jam and is free to play online.
There are few typing games which can boast gorgeous 3d graphics, a story, voice acting, and puzzle-based gameplay. In this third-person RPG, you play as a girl riding a three-tailed fox through a series of beautifully Origami-like stylized worlds. All interaction happens by typing words. The game adapts to your typing speed as you clear enemies and environmental elements.
The player gathers XP through exploration, trials with waves of enemies, and memory puzzles which also unlock new areas. You can buy new skills with experience points that grant movement speed increases and aids to combat. A particularly nice touch comes in the form of languages you cannot speak until a skill is learned.
The game adds harder words if your going is too easy. This game also supports alternate keyboard layouts including AZERTY, Dvorak, and Colemak. If you are looking for a full game experience in a typing game, Epistory – Typing Chronicles is one of the strongest contenders around.
Good typing games can seem to be thin on the ground. But there are some great examples out there. Mixing games into your practice will improve your typing skills. And a good routine always reinforces good habits, and a good mechanical keyboard while not essential really improves the typing experience.
As we do in many series at Laracasts, we’ll begin with laravel new project. Following that, we’ll incrementally pull in all necessary npm dependencies and construct the base skeleton for our "assets" website.
View the source code for this episode on GitHub.
via Laracasts The Skeleton
