Tag Archives: database

Hit The Ground Running With Vue.js And Firestore




Hit The Ground Running With Vue.js And Firestore

Lukas van Driel



Google Firebase has a new data storage possibility called ‘Firestore’ (currently in beta stage) which builds on the success of the Firebase Realtime Database but adds some nifty features. In this article, we’ll set up the basics of a web app using Vue.js and Firestore.

Let’s say you have this great idea for a new product (e.g. the next Twitter, Facebook, or Instagram, because we can never have too much social, right?). To start off, you want to make a prototype or Minimum Viable Product (MVP) of this product. The goal is to build the core of the app as fast as possible so you can show it to users and get feedback and analyze usage. The emphasis is heavily on development speed and quick iterating.

But before we start building, our amazing product needs a name. Let’s call it “Amazeballs.” It’s going to be legen — wait for it — dary!

Here’s a shot of how I envision it:


Screenshot of Amazeballs app


The legendary Amazeballs app

Our Amazeballs app is — of course — all about sharing cheesy tidbits of your personal life with friends, in so-called Balls. At the top is a form for posting Balls, below that are your friends’ Balls.

When building an MVP, you’ll need tooling that gives you the power to quickly implement the key features as well as the flexibility to quickly add and change features later on. My choice falls on Vue.js as it’s a Javascript-rendering framework, backed by the Firebase suite (by Google) and its new real-time database called Firestore.

Firestore can directly be accessed using normal HTTP methods which makes it a full backend-as-a-service solution in which you don’t have to manage any of your own servers but still store data online.

Sounds powerful and daunting, but no sweat, I’ll guide you through the steps of creating and hosting this new web app. Notice how big the scrollbar is on this page; there’s not a huge amount of steps to it. Also, if you want to know where to put each of the code snippets in a code repository, you can see a fully running version of Amazeballs on github.

Let’s Start

We’re starting out with Vue.js. It’s great for Javascript beginners, as you start out with HTML and gradually add logic to it. But don’t underestimate; it packs a lot of powerful features. This combination makes it my first choice for a front-end framework.

Vue.js has a command-line interface (CLI) for scaffolding projects. We’ll use that to get the bare-bones set-up quickly. First, install the CLI, then use it to create a new project based on the “webpack-simple” template.

npm install -g vue-cli

vue init webpack-simple amazeballs

If you follow the steps on the screen (npm install and npm run dev) a browser will open with a big Vue.js logo.

Congrats! That was easy.

Next up, we need to create a Firebase project. Head on over to https://console.firebase.google.com/ and create a project. A project starts out in the free Spark plan, which gives you a limited database (1 GB data, 50K reads per day) and 1 GB of hosting. This is more than enough for our MVP, and easily upgradable when the app gains traction.

Click on the ‘Add Firebase to your web app’ to display the config that you need. We’ll use this config in our application, but in a nice Vue.js manner using shared state.

First npm install firebase, then create a file called src/store.js. This is the spot that we’re going to put the shared state in so that each Vue.js component can access it independently of the component tree. Below is the content of the file. The state only contains some placeholders for now.

import Vue from 'vue';
import firebase from 'firebase/app';
import 'firebase/firestore';

// Initialize Firebase, copy this from the cloud console
// Or use mine :)
var config = 
  apiKey: "AIzaSyDlRxHKYbuCOW25uCEN2mnAAgnholag8tU",
  authDomain: "amazeballs-by-q42.firebaseapp.com",
  databaseURL: "https://amazeballs-by-q42.firebaseio.com",
  projectId: "amazeballs-by-q42",
  storageBucket: "amazeballs-by-q42.appspot.com",
  messagingSenderId: "972553621573"
;
firebase.initializeApp(config);

// The shared state object that any vue component can get access to. 
// Has some placeholders that we’ll use further on!
export const store = 
  ballsInFeed: null,
  currentUser: null,
  writeBall: (message) => console.log(message)
;

Now we’ll add the Firebase parts. One piece of code to get the data from the Firestore:

// a reference to the Balls collection
const ballsCollection = firebase.firestore()
  .collection('balls');

// onSnapshot is executed every time the data
// in the underlying firestore collection changes
// It will get passed an array of references to 
// the documents that match your query
ballsCollection
  .onSnapshot((ballsRef) => 
    const balls = [];
    ballsRef.forEach((doc) => 
      const ball = doc.data();
      ball.id = doc.id;
      balls.push(ball);
    );
    store.ballsInFeed = balls;
  });

And then replace the writeBall function with one that actually executes a write:

writeBall: (message) => ballsCollection.add(
  createdOn: new Date(),
  author: store.currentUser,
  message
)

Notice how the two are completely decoupled. When you insert into a collection, the onSnapshot is triggered because you’ve inserted an item. This makes state management a lot easier.

Now you have a shared state object that any Vue.js component can easily get access to. Let’s put it to good use.

Post Stuff!

First, let’s find out who the current user is.

Firebase has authentication APIs that help you with the grunt of the work of getting to know your user. Enable the appropriate ones on the Firebase Console in AuthenticationSign In Method. For now, I’m going to use Google Login — with a very non-fancy button.


Screenshot of login page with Google authentication


Authentication with Google Login

Firebase doesn’t give you any interface help, so you’ll have to create your own “Login with Google/Facebook/Twitter” buttons, and/or username/password input fields. Your login component will probably look a bit like this:

<template>
  <div>
    <button @click.prevent="signInWithGoogle">Log in with Google</button>
  </div>
</template>

<script>
import firebase from 'firebase/app';
import 'firebase/auth';

