Tag: Developing


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
23 Nov

Developing For The Semantic Web

by TBSCategories: News

In July the Wikimedia Foundation announced Abstract Wikipedia, an attempt to markup knowledge that is language-independent. In many respects, this is the culmination of decades of buildup, during which the dream of a Semantic Web has never quite taken off, but never quite disappeared either.

As a matter of fact the Semantic Web is growing, and as it renews its mission we all stand to gain from incorporating semantic markup into our websites, be they personal blogs or social media giants. Whether you care about sophisticated web experiences, SEO, or fending off the tyranny of web monopolies, the Semantic Web deserves our attention.

The benefits of developing for the Semantic Web are not always immediate, or visible, but every site that does strengthens the foundations of an open, transparent, decentralized internet.

The Semantic Web

What exactly is the Semantic Web? It is a machine-readable web, providing through metadata “a common framework that allows data to be shared and reused across application, enterprise, and community boundaries.”

The idea is as old as the World Wide Web itself. Older, in fact. It was a focal point of Tim Berners-Lee’s 1989 proposal. As he outlined, not only should documents form webs, but the data inside them should too:

The Semantic Web’s tread a rocky road in the decades since. Since the turn of the millennium, it has morphed into multiple concepts — open data, knowledge graphs — all effectively meaning the same thing: webs of data.

As the W3C summarises, it is “an extension of the current web in which information is given well-defined meaning, better-enabling computers and people to work in cooperation.”

The idea has had its fair share of advocates. Internet hacktivist Aaron Swartz wrote a book manuscript about the Semantic Web called A Programmable Web. In it he wrote:

“Documents can’t really be merged and integrated and queried; they serve mostly as isolated instances to be viewed and reviewed. But data are protean, able to shift into whatever shape best suits your needs.”

For a variety of reasons, the Semantic Web has not taken off in the same way the Web has, though it is catching up. Several markups have tried to seize the mantle over the years — RDFa, OWL, and Schema to name a few — though none have become standard in the way, say, HTML or CSS have. The barrier to entry was too high.

However, the dream of the Semantic Web has endured, and as more and more sites incorporate it into their designs there’s all the more reason to join the party. The more sites that get on board, the stronger the Semantic Web becomes.

Further Reading

Knowledge Without Borders

Before getting into the weeds of how to design for the Semantic Web, it’s worth digging a little deeper into the why. What does it matter whether data is connected? Aren’t connected documents enough?

There are several reasons why the Semantic Web continues to be pushed by those who care about a free and open internet. Understanding those reasons is essential to the implementation process. It shouldn’t be a case of ‘eat your vegetables, use semantic markup.’ The Semantic Web is something to believe in and be a part of.

Benefits of the Semantic Web include:

  • Richer, more sophisticated web experiences
  • Bypassing content silos and internet monopolies
  • Improved search engine readability and rankings
  • Democratisation of information

Most of these can be traced back to a core tenet of the Semantic Web: a universal language for data. Although the internet has already done wonders for international communication, there’s no escaping the fact some countries have it much better than others. Take languages used on the web vs. languages used in the real world, for example. The eagle-eyed among you may be able to spot a slight imbalance in the data below…

The borderless utopia of the web is not as close as it might seem to those of us inside the English-speaking bubble. Is that something to chastise anyone for? Not necessarily, but it is something to face up to. Doing so highlights the importance of markup that bridges those gaps. By enriching the data of the web, we take the strain off of its languages.

This is the crux of the recently announced Abstract Wikipedia, which will attempt to decouple articles from the language they happen to be written in. Wikimedia Executive Director Katherine Maher writes: “Using code, volunteers will be able to translate these abstract ‘articles’ into their own languages. If successful, this could eventually allow everyone to read about any topic in Wikidata in their own language.”

Abstract Wikipedia creator Denny Vrandečić has been a Semantic Web advocate for years, recognizing its potential to unlock untapped potential online. Breaking down national barriers is essential to that process.

“No matter what language you publish your content in, you are going to miss out on including the vast majority of people in the world. The Web gave us this wonderful opportunity to have global reach — but by relying on a single language, or a small set of languages, we are squandering this opportunity. While the most important objective is to create good content in the first place, you invite more people to participate in the development of better content by being language-independent. It helps you lower the barriers to contribution and consumption, and it allows for many more people to benefit from that effort.”

— Denny Vrandečić, Abstract Wikipedia creator

A timely example of this has been data visualization during the COVID-19 pandemic. The virus has wreaked unspeakable havoc worldwide, but it has also been a shining moment for open data networks, allowing superb web apps, reporting, and more to be common across the web.

And of course, when data is transparent and easily accessible, it makes it easier to identify anomalies… or straight up deceit. Widespread public access to the kind of information above would be unthinkable even 20 years ago. Now we expect it, and smell a rat when it’s denied us. Data is powerful, and if we want to, can be wielded for good.

Similarly, checking ourselves out of content silos — a hallmark of the modern web experience — takes power away from web monopolies like Google, Facebook, and Twitter. We’re so used to third party platforms deciphering and presenting information that we forget they’re not strictly necessary.