export default 
  methods: 
    signInWithGoogle() 
      var provider = new firebase.auth.GoogleAuthProvider();
      firebase.auth().signInWithPopup(provider);
    
  }
}
</script>

Now there’s one more piece of the login puzzle, and that’s getting the currentUser variable in the store. Add these lines to your store.js:

// When a user logs in or out, save that in the store
firebase.auth().onAuthStateChanged((user) => 
  store.currentUser = user;
);

Due to these three lines, every time the currently-logged-in user changes (logs in or out), store.currentUser also changes. Let’s post some Balls!


Screenshot of logout option


Login state is stored in the store.js file

The input form is a separate Vue.js component that is hooked up to the writeBall function in our store, like this:

<template>
  <form @submit.prevent="formPost">
    <textarea v-model="message" />
    <input type="submit" value="DUNK!" />
  </form>
</template>

<script>
import  store  from './store';

export default 
  data() 
    return 
      message: null,
    ;
  },
  methods: 
    formPost() 
      store.writeBall(this.message);
    
  },
}
</script>

Awesome! Now people can log in and start posting Balls. But wait, we’re missing authorization. We want you to only be able to post Balls yourself, and that’s where Firestore Rules come in. They’re made up of Javascript-ish code that defines access privileges to the database. You can enter them via the Firestore console, but you can also use the Firebase CLI to install them from a file on disk. Install and run it like this:

npm install -g firebase-tools
firebase login
firebase init firestore

You’ll get a file named firestore.rules where you can add authorization for your app. We want every user to be able to insert their own balls, but not to insert or edit someone else’s. The below example do nicely. It allows everyone to read all documents in the database, but you can only insert if you’re logged in, and the inserted resource has a field “author” that is the same as the currently logged in user.

service cloud.firestore 
  match /databases/database/documents 
    match /document=** 
      allow read: if true;
      allow create: if request.auth.uid != null && request.auth.uid == request.resource.data.author;
    
  }
}

It looks like just a few lines of code, but it’s very powerful and can get complex very quickly. Firebase is working on better tooling around this part, but for now, it’s trial-and-error until it behaves the way you want.

If you run firebase deploy, the Firestore rules will be deployed and securing your production data in seconds.

Adding Server Logic

On your homepage, you want to see a timeline with your friends’ Balls. Depending on how you want to determine which Balls a user sees, performing this query directly on the database could be a performance bottleneck. An alternative is to create a Firebase Cloud Function that activates on every posted Ball and appends it to the walls of all the author’s friends. This way it’s asynchronous, non-blocking and eventually consistent. Or in other words, it’ll get there.

To keep the examples simple, I’ll do a small demo of listening to created Balls and modifying their message. Not because this is particularly useful, but to show you how easy it is to get cloud functions up-and-running.

const functions = require('firebase-functions');

exports.createBall = functions.firestore
  .document('balls/ballId')
  .onCreate(event => 
    var createdMessage = event.data.get('message');
    return event.data.ref.set(
      message: createdMessage + ', yo!'
    , merge: true);
});

Oh, wait, I forgot to tell you where to write this code.

firebase init functions

This creates the functions directory with an index.js. That’s the file you can write your own Cloud Functions in. Or copy-paste mine if you’re very impressed by it.

Cloud Functions give you a nice spot to decouple different parts of your application and have them asynchronously communicate. Or, in architectural drawing style:


Server logic architectural diagram of Cloud Functions


Asynchronous communication between the different components of your application

Last Step: Deployment

Firebase has its Hosting option available for this, and you can use it via the Firebase CLI.

firebase init hosting

Choose distas a public directory, and then ‘Yes’ to rewrite all URLs to index.html. This last option allows you to use vue-router to manage pretty URLs within your app.

Now there’s a small hurdle: the dist folder doesn’t contain an index.html file that points to the right build of your code. To fix this, add an npm script to your package.json:


  "scripts": 
    "deploy": "npm run build && mkdir dist/dist && mv dist/*.* dist/dist/ && cp index.html dist/ && firebase deploy"
  
}

Now just run npm deploy, and the Firebase CLI will show you the URL of your hosted code!

When To Use This Architecture

This setup is perfect for an MVP. By the third time you’ve done this, you’ll have a working web app in minutes — backed by a scalable database that is hosted for free. You can immediately start building features.

Also, there’s a lot of space to grow. If Cloud Functions aren’t powerful enough, you can fall back to a traditional API running on docker in Google Cloud for instance. Also, you can upgrade your Vue.js architecture with vue-router and vuex, and use the power of webpack that’s included in the vue-cli template.

It’s not all rainbows and unicorns, though. The most notorious caveat is the fact that your clients are immediately talking to your database. There’s no middleware layer that you can use to transform the raw data into a format that’s easier for the client. So, you have to store it in a client-friendly way. Whenever your clients request change, you’re going to find it pretty difficult to run data migrations on Firebase. For that, you’ll need to write a custom Firestore client that reads every record, transforms it, and writes it back.

Take time to decide on your data model. If you need to change your data model later on, data migration is your only option.

So what are examples of projects using these tools? Amongst the big names that use Vue.js are Laravel, GitLab and (for the Dutch) nu.nl. Firestore is still in beta, so not a lot of active users there yet, but the Firebase suite is already being used by National Public Radio, Shazam, and others. I’ve seen colleagues implement Firebase for the Unity-based game Road Warriors that was downloaded over a million times in the first five days. It can take quite some load, and it’s very versatile with clients for web, native mobile, Unity, and so on.

Where Do I Sign Up?!

If you want to learn more, consider the following resources:

Happy coding!

Smashing Editorial
(da, ra, hj, il)


Link: 

Hit The Ground Running With Vue.js And Firestore

How To Streamline WordPress Multisite Migrations With MU-Migration

Migrating a standalone WordPress site to a site network (or “multisite”) environment is a tedious and tricky endeavor, the opposite is also true. The WordPress Importer works reasonably well for smaller, simpler sites, but leaves room for improvement. It exports content, but not site configuration data such as Widget and Customizer configurations, plugins, and site settings. The Importer also struggles to handle a large amount of content. In this article, you’ll learn how to streamline this type of migration by using MU-Migration, a WP-CLI plugin.

Link: 

How To Streamline WordPress Multisite Migrations With MU-Migration

Breaking The Rules: Using SQLite To Demo Web Apps

Most potential users will want to try out the software or service before committing any time and money. Some products work great by just giving users a free trial, while other apps are best experienced with sample data already in place. Often this is where the age-old demo account comes into play.
However, anyone who has ever implemented a demo account can attest to the problems associated. You know how things run on the Internet: Anyone can enter data (whether it makes sense or not to the product) and there is a good chance that the content added by anonymous users or bots could be offensive to others.

See original article here:  

Breaking The Rules: Using SQLite To Demo Web Apps

How to do server-side testing for single page app optimization

Reading Time: 5 minutes

Gettin’ technical.

We talk a lot about marketing strategy on this blog. But today, we are getting technical.

In this post, I team up with WiderFunnel front-end developer, Thomas Davis, to cover the basics of server-side testing from a web development perspective.

The alternative to server-side testing is client-side testing, which has arguably been the dominant testing method for many marketing teams, due to ease and speed.

But modern web applications are becoming more dynamic and technically complex. And testing within these applications is becoming more technically complex.

Server-side testing is a solution to this increased complexity. It also allows you to test much deeper. Rather than being limited to testing images or buttons on your website, you can test algorithms, architectures, and re-brands.

Simply put: If you want to test on an application, you should consider server-side testing.

Let’s dig in!

Note: Server-side testing is a tactic that is linked to single page applications (SPAs). Throughout this post, I will refer to web pages and web content within the context of a SPA. Applications such as Facebook, Airbnb, Slack, BBC, CodeAcademy, eBay, and Instagram are SPAs.


Defining server-side and client-side rendering

In web development terms, “server-side” refers to “occurring on the server side of a client-server system.”

The client refers to the browser, and client-side rendering occurs when:

  1. A user requests a web page,
  2. The server finds the page and sends it to the user’s browser,
  3. The page is rendered on the user’s browser, and any scripts run during or after the page is displayed.
Static app server
A basic representation of server-client communication.

The server is where the web page and other content live. With server-side rendering, the requested web page is sent to the user’s browser in final form:

  1. A user requests a web page,
  2. The server interprets the script in the page, and creates or changes the page content to suit the situation
  3. The page is sent to the user in final form and then cannot be changed using server-side scripting.

To talk about server-side rendering, we also have to talk a little bit about JavaScript. JavaScript is a scripting language that adds functionality to web pages, such as a drop-down menu or an image carousel.

Traditionally, JavaScript has been executed on the client side, within the user’s browser. However, with the emergence of Node.js, JavaScript can be run on the server side. All JavaScript executing on the server is running through Node.js.

*Node.js is an open-source, cross-platform JavaScript runtime environment, used to execute JavaScript code server-side. It uses the Chrome V8 JavaScript engine.

In laymen’s (ish) terms:

When you visit a SPA web application, the content you are seeing is either being rendered in your browser (client-side), or on the server (server-side).

If the content is rendered client-side, JavaScript builds the application HTML content within the browser, and requests any missing data from the server to fill in the blanks.

Basically, the page is incomplete upon arrival, and is completed within the browser.

If the content is being rendered server-side, your browser receives the application HTML, pre-built by the server. It doesn’t have to fill in any blanks.

Why do SPAs use server-side rendering?

There are benefits to both client-side rendering and server-side rendering, but render performance and page load time are two huge pro’s for the server side.

(A 1 second delay in page load time can result in a 7% reduction in conversions, according to Kissmetrics.)

Server-side rendering also enables search engine crawlers to find web content, improving SEO; and social crawlers (like the crawlers used by Facebook) do not evaluate JavaScript, making server-side rendering beneficial for social searching.

With client-side rendering, the user’s browser must download all of the application JavaScript, and wait for a response from the server with all of the application data. Then, it has to build the application, and finally, show the complete HTML content to the user.

All of which to say, with a complex application, client-side rendering can lead to sloooow initial load times. And, because client-side rendering relies on each individual user’s browser, the developer only has so much control over load time.

Which explains why some developers are choosing to render their SPAs on the server side.

But, server-side rendering can disrupt your testing efforts, if you are using a framework like Angular or React.js. (And the majority of SPAs use these frameworks).

The disruption occurs because the version of your application that exists on the server becomes out of sync with the changes being made by your test scripts on the browser.

NOTE: If your web application uses Angular, React, or a similar framework, you may have already run into client-side testing obstacles. For more on how to overcome these obstacles, and successfully test on AngularJS apps, read this blog post.


Testing on the server side vs. the client side

Client-side testing involves making changes (the variation) within the browser by injecting Javascript after the original page has already loaded.

The original page loads, the content is hidden, the necessary elements are changed in the background, and the ‘new’ version is shown to the user post-change. (Because the page is hidden while these changes are being made, the user is none-the-wiser.)

As I mentioned earlier, the advantages of client-side testing are ease and speed. With a client-side testing tool like VWO, a marketer can set up and execute a simple test using a WYSIWYG editor without involving a developer.