“If we had shared formats, shared protocols, we might still end up with certain providers playing a large role in certain markets — think of Gmail for email — but everyone is free to move to another provider, and the market remains competitive.”

— Denny Vrandečić, Abstract Wikipedia creator

The Semantic Web is silo-less; it is free, open, and abstract, enabling communication between different languages and platforms that would be far more difficult otherwise.

Data-fying Online Content

Designing for the Semantic Web boils down to data-fying online content — looking at your content and seeing what can (and should) be abstracted. What does this mean in practical terms, beyond vaguely agreeing it’s a worthwhile thing to do? It depends:

  1. If starting a project from scratch, incorporate Semantic Web considerations into what you do. As a website takes shape, weave semantic markup into its DNA.
  2. If updating or rebuilding a project, assess what could be woven into the Semantic Web that currently isn’t, then implement.

Both cases basically amount to data-fying content. In this section, we will go through some examples of data abstraction and how it can make content better, smarter, and more widely available.

Abstracting Information

Designing and developing for the Semantic Web means looking at online content with your data hat on. Most of us experience the web as a series of connecting documents or pages; what you want to do with the Semantic Web is connect information. This means assessing your content for data points then adjusting the design based on what you find.

Semantic Web advocate James Hendler outlines this process particularly well with his DIVE ethos. (DIVE into the data, eh? Eh?). It breaks down as follows:

  • Discover
    Find datasets and/or content (including outside your own organization).
  • Integrate
    Link the relations using meaningful labels.
  • Validate
    Provide inputs to modeling and simulation systems.
  • Explore
    Develop approaches to turn data into actionable knowledge.

Developing for the Semantic Web is largely about having that birds-eye view of the things you make, and how it potentially feeds into infinitely richer web experiences. As Hendler says, actionable knowledge is the goal.

This really can be applied to almost any type of web content, but let’s start with a common example: recipes. Let’s say you run a cooking blog, with new recipes every Thursday. If you’re French and post a smashing soufflé recipe on your personal blog in plain text, it’s only useful to those who can read French.

However, by implementing semantic markup the blog can be transformed into a machine-readable recipe data set. Syntax exists for cooking terms to be abstracted. Schema, for example, which can work alongside Microdata, RDFa, or JSON-LD, has markup including:

  • prepTime
  • cookTime
  • recipeYield
  • recipeIngredient
  • estimatedCost
  • nutrition, breaking down into calories and fatContent
  • suitableForDiet.

I could go on. The full range of options, with examples, can be read at Schema.org. In adding them to the post format the format of the recipe needn’t change at all — you’re simply putting the information in terms computers can understand.

For example, everything highlighted blue in the BBC recipe above has also been given semantic markup — from cooking time to nutritional content. You can see what’s going on under the hood by entering the recipe URL into Google’s Rich Results Test. Note the ‘Add to shopping list’ functionality, an example of connection made possible by Semantic Web implementation. Good content becomes usable data.

Most of us have crossed paths with this kind of sophistication via search results, but the applications are much wider than that. Semantic markup of recipes makes it easier for websites to be found and used by home assistants. Listed ingredients can be ordered from the local supermarket. Recipes could be filtered in all sorts of ways — for diets, allergies, religion, cost, you name it. Or let’s say you had a limited number of ingredients in the house. With a database you could input those ingredients and see what recipes fit the bill.

The range of possibilities really do border on limitless. As Swartz said, data is protean. Once you have it you can use it in all sorts of weird and wonderful ways. This piece is not about those weird and wonderful ways so much as it is about making them possible. Designing for the Semantic Web makes subsequent design infinitely richer.

Here’s a more personal example to show what I mean. A couple of friends and I run a little music webzine as a hobby. Though we publish the odd article or interview, the ‘main event’ is our weekly album reviews, in which the three of us each assign a score, choose favorite tracks, and write summaries. We’ve been going for more than five years, which means we have close to 250 reviews, which means an awful lot of potential data. We didn’t realize how much until we started redesigning the site.

I touched upon this in a piece about baking structured data into the design process. In dissecting our reviews we realized they were chock full of information that could be given semantic markup. Artists, album names, artwork, release date, individual scores, overall scores, release type, and more. What’s more — and this is where it gets really exciting — we realized we could connect to an existing database: MusicBrainz.

This two-way approach is the crux of the Semantic Web. When our music website relaunches it will be its own open data source with thousands of unique data points. Connecting to an existing music database will give our own data more context — and potential. Thousands of data points becomes tens of thousands of data points, maybe more.

The graphic above only scratches the surface of how much information will be connected to reviews pages. The content is the same as it was before, only now it is plugged into a metadata ecosystem — the Giant Global Graph, as Berners-Lee once called it.

Developing for the Semantic Web means identifying your own data, markup it up, then sussing out how it connects to other data. Because it does. It always does. And that process is how this…

… in time becomes this…

The second image is The Linked Open Data Cloud, a constantly updating visualization of the web’s connected data. That red hive of connections is the sciences; the rest has some way to go. That’s where we come in.

Useful Semantic Web Resources

Plugging In