But for complex applications, client-side testing may not be the best option: Layering more JavaScript on top of an already-bulky application means even slower load time, and an even more cumbersome user experience.

A Quick Hack

There is a workaround if you are determined to do client-side testing on a SPA application. Web developers can take advantage of features like Optimizely’s conditional activation mode to make sure that testing scripts are only executed when the application reaches a desired state.

However, this can be difficult as developers will have to take many variables into account, like location changes performed by the $routeProvider, or triggering interaction based goals.

To avoid flicker, you may need to hide content until the front-end application has initialized in the browser, voiding the performance benefits of using server-side rendering in the first place.

WiderFunnel - client side testing activation mode
Activation Mode waits until the framework has loaded before executing your test.



When you do server-side testing, there are no modifications being made at the browser level. Rather, the parameters of the experiment variation (‘User 1 sees Variation A’) are determined at the server route level, and hooked straight into the javascript application through a service provider.

Here is an example where we are testing a pricing change:

“Ok, so, if I want to do server-side testing, do I have to involve my web development team?”

Yep.

But, this means that testing gets folded into your development team’s work flow. And, it means that it will be easier to integrate winning variations into your code base in the end.

If yours is a SPA, server-side testing may be the better choice, despite the work involved. Not only does server-side testing embed testing into your development workflow, it also broadens the scope of what you can actually test.

Rather than being limited to testing page elements, you can begin testing core components of your application’s usability like search algorithms and pricing changes.

A server-side test example!

For web developers who want to do server-side testing on a SPA, Tom has put together a basic example using Optimizely SDK. This example is an illustration, and is not functional.

In it, we are running a simple experiment that changes the color of a button. The example is built using Angular Universal and express JS. A global service provider is being used to fetch the user variation from the Optimizely SDK.

Here, we have simply hard-coded the user ID. However, Optimizely requires that each user have a unique ID. Therefore, you may want to use the user ID that already exists in your database, or store a cookie through express’ Cookie middleware.

Are you currently doing server-side testing?

Or, are you client-side testing on a SPA application? What challenges (if any) have you faced? How have you handled them? Do you have any specific questions? Let us know in the comments!

The post How to do server-side testing for single page app optimization appeared first on WiderFunnel Conversion Optimization.

Continue reading – 

How to do server-side testing for single page app optimization

How To Improve Your Billing Form’s UX In One Day

The checkout page is the last page a user visits before finally decide to complete a purchase on your website. It’s where window shoppers turn into paying customers. If you want to leave a good impression, you should provide optimal usability of the billing form and improve it wherever it is possible to. In less than one day, you can add some simple and useful features to your project to make your billing form user-friendly and easy to fill in.

Original article: 

How To Improve Your Billing Form’s UX In One Day

A Look At The Modern WordPress Server Stack

Do you remember when you could run a “fast” WordPress website with just an Apache server and PHP? Yeah, those were the days! Things were a lot less complicated back then.
Now, everything has to load lightning-fast! Visitors don’t have the same expectations about loading times as they used to. A slow website can have serious implications for you or your client.
Further Reading on SmashingMag: Proper WordPress Filesystem Permissions And Ownerships Moving A WordPress Website Without Hassle How To Develop WordPress Locally With MAMP Do-It-Yourself Caching Methods With WordPress Consequently, the WordPress server stack has had to evolve over the years to keep up with this need for speed.

Source:

A Look At The Modern WordPress Server Stack

Thumbnail

Encrypting Blacklisted Words In WordPress With ROT13

Countless algorithms for encrypting data exist in computer science. One of the lesser known and less common encryptions is ROT13, a derivative of the Caesar cypher1 encryption technique.

In this tutorial, we’ll learn about ROT13 encryption and how it works. We’ll see how text (or strings) can be programmatically encoded in ROT13 using PHP. Finally, we’ll code a WordPress plugin that scans a post for blacklisted words and replaces any in ROT13 encryption.

If you own a blog on which multiple authors or certain group of people have the privilege of publishing posts, then a plugin that encrypts or totally removes inappropriate words might come in handy

Introduction

ROT13 (short for “rotate by 13 places,” sometimes abbreviated as ROT-13) is a simple encryption technique for English that replaces each letter with the one 13 places forward or back along the alphabet. So, A becomes N, B becomes O and so on up to M, which becomes Z. Then, the sequence continues at the beginning of the alphabet: N becomes A, O becomes B and so on up to Z, which becomes M.

A major advantage of ROT13 over other rot(N) techniques (where “N” is an integer that denotes the number of places down the alphabet in a Caesar cypher encryption) is that it is “self-inverse,” meaning that the same algorithm is applied to encrypt and decrypt data.

Below is a ROT13 table for easy reference.

| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z |
--------------------------------------------------------------------------------------------------------  
| N | O | P | Q | R | S | T | U | V | W | X | Y | Z | A | B | C | D | E | F | G | H | I | J | K | L | M |

If we encrypted the domain smashingmagazine.com in ROT13, the result would be fznfuvatzntnmvar.pbz, and the sentence “Why did the chicken cross the road?” would become “Jul qvq gur puvpxra pebff gur ebnq?”

Note that only letters in the alphabet are affected by ROT13. Numbers, symbols, white space and all other characters are left unchanged.

Transforming Strings To ROT13 In PHP

PHP includes a function, str_rot13(), for converting a string to its ROT13-encoded value. To encode text in ROT13 using this function, pass the text as an argument to the function.

<?php

echo str_rot13('smashingmagazine.com'); // fznfuvatzntnmvar.pbz

echo str_rot13('The best web design and development blog'); // Gur orfg jro qrfvta naq qrirybczrag oybt