The ideal of the Semantic Web is connection. Make data, share data, demand data. Be part of an information ecosystem. When you’re creating original data, great. Share it. When data already exists and you’d like to use it, pull it in.

Here are just a handful of the data resources out there:

Indeed, where databases like these exist, I’d go so far as to say the right thing to do would be update them where they’re lacking information. Why keep it to yourself? Become a contributor, a Semantic Web advocate.

Implementation

As far as building Semantic Webness into your sites goes, I’m certainly not advocating manual, doc-by-doc markup. Who’s got time for that? More often than not the solution is a case of standardizing a format and templating for it.

Templating is the big opportunity here. How many people really have time to markup all that information manually? However, if you have custom inputs, you get the best of both worlds. Content can be filled with people-friendly information and the information exists as data ready to serve whatever purpose comes to mind.

Take, for example, a static site generator like Eleventy, which has been enjoying a bit of a love-in from the dev community lately. You write a post, run it through a template, and you’re golden. So why not incorporate semantic markup into the template itself?

Like Eleventy, the new version of our music webzine site uses Markdown for its posts. While we have the same old text posts we always did, every review now also includes the following metadata inputs, which are then pulled into the template:

Together with author details in the body of the post and some generic website info, this then translates to the following semantic markup:

<script type="application/ld+json">     {   "@context": "http://schema.org/",   "@type": "Review",   "reviewBody": "One of the definitive albums released by, quite possibly, the greatest singer-songwriter we've ever seen. To those looking to probe Young's daunting discography: start here.",   "datePublished": "2020-08-14",   "author": [{     "@type": "Person",     "name": "André Dack"   },              {     "@type": "Person",     "name": "Frederick O'Brien"   },              {     "@type": "Person",     "name": "Marcus Lawrence"   }],   "itemReviewed": {     "@type": "MusicAlbum",       "name": "After the Gold Rush",       "@id": "https://musicbrainz.org/release-group/b6a3952b-9977-351c-a80a-73e023143858",       "image": "https://audioxide.com/images/album-artwork/after-the-gold-rush-neil-young.jpg",       "albumProductionType": "http://schema.org/StudioAlbum",     "albumReleaseType": "http://schema.org/AlbumRelease",       "byArtist": {         "@type": "MusicGroup",         "name": "Neil Young",         "@id": "https://musicbrainz.org/artist/75167b8b-44e4-407b-9d35-effe87b223cf"       }   },   "reviewRating": {     "@type": "Rating",     "ratingValue": 27,     "worstRating": 0,     "bestRating": 30   },   "publisher": {       "@type": "Organization",       "name": "Audioxide",       "description": "Independent music webzine founded in 2015. Publishes reviews, articles, interviews, and other oddities.",       "url": "https://audioxide.com",       "logo": "https://audioxide.com/logo-location.jpg",       "sameAs" : [     "https://facebook.com/audioxide",     "https://twitter.com/audioxide",     "https://instagram.com/audioxidecom"   ]     } }      </script>

Where before there was just text, on every single review page there will now also be machine-readable versions of what readers see when they visit the site. The words are all still there, the content has barely changed at all — it’s just been data-fyed. From rich search results to interactive review statistics pages, this massively increases what’s possible. The road ahead is wide and open. It also gives us a stake in MusicBrainz’s future. By connecting their data to our own data, we in turn want to see it do well, and will do our part to ensure it does.

The appropriate semantic markup depends on the nature of a website, but odds are it exists. Start with the obvious inputs (date, author, content type, etc.) and work your way into the weeds of the content. The first step could be as simple as a hCard (a kind of digital ID card) for your personal website. Print out screenshots of pages and start annotating. You’ll be amazed by how much content can be data-fyed.

Beyond Imagination

Designing and developing for the Semantic Web is a practice that dates back to the Internet’s founding ideals. Whether you value beautiful, informative data visualization, want more sophisticated search results, wish to remove power from web monopolies, or simply believe in free and open information, the Semantic Web is your ally.

Aaron Swartz closed his manuscript with a call to hope:

“The Semantic Web is based on bet, a bet that giving the world tools to easily collaborate and communicate will lead to possibilities so wonderful we can scarcely even imagine them right now.”

Abstract Wikipedia Denny Vrandečić echoes those sentiments today, saying:

“There’s a need for a web infrastructure that will facilitate interoperability between services, which requires a common set of standards for representing data, and common protocols across providers.”

The Semantic Web has limped along long enough for it to be clear that a silver bullet language is unlikely to appear, but there are enough now peacefully coexisting for Berners-Lee’s founding dream to be a reality for most of the web. Each of us can be advocates in our own neighborhoods.

Be Better, Demand Better

As Tim Berners-Lee has said, the Semantic Web is a culture as much as it is a technical hurdle. In a 2009 TED Talk he summed it up nicely: make linked data, demand linked data. That’s truer now than ever. The World Wide Web is only as open and connected and good as we force it to be. Whenever you make something online ask yourself, “How can this plug into the Semantic Web?” The answers will add new dimensions to the things we create, and create unimaginably wonderful new possibilities for years to come.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
2-developing-custom-plugin-for-october-cms
08 Oct