Using ROT13 In WordPress

Armed with this knowledge, I thought of ways it might be handy in WordPress. I ended up creating a plugin that encodes blacklisted words found in posts using ROT13.

The plugin consists of a textearea field (located in the plugin’s settings page) in which you input blacklisted words, which are then saved to the database for later reuse in WordPress posts.

Without further fussing, let’s start coding the plugin.

Setting Up the Plugin

First, include the plugin’s file header2.

<?php

/*
Plugin Name: Rot13 Words Blacklist
Plugin URI: http://smashingmagazine.com/
Description: A simple plugin that detects and encrypts blacklisted words in ROT13
Version: 1.0
Author: Agbonghama Collins
Author URI: http://w3guy.com
Text Domain: rot13
Domain Path: /lang/
License: GPL2
*/

As mentioned, the plugin will have a settings page with a textarea field that collects and saves blacklisted words to WordPress’ database (specifically the options table).

Below is a screenshot of what the plugin’s settings (or admin) page will look like.

Settings page of the plugin.3
(See large version4)

Now that we know what the options page will look like, let’s build it using WordPress’ Settings API5

Building the Settings Page

First, we create a submenu item in the main “Settings” menu by using add_options_page(), with its parent function hooked to admin_menu action.

add_action( 'admin_menu', 'rot13_plugin_menu' );

/**
 * Add submenu to main Settings menu
 */
function rot13_plugin_menu() 
	add_options_page(
		__( 'Rot13 Blacklisted Words', 'rot13' ),
		__( 'Rot13 Blacklisted Words', 'rot13' ),
		'manage_options',
		'rot13-words-blacklist',
		'rot13_plugin_settings_page'
	);

The fifth parameter of add_options_page() is the function’s name (rot13_plugin_settings_page), which is called to output the contents of the page.

Below is the code for rot13_plugin_settings_page().

/**
 * Output the contents of the settings page.
 */
function rot13_plugin_settings_page() 
	echo '<div class="wrap">';
	echo '<h2>', __( 'Rot13 Blacklisted Words', 'rot13' ), '</h2>';
	echo '<form action="options.php" method="post">';
	do_settings_sections( 'rot13-words-blacklist' );
	settings_fields( 'rot13_settings_group' );
	submit_button();

Next, we add a new section to the “Settings” page with add_settings_section(). The textarea field we mentioned earlier will be added to this section with add_settings_field(). Finally, the settings are registered with register_setting().

Below is the code for add_settings_section(), add_settings_field() and register_setting().

	// Add the section
	add_settings_section(
		'rot13_setting_section',
		'',
		'rot13_setting_section_callback_function',
		'rot13-words-blacklist'
	);


	// Add the textarea field to the section.
	add_settings_field(
		'blacklisted_words',
		__( 'Blacklisted words', 'rot13' ),
		'rot13_setting_callback_function',
		'rot13-words-blacklist',
		'rot13_setting_section'
	);

	// Register our setting so that $_POST handling is done for us
	register_setting( 'rot13_settings_group', 'rot13_plugin_option', 'sanitize_text_field' );

The three functions above must be enclosed in a function and hooked to the admin_init action, like so:

/**
 * Hook the Settings API to 'admin_init' action
 */
function rot13_settings_api_init() 
	// Add the section
	add_settings_section(
		'rot13_setting_section',
		'',
		'rot13_setting_section_callback_function',
		'rot13-words-blacklist'
	);


	// Add the textarea field to the section
	add_settings_field(
		'blacklisted_words',
		__( 'Blacklisted words', 'rot13' ),
		'rot13_setting_callback_function',
		'rot13-words-blacklist',
		'rot13_setting_section'
	);

	// Register our setting so that $_POST handling is done for us
	register_setting( 'rot13_settings_group', 'rot13_plugin_option', 'sanitize_text_field' );


add_action( 'admin_init', 'rot13_settings_api_init' );

Lest I forget, here is the code for the rot13_setting_callback_function() and rot13_setting_section_callback_function() functions, which will output the textarea field and the description of the field (at the top of the section), respectively.

/**
 * Add a description of the field to the top of the section
 */
function rot13_setting_section_callback_function() 
	echo '<p>' . __( 'Enter a list of words to blacklist, separated by commas (,)', 'rot13' ) . '</p>';


/**
 * Callback function to output the textarea form field
 */
function rot13_setting_callback_function() 
	echo '<textarea rows="10" cols="60" name="rot13_plugin_option" class="code">' . esc_textarea( get_option( 'rot13_plugin_option' ) ) . '</textarea>';

At this point, we are done building the settings page for the plugin.

Up next is getting the plugin to detect blacklisted words and encrypt them with ROT13.

Detecting Blacklisted Words and Encrypting in ROT13

Here is an overview of how we will detect blacklisted words in a WordPress post:

  • A post’s contents are broken down into individual words and saved to an array ($post_words).
  • The blacklisted words that were saved by the plugin to the database are retrieved. They, too, are broken down into individual words and saved to an array ($blacklisted_words).
  • We iterate over the $post_words arrays and check for any word that is on the blacklist.
  • If a blacklisted word is found, then str_rot13() encodes it in ROT13.

It’s time to create the PHP function (rot13_filter_post_content()) that filters the contents of a post and then actually detects blacklisted words and encrypts them in ROT13.

Below is the code for the post’s filter.

/**
 * Encrypt every blacklisted word in ROT13
 *
 * @param $content string post content to filter
 *
 * @return string
 */
function rot13_filter_post_content( $content ) 

	// Get the words marked as blacklisted by the plugin
	$blacklisted_words = esc_textarea( get_option( 'rot13_plugin_option' ) );

    // If no blacklisted word are defined, return the post's content.
	if ( empty( $blacklisted_words ) ) 
		return $content;
	

	else 

		// Ensure we are dealing with "posts", not "pages" or any other content type.
		if ( is_singular( 'post' ) ) 

			// Confine each word in a post to an array
			$post_words = preg_split( "/b/", $content );

			// Break down the post's contents into individual words
			$blacklisted_words = explode( ',', $blacklisted_words );

			// Remove any leading or trailing white space
			$blacklisted_words = array_map(
				function ( $arg ) 
					return trim( $arg );
				,

				$blacklisted_words
			);


			// Iterate over the array of words in the post
			foreach ( $post_words as $key => $value ) 

				// Iterate over the array of blacklisted words
				foreach ( $blacklisted_words as $words ) 

					// Compare the words, being case-insensitive
					if ( strcasecmp( $post_words[ $key ], $words ) == 0 ) 

						// Encrypt any blacklisted word
						$post_words[ $key ] = '<del>' . str_rot13( $value ) . '</del>';
					
				}
			}

			// Convert the individual words in the post back into a string or text
			$content = implode( '', $post_words );
		}

		return $content;
	}
}


add_filter( 'the_content', 'rot13_filter_post_content' );

While the code above for the filter function is quite easy to understand, especially because it is so heavily commented, I’ll explain a bit more anyway.

The is_singular( 'post' ) conditional tag ensures that we are dealing with a post, and not a page or any other content type.

With preg_split(), we are breaking down the post’s contents into individual words and saving them as an array by searching for the RegEx pattern b, which matches word boundaries6.

The list of blacklisted words is retrieved from the database using get_option(), with rot13_plugin_option as the option’s name.

From the screenshot of the plugin’s settings page above and the description of the textarea field, we can see that the blacklisted words are separated by commas, our delimiter. The explode PHP function breaks down the blacklisted words into an array by searching for those commas.

A closure7 is applied to the $blacklisted_words array via array_map() that will trim leading and trailing white spaces from the array values (the individual blacklisted words).

The foreach construct iterates over the post’s words and check whether any word is in the array of blacklisted words. Any blacklisted word that gets detected is encrypted in ROT13 and enclosed in a <del> tag.

The $post_words array is converted back to a string or text and subsequently returned.

Finally, the function is hooked to the the_content filter action.

Below is a screenshot of a post with the words “love” and “forever” blacklisted.

A post with the blacklisted word love encoded in ROT138

Wrapping Up

ROT13 is a simple encryption technique that can be easily decrypted. Thus, you should never use it for serious data encryption.

Even if you don’t end up using the plugin, the concepts you’ve learned in creating it can be applied to many situations, such as obfuscating or encrypting inappropriate words (such as profanities) in ROT13, which would be a nice feature in a forum where people have the freedom to post anything.

Hopefully, you have learned a thing or two from this tutorial. If you have any question or a contribution, please let us know in the comments.

(dp, al, il)

Front page image credit: Wikipedia9.

Footnotes

  1. 1 http://en.wikipedia.org/wiki/Caesar_cipher
  2. 2 http://codex.wordpress.org/File_Header
  3. 3 http://www.smashingmagazine.com/wp-content/uploads/2014/12/rot13-plugin-settings-page-large-opt.jpg
  4. 4 http://www.smashingmagazine.com/wp-content/uploads/2014/12/rot13-plugin-settings-page-large-opt.jpg
  5. 5 http://codex.wordpress.org/Settings_API
  6. 6 http://www.regular-expressions.info/wordboundaries.html
  7. 7 php.net/manual/en/functions.anonymous.php
  8. 8 http://www.smashingmagazine.com/wp-content/uploads/2014/11/post-with-blacklisted-word-opt.jpg
  9. 9 http://en.wikipedia.org/wiki/Caesar_cipher

The post Encrypting Blacklisted Words In WordPress With ROT13 appeared first on Smashing Magazine.

Continue reading here:  

Encrypting Blacklisted Words In WordPress With ROT13

Thumbnail

Obfuscating Blacklisted Words In WordPress With ROT13

Countless algorithms for encrypting data exist in computer science. One of the lesser known and less common encryptions is ROT13, a derivative of the Caesar cypher1 encryption technique.

In this tutorial, we’ll learn about ROT13 encryption and how it works. We’ll see how text (or strings) can be programmatically encoded in ROT13 using PHP. Finally, we’ll code a WordPress plugin that scans a post for blacklisted words and replaces any in ROT13 encryption.

If you own a blog on which multiple authors or certain group of people have the privilege of publishing posts, then a plugin that encrypts or totally removes inappropriate words might come in handy

Introduction

ROT13 (short for “rotate by 13 places,” sometimes abbreviated as ROT-13) is a simple encryption technique for English that replaces each letter with the one 13 places forward or back along the alphabet. So, A becomes N, B becomes O and so on up to M, which becomes Z. Then, the sequence continues at the beginning of the alphabet: N becomes A, O becomes B and so on up to Z, which becomes M.

A major advantage of ROT13 over other rot(N) techniques (where “N” is an integer that denotes the number of places down the alphabet in a Caesar cypher encryption) is that it is “self-inverse,” meaning that the same algorithm is applied to encrypt and decrypt data.

Below is a ROT13 table for easy reference.

| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z |
--------------------------------------------------------------------------------------------------------  
| N | O | P | Q | R | S | T | U | V | W | X | Y | Z | A | B | C | D | E | F | G | H | I | J | K | L | M |