Developing A Custom Plugin For October CMS

by TBSCategories: News

Developing A Custom Plugin For October CMS

Developing A Custom Plugin For October CMS

Andriy Haydash

Last year, I did some research about new CMS systems in PHP in order to find a good alternative to WordPress. Ideally, it had to be an open-source solution with a clean and modern codebase.

One of them caught my interest: October CMS. I tried it and almost instantly liked it. The code structure was really nice and it was easy to write custom plugins.

This article aims to give you an overview of what to expect from the platform and give you a taste of it before you decide to commit to using it.

Why Choose October As Your CMS Platform?

There are a few main reasons why I have personally decided to use it for my projects.

Powered By Laravel

October is built on top of the most powerful PHP framework for creating modern web apps: Laravel. I can say with great confidence that it’s the best. It is very easy to use and understand, and has all the features that a modern framework needs, from routing, object-relational mapping (ORM), authorization, caching, and many others that provide a nice and clear MVC structure. As it is powered by Laravel, October has inherited all those features from its big brother.

Clean Code And Documentation

Unlike many other CMS solutions, October has a very clean and well-documented codebase. It’s written in using an objectoriented paradigm. Instead of plain old PHP, October uses Twig as its templating engine, which simplifies things for developers. Technical documentation is also well written, and helps you quickly find answers to most of your questions.

Great Community

Even though October’s community is not yet that big, it’s very helpful and responsive. There is a public Slack channel you can join, where you’ll find developers happy to assist you in fixing your issue.

Big Marketplace

Like WordPress and other CMSes, October has a marketplace for themes and plugins. Even though there aren’t that many good themes to choose from, there are over 700 plugins right now, so it’s very likely you’ll be able to add functionality by simply searching for and installing one of them. A great feature of plugins is that they can be easily synchronized between all your projects if you just add your project ID in the admin dashboard.

PlugIns And Components

Plugins are a foundation of adding new functionality to October. A plugin can consist of multiple files and directories that are responsible for registering custom components, models, updating database structure, or adding translations.

A plugin is usually created in the plugins/ directory of the project. Since many plugins are submitted to the marketplace for others to use, each plugin should have a custom namespace, which usually starts with the name of the company or developer that created the plug-in. So, for instance, if your name is Acme and you’ve created an awesome plugin called Blog, your plugin will live under the namespace of AcmeBlog.

Let me show you how a plugin directory structure might look like:

Sample plugin directory structure
Sample plugin directory structure (Large preview)

As you can see, there is also a file called plugin.php that is responsible for registering a plugin and all of its components in October CMS.

Another important thing to mention is that not all directories listed above are necessary for a plugin to run. Your plugin could have the following structure and still work perfectly well:

Simple plugin directory structure
Simple plugin directory structure (Large preview)

Most often, one plugin is built to add only one piece of functionality. For example, the ‘Translate’ plugin is designed to help you translate content on your website into different languages, and provide the multi-language support for the users.

October CMS has a great marketplace where you can find for your needs.

October marketplace
October marketplace (Large preview)

Unlike WordPress and other popular CMSes, October plugins can also have components. According to October’s documentation, components are “configurable building elements that can be attached to any page, partial or layout.” Examples might include: a contact form, navigation, a list of FAQs and their answers; basically anything that it makes sense to bundle together as one building block that can be reused on multiple pages.

Components are created as a part of a plugin and they exist in the components/ subdirectory:

Component directory structure
Component directory structure (Large preview)

Each component has a PHP file like componentName.php that defines the component, as well as an optional subdirectory for component partials. A component partials folder must have the same name in lowercase as the component itself.

To demonstrate how a component functions, let’s assume that our component is responsible for showing blog posts.

namespace AcmeBlogComponents;  class BlogPosts extends CmsClassesComponentBase {     public function componentDetails()     {         return [             'name' => 'Blog Posts',             'description' => 'Displays a collection of blog posts.'         ];     }      // This array becomes available on the page as {{ component.posts }}     public function posts()     {         return ['First Post', 'Second Post', 'Third Post'];     } }

As we can see, the component has two main functions. The first one, componentDetails(), provides information about the component to the administrator who will add and use components on their web pages.

The second function, posts(), returns dummy posts that can then be used inside a component partial (blogposts/default.htm file) like this:

url = "/blog"  [blogPosts] == {% for post in blogPosts.posts %}     {{ post }} {% endfor %}

For October CMS to know our component exists, we must register it using our main plugin file inside a function named registerComponents():

public function registerComponents() {     return [         'OctoberDemoComponentsTodo' => 'demoTodo'     ]; }

Creating A Custom Contact Form plugin

We’re going to create a custom contact form plug-in. Here are the assumptions about how the plugin should work:

  • The form will have the following fields: First Name, Last Name, Email, Message.
  • Data will be submitted to the server using Ajax.
  • After data is submitted, the admin will receive an email with the message sent by the user.

For the purpose of this tutorial we will use a fresh installation of October CMS:

Default view after fresh installation
Default view after fresh installation (Large preview)

Let’s start creating our plugin by running a command in a terminal that will generate the plugin structure: php artisan create:plugin progmatiq.contactform

Creating a new plugin from terminal
Creating a new plugin from terminal (Large preview)

The progmatiq.contactform argument contains the name of the author (progmatiq) and the name of the plugin (contactform).

New plugin folder structure
New plugin folder structure (Large preview)

Now we need to open our plugin.php file and modify the plugin details in the following method:

public function pluginDetails()    {         return [             'name'        => 'Contact Form',             'description' => 'A simple contact form plug-in',             'author'      => 'progmatiq',             'icon'        => 'icon-leaf'         ];     }

Here are a few other methods that you should take a look at:

  • registerComponents()
    Here you can define an array of components that your plugin provides.
  • registerPermissions()
    You can register custom permissions that you can then use later in other areas of the application.
  • registerNavigation()
    You can add a custom menu item with a URL to your admin dashboard menu.

Now let’s create our ContactForm component:

  1. Make a new folder named components/ inside your plug-in’s root directory.
  2. Create a file named contactForm.php inside the components/ folder.
    3. Creating a new component
    Creating a new component (Large preview)
  3. Paste the following code that will tell October what our component does. We can do it by creating a method inside our component called componentDetails().
<?php  namespace ProgmatiqContactformComponents;  use CmsClassesComponentBase;  class ContactForm extends ComponentBase {     public function componentDetails()     {         return [             'name' => 'Contact Form',             'description' => 'A simple contact form'         ];     } }

Now we need to register our component inside the plug-in. To do that, we modify the registerComponents() method:

    public function registerComponents()     {         return [             'ProgmatiqContactformComponentsContactForm' => 'contactForm',         ];     }

This function returns an array of components that our plugin provides. The component’s full class name is a key in this method, and a value is an alias that we’ll use to reference our component inside our Twig templates.

Once we have registered the component, we can create a new contact page and add our component (numbers in the steps refer to the screenshot):

  1. In your admin dashboard go to CMS (1) > Pages (2) and click on + Add (3).
  2. Give your page a name and a URL (4).
  3. Name your file (5) and select the default layout (6).
Creating a contact page
Creating a contact page (Large preview)

Let’s add our new component to the page:

  1. Click on Components in the left menu (1) and then select our “Contact Form” component. Once you click on it (2), it should be added to the page.
  2. We need to place a piece of code that would give our page a headline as well as render the component using the {% component ‘contactForm’ %} Twig directive:
<div class="container">     <h1> Contact </h1>     {% component 'contactForm' %} </div>
Adding contact form component to contact form page
Adding contact form component to contact form page (Large preview)

If you open your contact page right now, you will see the headline saying “Contact” and nothing else.

Contact page
Contact page (Large preview)

That’s because our contact form doesn’t have any HTML to render.

We need to create a contactform/default.htm file inside our components/ folder.

Adding a html view to our component
Adding an HTML view to our component (Large preview)

And add the following HTML code to the file:

<form method="POST"      data-request="onSend"     data-request-validate     data-request-success="this.reset(); alert('Thank you for submitting your inquiry')" >     <div>                  <label for="first_name">First Name</label>         <input type="text" name="first_name" class="form-control">         <p data-validate-for="first_name" class="text-danger"></p>      </div>      <div>         <label for="last_name">Last Name</label>         <input type="text" name="last_name" class="form-control">          <p data-validate-for="last_name" class="text-danger"></p>      </div>      <div>         <label for="email">Email</label>         <input type="text" name="email" class="form-control">         <p data-validate-for="email" class="text-danger"></p>      </div>      <div>         <label for="content">Content</label>         <textarea rows="6" cols="20" name="content" class="form-control"></textarea>         <p data-validate-for="content"  class="text-danger"></p>      </div>      <div>         <button type="submit" class="btn btn-primary" data-attach-loading>Send</button>     </div> </form>

Most of this code is pretty straightforward. However, it is flavored with special data-* attributes that October allows us to use:

  1. <form> tag has three special attributes:
    • data-request="onSend". This attribute tells October that the onSend function from our component (that we’re going to create next) has to be called when the form is submitted using Ajax.
    • data-request-validate will enable form Ajax validation using errors that will be sent from the server if the form is invalid.
    • data-request-success="this.reset(); alert('Thank you for submitting your inquiry')" clears the form and then triggers the alert message if the request was successful and no validation or server-side errors were present.
  2. Every input has a following block that is responsible for displaying validation errors returned by the server for that given input:
    3. <p data-validate-for="content"  class="text-danger"></p>
  3. The submit button has the data-attach-loading attribute, which will add a spinner and disable the button while the request is being processed by the server. This is done in order to prevent the user submitting a form again until the previous request is complete.

And here is how our page looks now:

Contact page view
Contact page view (Large preview)

Let’s go back to our contactForm.php component and create the onSend() as well as validate() helper method that will be responsible for handling form submission:

public function onSend()     {         // Get request data         $ data = Input::only([             'first_name',             'last_name',             'email',             'content'         ]);          // Validate request         $ this->validate($ data);          // Send email         $ receiver = 'admin@gmail.com';          Mail::send('progmatiq.contact::contact', $ data, function ($ message) use ($ receiver) {             $ message->to($ receiver);         });     }      protected function validate(array $ data)      {         // Validate request         $ rules = [             'first_name' => 'required|min:3|max:255',             'last_name' => 'required|min:3|max:255',             'email' => 'required|email',             'content' => 'required',         ];          $ validator = Validator::make($ data, $ rules);          if ($ validator->fails()) {             throw new ValidationException($ validator);         }     }

The first thing we’re doing is getting data from the request and validating it using the validate() helper method. (All the available validation rules you can use can be found in the documentation.) If validation fails, the validate() method will throw the ValidationException an exception and code execution will stop, and the server will respond with status code 406 and with validation messages.

If validation succeeds, then we will send an email to our admin.

Note: For simplicity, I’ve assumed that the email we want to send the submission to is admin@gmail.com. Make sure to use your own email!

Here is the full code of your contactForm.php plug-in:

<?php  namespace ProgmatiqContactformComponents;  use CmsClassesComponentBase; use OctoberRainExceptionValidationException;  class ContactForm extends ComponentBase {     public function componentDetails()     {         return [             'name' => 'Contact Form',             'description' => 'A simple contact form'         ];     }      public function onSend()     {         // Get request data         $ data = Input::only([             'first_name',             'last_name',             'email',             'content'         ]);          // Validate request         $ this->validate($ data);          // Send email         $ receiver = 'admin@gmail.com';          Mail::send('progmatiq.contact::contact', $ data, function ($ message) use ($ receiver) {             $ message->to($ receiver);         });     }      protected function validate(array $ data)      {         // Validate request         $ rules = [             'first_name' => 'required|min:3|max:255',             'last_name' => 'required|min:3|max:255',             'email' => 'required|email',             'content' => 'required',         ];          $ validator = Validator::make($ data, $ rules);          if ($ validator->fails()) {             throw new ValidationException($ validator);         }     } }

As you can see, the first argument that the Mail::send() function accepts is the name of the email template that will be rendered for the email body. We need to create it in the admin panel. Go to Settings > Mail Templates and click on the New Template button. Then fill out the form as it is shown on the screen below:

Adding new email template
Adding new email template (Large preview)

Here is the body of the email that we’re going to be using:

You have received a new contact inquiry  **First Name**: {{ first_name }} *** **Last Name**: {{ last_name }} *** **Email**: {{ email }} *** **Message**: {{ content }} ***

Now save the email template. The next thing we need to do is configure the SMTP server that will send emails.

Go to Settings > Mail Configuration and fill out all the settings.

Email server configuration
Email server configuration (Large preview)

Obviously, I won’t share my personal configuration. Use your own settings. 😉

At this stage we have everything ready to start testing our contact form component.

First, let’s check if validation works when we leave the “Content” field empty and input an invalid email:

Contact form validation
Contact form validation (Large preview)

Validation works as expected. Let’s now input correct data and see if the email will be sent successfully to our admin.

Here is the email that admin@gmail.com will receive:

Contact form submission email
Contact form submission email (Large preview)

After the form is submitted successfully, the user will see an alert message informing him that the operation was successful:

Successful submission of contact form
Successful submission of contact form (Large preview)

Conclusion

In this tutorial, we’ve covered what a plugin and a component are and how to use them with October CMS.

Don’t be afraid to create a custom plugin for your project if you can’t find an existing one that fits your needs. It’s not that difficult and you have full control over it, and you can update or extend it at any time. Even creating a simple contact form plugin like we’ve done today can be useful if you want to then integrate it with other services like Mailchimp or HubSpot.

I hope this tutorial was helpful to you. If you have any questions, don’t hesitate to ask in the comments section below.

Smashing Editorial (dm, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers

lessons-learned-while-developing-wordpress-plugins
25 May

Lessons Learned While Developing WordPress Plugins

by TBSCategories: News

Lessons Learned While Developing WordPress Plugins

Lessons Learned While Developing WordPress Plugins

Jakub Mikita

Every WordPress plugin developer struggles with tough problems and code that’s difficult to maintain. We spend late nights supporting our users and tear out our hair when an upgrade breaks our plugin. Let me show you how to make it easier.

In this article, I’ll share my five years of experience developing WordPress plugins. The first plugin I wrote was a simple marketing plugin. It displayed a call to action (CTA) button with Google’s search phrase. Since then, I’ve written another 11 free plugins, and I maintain almost all of them. I’ve written around 40 plugins for my clients, from really small ones to one that have been maintained for over a year now.

Measuring Performance With Heatmaps

Heatmaps can show you the exact spots that receive the most engagement on a given page. Find out why they’re so efficient for your marketing goals and how they can be integrated with your WordPress site. Read article →

Good development and support lead to more downloads. More downloads mean more money and a better reputation. This article will show you the lessons I’ve learned and the mistakes I’ve made, so that you can improve your plugin development.

1. Solve A Problem

If your plugin doesn’t solve a problem, it won’t get downloaded. It’s as simple as that.

Take the Advanced Cron Manager plugin (8,000+ active installations). It helps WordPress users who are having a hard time debugging their cron. The plugin was written out of a need — I needed something to help myself. I didn’t need to market this one, because people already needed it. It scratched their itch.

On the other hand, there’s the Bug — fly on the screen plugin (70+ active installations). It randomly simulates a fly on the screen. It doesn’t really solve a problem, so it’s not going to have a huge audience. It was a fun plugin to develop, though.

Focus on a problem. When people don’t see their SEO performing well, they install an SEO plugin. When people want to speed up their website, they install a caching plugin. When people can’t find a solution to their problem, then they find a developer who writes a solution for them.

As David Hehenberger attests in his article about writing a successful plugin, need is a key factor in the WordPress user’s decision of whether to install a particular plugin.

If you have an opportunity to solve someone’s problem, take a chance.

2. Support Your Product

“3 out of 5 Americans would try a new brand or company for a better service experience. 7 out of 10 said they were willing to spend more with companies they believe provide excellent service.”

— Nykki Yeager

Don’t neglect your support. Don’t treat it like a must, but more like an opportunity.

Good-quality support is critical in order for your plugin to grow. Even a plugin with the best code will get some support tickets. The more people who use your plugin, the more tickets you’ll get. A better user experience will get you fewer tickets, but you will never reach inbox 0.

Every time someone posts a message in a support forum, I get an email notification immediately, and I respond as soon as I can. It pays off. The vast majority of my good reviews were earned because of the support. This is a side effect: Good support often translates to 5-star reviews.

When you provide excellent support, people start to trust you and your product. And a plugin is a product, even if it’s completely free and open-source.

Good support is more complex than about writing a short answer once a day. When your plugin gains traction, you’ll get several tickets per day. It’s a lot easier to manage if you’re proactive and answer customers’ questions before they even ask.

Here’s a list of some actions you can take:

  • Create an FAQ section in your repository.
  • Pin the “Before you ask” thread at the top of your support forum, highlighting the troubleshooting tips and FAQ.
  • Make sure your plugin is simple to use and that users know what they should do after they install it. UX is important.
  • Analyze the support questions and fix the pain points. Set up a board where people can vote for the features they want.
  • Create a video showing how the plugin works, and add it to your plugin’s main page in the WordPress.org repository.

It doesn’t really matter what software you use to support your product. The WordPress.org’s official support forum works just as well as email or your own support system. I use WordPress.org’s forum for the free plugins and my own system for the premium plugins.

3. Don’t Use Composer

Composer is package-manager software. A repository of packages is hosted on packagist.org, and you can easily download them to your project. It’s like NPM or Bower for PHP. Managing your third-party packages the way Composer does is a good practice, but don’t use it in your WordPress project.

I know, I dropped a bomb. Let me explain.

Composer is great software. I use it myself, but not in public WordPress projects. The problem lies in conflicts. WordPress doesn’t have any global package manager, so each and every plugin has to load dependencies of their own. When two plugins load the same dependency, it causes a fatal error.

There isn’t really an ideal solution to this problem, but Composer makes it worse. You can bundle the dependency in your source manually and always check whether you are safe to load it.

Composer’s issue with WordPress plugins is still not solved, and there won’t be any viable solution to this problem in the near future. The problem was raised many years ago, and, as you can read in WP Tavern’s article, many developers are trying to solve it, without any luck.

The best you can do is to make sure that the conditions and environment are good to run your code.

4. Reasonably Support Old PHP Versions

Don’t support very old versions of PHP, like 5.2. The security issues and maintenance aren’t worth it, and you’re not going to earn more installations from those older versions.

The Notification plugin’s usage on PHP versions from May 2018. (Large preview)

Go with PHP 5.6 as a minimal requirement, even though official support will be dropped by the end of 2018. WordPress itself requires PHP 7.2.

There’s a movement that discourages support of legacy PHP versions. The Yoast team released the Whip library, which you can include in your plugin and which displays to your users important information about their PHP version and why they should upgrade.

Tell your users which versions you do support, and make sure their website doesn’t break after your plugin is installed on too low a version.

5. Focus On Quality Code

Writing good code is tough in the beginning. It takes time to learn the “SOLID” principles and design patterns and to change old coding habits.

It once took me three days to display a simple string in WordPress, when I decided to rewrite one of my plugins using better coding practices. It was frustrating knowing that it should have taken 30 minutes. Switching my mindset was painful but worth it.

Why was it so hard? Because you start writing code that seems at first to be overkill and not very intuitive. I kept asking myself, “Is this really needed?” For example, you have to separate the logic into different classes and make sure each is responsible for a single thing. You also have to separate classes for the translation, custom post type registration, assets management, form handlers, etc. Then, you compose the bigger structures out of the simple small objects. That’s called dependency injection. That’s very different from having “front end” and “admin” classes, where you cram all your code.

The other counterintuitive practice was to keep all actions and filters outside of the constructor method. This way, you’re not invoking any actions while creating the objects, which is very helpful for unit testing. You also have better control over which methods are executed and when. I wish I knew this before I wrote a project with an infinite loop caused by the actions in the constructor methods. Those kinds of bugs are hard to trace and hard to fix. The project had to be refactored.

The above are but a few examples, but you should get to know the SOLID principles. These are valid for any system and any coding language.

When you follow all of the best practices, you reach the point where every new feature just fits in. You don’t have to tweak anything or make any exceptions to the existing code. It’s amazing. Instead of getting more complex, your code just gets more advanced, without losing flexibility.

Also, format your code properly, and make sure every member of your team follows a standard. Standards will make your code predictable and easier to read and test. WordPress has its own standards, which you can implement in your projects.

6. Test Your Plugin Ahead Of Time

I learned this lesson the hard way. Lack of testing led me to release a new version of a plugin with a fatal error. Twice. Both times, I got a 1-star rating, which I couldn’t turn into a positive review.

You can test manually or automatically. Travis CI is a continuous testing product that integrates with GitHub. I’ve built a really simple test suite for my Notification plugin that just checks whether the plugin can boot properly on every PHP version. This way, I can be sure the plugin is error-free, and I don’t have to pay much attention to testing it in every environment.

Each automated test takes a fraction of a second. 100 automated tests will take about 10 minutes to complete, whereas manual testing needs about 2 minutes for each case.

The more time you invest in testing your plugin up front, the more it will save you in the long run.

To get started with automated testing, you can use the WP-CLI `wp scaffold plugin-test` command, which installs all of the configuration you need.

7. Document Your Work

It’s a cliche that developers don’t like to write documentation. It’s the most boring part of the development process, but a little goes a long way.

Write self-documenting code. Pay attention to variable, function and class names. Don’t make any complicated structures, like cascades that can’t be read easily.

Another way to document code is to use the “doc block”, which is a comment for every file, function and class. If you write how the function works and what it does, it will be so much easier to understand when you need to debug it six months from now. WordPress Coding Standards covers this part by forcing you to write the doc blocks.

Using both techniques will save you the time of writing the documentation, but the code documentation is not going to be read by everyone.

For the end user, you have to write high-quality, short and easy-to-read articles explaining how the system works and how to use it. Videos are even better; many people prefer to watch a short tutorial than read an article. They are not going to look at the code, so make their lives easier. Good documentation also reduces support tickets.

Conclusion

These seven rules have helped me develop good-quality products, which are starting to be a core business at BracketSpace. I hope they’ll help you in your journey with WordPress plugins as well.

Let me know in the comments what your golden development rule is or whether you’ve found any of the above particularly helpful.

Smashing Editorial (il, ra, yk)


Articles on Smashing Magazine — For Web Designers And Developers

advertisement-23
30 May

Developing A Chatbot Using Microsoft’s Bot Framework, LUIS And Node.js (Part 1)

by TBSCategories: News

   

This tutorial gives you hands-on access to my journey of creating a digital assistant capable of connecting with any system via a RESTful API to perform various tasks.

Developing A Chatbot Using Microsoft Bot Framework, LUIS And Node.js (Part 1)

Here, I’ll be demonstrating how to save a user’s basic information and create a new project on their behalf via natural language processing (NLP).

The post Developing A Chatbot Using Microsoft’s Bot Framework, LUIS And Node.js (Part 1) appeared first on Smashing Magazine.

Smashing Magazine

advertisement-19
26 Sep

Developing For Virtual Reality: What We Learned

by TBSCategories: News

   

With the tools getting more user-friendly and affordable, virtual reality (VR) development is easier to get involved in than ever before. Our team at Clearbridge Mobile recently jumped on the opportunity to develop immersive VR content for the Samsung Gear VR, using Samsung’s 360 camera.

Developing For Virtual Reality: What We Learned

The result is ClearVR, a mobile application demo that enables users to explore the features, pricing, interiors and exteriors of listed vehicles. Developing this demo project gave us a better understanding of VR development for our future projects, including scaling, stereoscopic display and motion-tracking practices. This article is an introductory guide to developing for VR, with the lessons we learned along the way.

The post Developing For Virtual Reality: What We Learned appeared first on Smashing Magazine.

Smashing Magazine

advertisement-24
23 May

Developing Dependency Awareness

by TBSCategories: News

  

I’m sure you’ve heard the proverb, “A chain is only as strong as its weakest link,” probably many times. Its written origin dates back to the 18th century, but I wouldn’t be surprised if it was much, much older. And though the work we do has little to do with actual chains, this proverb is every bit as relevant to us.

Developing Dependency Awareness

Remember when Azer Koçulu unpublished more than 250 of his modules from npm (Node Package Manager)? If that name doesn’t ring a bell, perhaps this function name will: left-pad. In case you’re still scratching your head wondering what the heck I’m talking about, Azer removed a bunch of functions from the canonical library of reusable Node.js code and, in doing so, brought thousands of projects to their knees, including high-profile ones like Babel and React.

The post Developing Dependency Awareness appeared first on Smashing Magazine.

Smashing Magazine

×

Powered by WhatsApp Chat

WhatsApp Chat is free, download and try it now here!

× Chat with Us