If we encrypted the domain smashingmagazine.com in ROT13, the result would be fznfuvatzntnmvar.pbz, and the sentence “Why did the chicken cross the road?” would become “Jul qvq gur puvpxra pebff gur ebnq?”

Note that only letters in the alphabet are affected by ROT13. Numbers, symbols, white space and all other characters are left unchanged.

Transforming Strings To ROT13 In PHP

PHP includes a function, str_rot13(), for converting a string to its ROT13-encoded value. To encode text in ROT13 using this function, pass the text as an argument to the function.

<?php

echo str_rot13('smashingmagazine.com'); // fznfuvatzntnmvar.pbz

echo str_rot13('The best web design and development blog'); // Gur orfg jro qrfvta naq qrirybczrag oybt

Using ROT13 In WordPress

Armed with this knowledge, I thought of ways it might be handy in WordPress. I ended up creating a plugin that encodes blacklisted words found in posts using ROT13.

The plugin consists of a textearea field (located in the plugin’s settings page) in which you input blacklisted words, which are then saved to the database for later reuse in WordPress posts.

Without further fussing, let’s start coding the plugin.

Setting Up the Plugin

First, include the plugin’s file header2.

<?php

/*
Plugin Name: Rot13 Words Blacklist
Plugin URI: http://smashingmagazine.com/
Description: A simple plugin that detects and encrypts blacklisted words in ROT13
Version: 1.0
Author: Agbonghama Collins
Author URI: http://w3guy.com
Text Domain: rot13
Domain Path: /lang/
License: GPL2
*/

As mentioned, the plugin will have a settings page with a textarea field that collects and saves blacklisted words to WordPress’ database (specifically the options table).

Below is a screenshot of what the plugin’s settings (or admin) page will look like.

Settings page of the plugin.3
(See large version4)

Now that we know what the options page will look like, let’s build it using WordPress’ Settings API5

Building the Settings Page

First, we create a submenu item in the main “Settings” menu by using add_options_page(), with its parent function hooked to admin_menu action.

add_action( 'admin_menu', 'rot13_plugin_menu' );

/**
 * Add submenu to main Settings menu
 */
function rot13_plugin_menu() 
	add_options_page(
		__( 'Rot13 Blacklisted Words', 'rot13' ),
		__( 'Rot13 Blacklisted Words', 'rot13' ),
		'manage_options',
		'rot13-words-blacklist',
		'rot13_plugin_settings_page'
	);

The fifth parameter of add_options_page() is the function’s name (rot13_plugin_settings_page), which is called to output the contents of the page.

Below is the code for rot13_plugin_settings_page().

/**
 * Output the contents of the settings page.
 */
function rot13_plugin_settings_page() 
	echo '<div class="wrap">';
	echo '<h2>', __( 'Rot13 Blacklisted Words', 'rot13' ), '</h2>';
	echo '<form action="options.php" method="post">';
	do_settings_sections( 'rot13-words-blacklist' );
	settings_fields( 'rot13_settings_group' );
	submit_button();

Next, we add a new section to the “Settings” page with add_settings_section(). The textarea field we mentioned earlier will be added to this section with add_settings_field(). Finally, the settings are registered with register_setting().

Below is the code for add_settings_section(), add_settings_field() and register_setting().

	// Add the section
	add_settings_section(
		'rot13_setting_section',
		'',
		'rot13_setting_section_callback_function',
		'rot13-words-blacklist'
	);


	// Add the textarea field to the section.
	add_settings_field(
		'blacklisted_words',
		__( 'Blacklisted words', 'rot13' ),
		'rot13_setting_callback_function',
		'rot13-words-blacklist',
		'rot13_setting_section'
	);

	// Register our setting so that $_POST handling is done for us
	register_setting( 'rot13_settings_group', 'rot13_plugin_option', 'sanitize_text_field' );

The three functions above must be enclosed in a function and hooked to the admin_init action, like so:

/**
 * Hook the Settings API to 'admin_init' action
 */
function rot13_settings_api_init() 
	// Add the section
	add_settings_section(
		'rot13_setting_section',
		'',
		'rot13_setting_section_callback_function',
		'rot13-words-blacklist'
	);


	// Add the textarea field to the section
	add_settings_field(
		'blacklisted_words',
		__( 'Blacklisted words', 'rot13' ),
		'rot13_setting_callback_function',
		'rot13-words-blacklist',
		'rot13_setting_section'
	);

	// Register our setting so that $_POST handling is done for us
	register_setting( 'rot13_settings_group', 'rot13_plugin_option', 'sanitize_text_field' );


add_action( 'admin_init', 'rot13_settings_api_init' );

Lest I forget, here is the code for the rot13_setting_callback_function() and rot13_setting_section_callback_function() functions, which will output the textarea field and the description of the field (at the top of the section), respectively.

/**
 * Add a description of the field to the top of the section
 */
function rot13_setting_section_callback_function() 
	echo '<p>' . __( 'Enter a list of words to blacklist, separated by commas (,)', 'rot13' ) . '</p>';


/**
 * Callback function to output the textarea form field
 */
function rot13_setting_callback_function() 
	echo '<textarea rows="10" cols="60" name="rot13_plugin_option" class="code">' . esc_textarea( get_option( 'rot13_plugin_option' ) ) . '</textarea>';

At this point, we are done building the settings page for the plugin.

Up next is getting the plugin to detect blacklisted words and encrypt them with ROT13.

Detecting Blacklisted Words and Encrypting in ROT13

Here is an overview of how we will detect blacklisted words in a WordPress post:

  • A post’s contents are broken down into individual words and saved to an array ($post_words).
  • The blacklisted words that were saved by the plugin to the database are retrieved. They, too, are broken down into individual words and saved to an array ($blacklisted_words).
  • We iterate over the $post_words arrays and check for any word that is on the blacklist.
  • If a blacklisted word is found, then str_rot13() encodes it in ROT13.

It’s time to create the PHP function (rot13_filter_post_content()) that filters the contents of a post and then actually detects blacklisted words and encrypts them in ROT13.

Below is the code for the post’s filter.

/**
 * Encrypt every blacklisted word in ROT13
 *
 * @param $content string post content to filter
 *
 * @return string
 */
function rot13_filter_post_content( $content ) 

	// Get the words marked as blacklisted by the plugin
	$blacklisted_words = esc_textarea( get_option( 'rot13_plugin_option' ) );

    // If no blacklisted word are defined, return the post's content.
	if ( empty( $blacklisted_words ) ) 
		return $content;
	

	else 

		// Ensure we are dealing with "posts", not "pages" or any other content type.
		if ( is_singular( 'post' ) ) 

			// Confine each word in a post to an array
			$post_words = preg_split( "/b/", $content );

			// Break down the post's contents into individual words
			$blacklisted_words = explode( ',', $blacklisted_words );

			// Remove any leading or trailing white space
			$blacklisted_words = array_map(
				function ( $arg ) 
					return trim( $arg );
				,

				$blacklisted_words
			);


			// Iterate over the array of words in the post
			foreach ( $post_words as $key => $value ) 

				// Iterate over the array of blacklisted words
				foreach ( $blacklisted_words as $words ) 

					// Compare the words, being case-insensitive
					if ( strcasecmp( $post_words[ $key ], $words ) == 0 ) 

						// Encrypt any blacklisted word
						$post_words[ $key ] = '<del>' . str_rot13( $value ) . '</del>';
					
				}
			}

			// Convert the individual words in the post back into a string or text
			$content = implode( '', $post_words );
		}

		return $content;
	}
}


add_filter( 'the_content', 'rot13_filter_post_content' );

While the code above for the filter function is quite easy to understand, especially because it is so heavily commented, I’ll explain a bit more anyway.

The is_singular( 'post' ) conditional tag ensures that we are dealing with a post, and not a page or any other content type.

With preg_split(), we are breaking down the post’s contents into individual words and saving them as an array by searching for the RegEx pattern b, which matches word boundaries6.

The list of blacklisted words is retrieved from the database using get_option(), with rot13_plugin_option as the option’s name.

From the screenshot of the plugin’s settings page above and the description of the textarea field, we can see that the blacklisted words are separated by commas, our delimiter. The explode PHP function breaks down the blacklisted words into an array by searching for those commas.

A closure7 is applied to the $blacklisted_words array via array_map() that will trim leading and trailing white spaces from the array values (the individual blacklisted words).

The foreach construct iterates over the post’s words and check whether any word is in the array of blacklisted words. Any blacklisted word that gets detected is encrypted in ROT13 and enclosed in a <del> tag.

The $post_words array is converted back to a string or text and subsequently returned.

Finally, the function is hooked to the the_content filter action.

Below is a screenshot of a post with the words “love” and “forever” blacklisted.

A post with the blacklisted word love encoded in ROT138

Wrapping Up

ROT13 is a simple encryption technique that can be easily decrypted. Thus, you should never use it for serious data encryption.

Even if you don’t end up using the plugin, the concepts you’ve learned in creating it can be applied to many situations, such as obfuscating or encrypting inappropriate words (such as profanities) in ROT13, which would be a nice feature in a forum where people have the freedom to post anything.

Hopefully, you have learned a thing or two from this tutorial. If you have any question or a contribution, please let us know in the comments.

(dp, al, il)

Front page image credit: Wikipedia9.

Footnotes

  1. 1 http://en.wikipedia.org/wiki/Caesar_cipher
  2. 2 http://codex.wordpress.org/File_Header
  3. 3 http://www.smashingmagazine.com/wp-content/uploads/2014/12/rot13-plugin-settings-page-large-opt.jpg
  4. 4 http://www.smashingmagazine.com/wp-content/uploads/2014/12/rot13-plugin-settings-page-large-opt.jpg
  5. 5 http://codex.wordpress.org/Settings_API
  6. 6 http://www.regular-expressions.info/wordboundaries.html
  7. 7 php.net/manual/en/functions.anonymous.php
  8. 8 http://www.smashingmagazine.com/wp-content/uploads/2014/11/post-with-blacklisted-word-opt.jpg
  9. 9 http://en.wikipedia.org/wiki/Caesar_cipher

The post Obfuscating Blacklisted Words In WordPress With ROT13 appeared first on Smashing Magazine.

View this article – 

Obfuscating Blacklisted Words In WordPress With ROT13

How To Speed Up WordPress

A few months ago, I ran an experiment to see how much faster I could make one of my websites in less than two hours of work. After installing a handful of WordPress plugins and fixing a few simple errors, I had improved the website’s loading speed from 1.61 seconds to 583 milliseconds. That’s a 70.39% improvement, without having made any visual changes to the website. [Links checked & repaired April/04/2017]

Originally posted here: 

How To Speed Up WordPress

How To Create An Admin-Manageable Magento Entity For Brands

In this tutorial, we will create a new “brand” entity in Magento that can be managed through the admin panel. Once we are finished, you will be able to create, update and delete brands that can be viewed in the front-end independently, much in the same way that you can interact with existing entities such as “products” and “categories.”
In addition, we will associate our new brand entity with other Magento entities, such as products.

See the article here – 

How To Create An Admin-Manageable Magento Entity For Brands