4elements, Amsterdam, Holland

  1. An 8-Step Checklist for Publishing a WordPress Theme on ThemeForest: Part 1

    Publishing WordPress themes on ThemeForest is hard. I mean really hard—but that's a good thing, because buyers need to buy the best designed and coded themes, and ThemeForest has to set the bar high to make sure they have the best themes in the marketplace.

    While not letting every theme be sold sounds like a bad idea, it's actually a win-win-win strategy:

    • The seller is encouraged to make and sell better themes.
    • The buyers get to buy quality themes with some "standards" that they follow.
    • ThemeForest gets to have a positive image and be on top of its competitors by selling WordPress themes that pass certain quality standards.

    Of course, the same goes for almost all types of products people sell on Envato marketplaces; but I think it's safe to say that WordPress themes get the most attention from ThemeForest reviewers... and again, that's a good thing for everyone.

    The bar could be set high for WordPress themes, but this doesn't necessarily mean that it's hard or impossible to have your theme approved. If you follow some simple steps like coding with standards and respecting the licenses of your assets, you'll be able to sell your WordPress themes.

    That's why in this tutorial, we're going to go through a checklist to create a WordPress theme that can be published and sold on ThemeForest.

    Important Notice: While Tuts+ and ThemeForest are both part of the Envato family, I'm not an Envato employee and this article doesn't reflect an official opinion of the guys at ThemeForest. I'm just an instructor and these are my ideas—although getting them published means that they're probably good ideas!

    1. Evaluate the Quality of Your Code

    The quality of your code is essential to the guys at ThemeForest: Poor coding skills can result in a soft or hard rejection. (We will look into what a "soft rejection" and a "hard rejection" means.) You must keep your code clean, optimized, and respecting quality standards.

    Coding clean and optimization might make sense to you, but you might be wondering what "quality standards" you are required to comply with while developing a theme's infrastructure. Simply put, there are five standards to pay attention to: HTML standards, CSS standards, JavaScript standards, PHP standards, and WordPress theme development standards.

    To get more information about these quality standards, you can check out this article from my series "Making the Perfect WordPress Theme". Adopting and complying with these standards while making your theme will be a huge plus for you, and the guys at ThemeForest won't have a hard time figuring out your theme's code.

    2. Validate Your Markup and Test Your Theme Vigorously

    Validating your theme is another important part of your theme's approval process, and is part of the quality standards that you've just read above—but writing standardized markup doesn't necessarily mean that all the pages in your theme will pass the HTML and CSS validation tests over W3C's tools. You must test your theme in detail with many, many types of post content and some popular plugins that can output content and invalidate your theme's markup.

    To try out various post data, you can head over to WPTest.io which is described as "a fantastically exhaustive set of test data to measure the integrity of your plugins and themes". It really is an exhaustive set of test data and might seem "too much" for you; but passing this hard test will pretty much guarantee that your theme will still be valid in any case. In addition to WPTest, I recommend a great WordPress plugin named Monster Widget which, as its name suggests, loads all 13 default widgets as one "super-widget" to let you save time testing your theme's sidebars.

    As for testing with WordPress plugins, be sure to test popular plugins that output or change data in the front-end of WordPress. Shortcode plugins, video embed helpers, social sharing widgets, any kind of sidebar widgets, and plugins that change or add to post content should be tested to offer a better experience for your theme's users. Keep in mind that this is not a requirement from the guys at ThemeForest, but it will be a step to get less bug reports and prevent any frustration with your theme.

    Oh, and one last thing: Don't forget to check your theme with the Theme Check plugin!

    3. Separate Any Kind of Functionality From Your Theme

    Ever heard the term "plugin territory"? It basically is the definition of the type of functionality that can (and should) be offered by a WordPress plugin. Leaving plugin functionality to plugins is one of the most important (yet overlooked) parts of the WordPress theme development process.

    Imagine that you're running your corporate website with a WordPress theme, but in time, you fall out of love with the theme. You decide to change to another theme and spend hours finding a new one. You find a really good looking design that's definitely going to fit to your website. You install it and, BAM, all your "testimonials" are gone, your "portfolio" pages are nowhere to be found, and the shortcodes you used inside your posts are missing. How would you feel?

    This is the exact frustration the users of "bad themes" feel—the users are practically forced to use that theme for ever and ever. The term "plugin territory" was coined to describe the functionality that should be covered by plugins, and to prevent this kind of bad experience. You probably get it now: You have to take your functionality out of your theme and serve it as a separate plugin to be installed.

    Luckily, there's an easy solution for both you and your theme's users: The TGM Plugin Activation Library. It's been created to be a part of themes that "recommend" or "require" users to install additional plugins. Using this library, you can make users install plugins from WordPress.org, a website, or even a ZIP file that's inside your theme's folders. Head over to the article where I explained how to use TGM Plugin Activation to get more information about it.

    4. Make Sure Your Design Is Good and "Unique"

    There are a lot of WordPress themes in ThemeForest, and it has started to feel as if there are more than a few "instances" of popular theme types. One example is "corporate themes": There are literally tens to hundreds of corporate WordPress themes in ThemeForest, and things have started to look alike. ThemeForest wants to offer different design choices to the customers, instead of designs similar to each other, so "uniqueness" is a factor in your theme's approval process.

    Of course, that doesn't mean you can't use a slider or a "Testimonials" section, but you need to combine these design elements in an original and eye-pleasing way in your pages.

    End of Part One

    I really hope you liked the article—it's kind of an "elephant in the room" since people doesn't want to talk about too much, but it's an important topic nonetheless. Stay tuned for the second part to get the remaining four checklist items!

    What's your take on this subject? Tell us what you think by commenting below. And don't forget to share the article with your friends—especially ThemeForesters!



    Leave a comment › Posted in: Daily

    1. Creating a Web App From Scratch Using AngularJS and Firebase: Part 4

      In the previous tutorial, we implemented the sign-up functionality and also saw how to use AngularJS services to share data between controllers. In this part of the tutorial series, we'll be creating an interface for the logged in user to create a blog post.

      Getting Started 

      Let's start by cloning the third part of the tutorial from GitHub.

      After cloning the source code, navigate to the project directory and install the required dependencies.

      Once the dependencies are installed, start the server.

      Point your browser to http://localhost:8000/app/#/home and you should have the application running.

      Creating the Add Post Page

      We need a page with which the user can create and publish blog posts. Let's add the require templates and files to create the Add Post page.

      Navigate to the AngularJS_Firebase_Part3/app directory and create a folder called addPost. Inside addPost create an HTML file called addPost.html and addPost.js. In addPost.html add the following HTML code:

      Inside addPost.js, we'll define the routes for the Add Post view. $routeProvider has a method called when, which we'll use to create a route for our addPost view. We'll set a templateUrl which would be rendered in the index.html. We'll also set a controller (logic which controls a view) for the newly created $scope of the addPost view. Here's how addPost.js finally looks:

      Include the myApp.addPost module in app.js.

      Also, add a reference to the addPost.js in the app/index.html page.

      Save the changes, restart the server and point your browser to http://localhost:8000/app/#/addPost and you should be able to see the add post page.

      Add Post page of AngularJS  Firebase app

      Validating the Add Post Fields

      First, we need to add an ngModel directive to the input text box and text area in the add post page to enable the two-way data binding.

      When a user publishes a blog post, it should have a title and post. So we'll add validation to check if a blog post has title and post. If the title and post are provided, we'll enable the publish button and the user can publish his or her blog post. We'll use an ngDisabled directive to disable the publish button. Add the ngDisabled directive to the publish button as shown.

      As seen in the above code, ngDisabled would disable the publish button when the title or post of the article is not provided.

      Implementing the Add Post Functionality

      Next, we'll save the title and post of the article to Firebase when the user clicks the publish button. In order to save the data to Firebase, we'll use the $push API.

      Add the ngController directive to the body of addPost.html and also add the ngSubmit directive to the form in addPost.html.

      Open up addPost.js and add a new function called AddPost inside the AddPostCtrl controller as shown:

      We'll be needing $firebase to push data to Firebase Db, so inject the $firebase module in the AddPostCtrl controller.

      Create a Firebase object using your Firebase URL.

      Using firebaseObj we'll create an instance of $firebase which we'll use to push data to Firebase.

      Read the title and post entered by the user using $scope

      Since we have the title and post, we'll call the Firebase push API to save data to Firebase.

      Now, save all the changes, restart the server, and try to add a new blog post. Once you've clicked the publish button, check the browser console for the reference object. After that, log into your Firebase account and you should be able to see the data.

      Add Post data in Firebase

      Wrapping It Up

      In this part of the series, we created an interface to add or publish blog posts. In the next part of this series, we'll create an interface to fetch and display all the blog posts added by users.

      Source code from this tutorial is available on GitHub. Do let us know your thoughts in the comments below!



      Leave a comment › Posted in: Daily

    1. Creating a Web App From Scratch Using AngularJS and Firebase: Part 3

      In the previous part of this series, we created the sign-up page, set up the routes, and also did some form validations using AngularJS. In this tutorial, we'll implement the sign-up functionality by wiring up AngularJS and the latest release of Firebase. We'll also modify the sign-in code as per the newer Firebase API.

      Getting Started

      Let's start by cloning the second part of the tutorial from GitHub.

      After cloning the source code, navigate to the project directory and install the required dependencies.

      Once the dependencies are installed, start the server.

      Point your browser to http://localhost:8000/app/ and you should have the application running.

      Firebase Script References

      Firebase recently released a newer version, and the FirebaseSimpleLogin client that we used in our first tutorial to sign in the user has been deprecated and included in the main Firebase library. So open up app/index.html and remove the existing Firebase references and include the following script references:

      Modifying Sign-In Implementation

      Navigate to app/home and open up home.js. Remove the injected $simplefirebaselogin from the controller and inject $firebaseAuth. Use it to create the loginObj as shown.

      The new Firebase provides an API method called $authWithPassword to authenticate using email address and password. Replace the login method with $authWithPassword in the SignIn function as shown:

      Save the changes, restart the server, and try to sign in using a valid email address and password. You should have a success message in the browser console.

      Implementing Sign-Up Functionality

      We'll be using the Firebase createUser method to create a new user using an email address and password. Since we have already validated the data in our previous tutorial, we'll bind a sign-up function call on the click of the register button. Add the ngClick directive to the register button as shown:

      Open up register.js and inside the RegisterCtrl controller, create a new function called signUp

      In the signUp function we'll just check if our form is valid:

      Add the ngController directive to the body tag in register.html.

      Restart the server and try browsing to the register page. Press the Register button after entering the email address and password. Now, if you check the browser console you should see the Valid form submission message.

      So, before calling the Firebase API to create a new user, we'll need to inject firebase into our application. Open up register.js and add the firebase module.

      Next, we'll also need to inject the $firebaseAuth into our register controller.

      Using our Firebase URL we'll create a Firebase instance and using that Firebase instance, we'll create a $firebaseAuth object. We'll be using this $firebaseAuth object to make our API call. Add the following code in register.js, inside the register controller.

      Now, we'll get the email address and password from $scope and call the createUser Firebase method. Here is the modified signUp method.

      As you can see in the above signUp function, we have called the $createUser method to create a new user. On successful user creation, we'll be logging the success message in the success callback of the createUser function. 

      Restart the server and point your browser to http://localhost:8000/app/#/register and try to register for a new user account using an email address and password. Check your browser console after the user registration button click. If successful, you should have the user creation success message in the browser console. 

      Next, point your browser to http://localhost:8000/app/#/home and try to sign in using the new user credentials.

      Handling User Registration Callbacks

      Create User Success Callback

      When a user registration is successful, we need to redirect the user to the sign-in page. In order to redirect the user, we'll need to inject the $location AngularJS service into our controller. So, inject $location as shown:

      Add the following code to the success callback of the auth.$createUser function to redirect the user to the sign-in page on successful user registration.

      Save the changes, restart the server, and try to register for another user account. On successful user registration, you should be redirected to the sign-in page.

      Create User Failure Callback

      User registrations may fail due to some issues, for example if the user email address already exists. So when an error occurs during user registration, we need to show it to the user. We'll add another error message below the password field and set its display to show when an error occurs. Here is the error message:

      As seen in the above code, we have used the ngShow directive to show the above error message when regError is true. The message is displayed using the $scope variable regErrorMessage. In the createUser failure callback, add the following code to display the error message.

      Here is the modified signUp function:

      Save the changes, restart the server, and try to register using an email address and password you have already used. On doing this, you should have an error message displayed on screen as shown :

      User Registration Error Message

      Creating the Home Screen

      When a user successfully signs into the application, we'll redirect the user to the home page. The home page will display the posts created by the user and it will also have an option to create new posts. So let's create the home page.

      Navigate to the app folder in the application directory and create a new folder called welcome. This folder will contain templates and files related to the home page. Inside the welcome folder, create pages called welcome.html and welcome.js. Add the following code to welcome.html.

      Inside welcome.js we'll define the routes for the application to the welcome page. We'll use $routeProvider to create a route for the welcome view. When defining a new route, we'll set a templateUrl which would be rendered in the index.html. Along with that, we'll also set a controller (a controller is a logic which controls a particular view) for the newly created $scope of the welcome view. Here's what welcome.js finally looks like:

      Now, open up app/app.js and include the newly added module.

      Also, open up app/index.html and include the newly-added register.js script.

      When a user successfully signs in, we'll redirect the user to the welcome page. Open up app/home/home.js and inject the $location into the HomeCtrl

      We'll use $location to redirect the user to the welcome page. In home.js, inside the SignIn function, on success callback add the following code:

      Save the changes, restart the server, and try to sign in to the app. On successful sign-in you should be able to see a screen as shown below:

      AngularJS  Firebase App User Home

      Accessing $scope Between Controllers 

      Now let's display the email of the logged in user in the welcome page. But there is an issue. During sign-in, we have the user detail in the HomeCtrl, but when we redirect to welcome view, the $scope of HomeCtrl isn't accessible inside the WelcomeCtrl. So in order to make this possible we'll make use of AngularJS services.

      Angular services are substitutable objects that are wired together using dependency injection (DI). You can use services to organize and share code across your app.

      Using services we can share data across different controllers. So in home.js we'll create our service called CommonProp.

      In the CommonProp service we have created a variable called user, where we'll set the email of the logged-in user. Since the service can be accessed from all controllers, it would be possible to share data between controllers using the service CommonProp.

      Inject the service CommonProp in the HomeCtrl as shown:

      On successful user authentication set the user variable in CommonProp service as shown.

      Also, inject the CommonProp service in the WelcomeCtrl in welcome.js.

      In welcome.html modify the welcome message to include a $scope variable as shown.

      Now in the WelcomeCtrl set the value of the $scope.username from CommonProp services getUser method.

      Save all the changes, restart your browser, and try to log in using any email address and password. On successful login you should see your email address on the welcome page.

      AngularJS  Firebase App User Home

      Wrapping It Up

      In this tutorial, we took our blog application development tutorial using AngularJS and Firebase to the next level. We implemented the sign-up functionality and also saw how to share data between two controllers.

      In the next part of this series, we'll see how to get started with implementing the "Create Blog Post" page. 

      Source code from this tutorial is available in GitHub.

      Do let us know your thoughts in the comments below!



      Leave a comment › Posted in: Daily

    1. Speed Up WordPress: Caching and Database Optimization

      One of the most popular talking points in the WordPress community is speeding up WordPress and optimizing web pages. I don't think there is a WordPress blog without an "X Tips to Speed Up WordPress" article. Don't get me wrong, it's a good thing. But we need better articles about this topic instead of dull plugin round-ups.

      This may look like yet another "tips for speeding up WordPress" tutorial, but in this three-part series, we're going to go through every aspect of optimizing and speeding up your WordPress website.

      Let's start with the most popular and probably the easiest thing: caching.

      Caching in WordPress

      I think it's safe to say that this is the most popular topic when it comes to speeding up WordPress. Granted, this is because of the popular and easy-to-use WordPress caching plugins, but it's also one of the fundamental techniques of reducing database load and speeding up WordPress websites.

      We're going to get back to caching plugins, but let's look at the two types of caching: server-side caching and client-side caching.

      Client-Side Caching

      Client-side caching is the type of caching your visitors' browsers do. That means when visitors come to your website, their browsers will store data of certain parts of your pages. While browsers do cache some data automatically (like caching JavaScript and CSS files), we can do some fine-tuning with the help of .htaccess files.

      By fine-tuning the .htaccess file, I mean adding the "Expires" header in it. You might have heard the term "leveraging browser caching" because it's commonly used in "website optimization" tutorials, and it's a high-priority criterion in the Google PageSpeed service.

      Luckily, we don't have to come up with these headers ourselves—there's plenty of code ready to be "borrowed" on the web. I like the one in the HTML5 Boilerplate, where the headers are divided by categories of file types:

      Place these lines of code in your .htaccess file and you're good to go!

      Server-Side Caching

      When it comes to server-side caching in WordPress, we can talk about four major kinds of caching: page caching, database caching, object caching, and opcode (operation code) caching. Sourav Kundu explains this in his article at WP Explorer, but let's recap:

      1. Page Caching: In essence, WordPress outputs your pages by querying databases and loading the results. Page caching, however, stores each page as HTML files in the server's local storage (hard disk or RAM), and serves the HTML files corresponding to your pages each time your visitors visit your website.
      2. Database Caching: While databases are the "brains" of a WordPress website where all data are stored, it's not very effective when WordPress makes the same non-altering query over and over again on each page and for each visitor. Database caching saves and serves the results of these queries, and refreshes the results when an altering query is made.
      3. Object Caching: This is an internal API of WordPress that allows plugins to store data of expensive queries in the memory. It's a bit irrelevant for our series—maybe we'll go through this in a separate tutorial in the future.
      4. Opcode Caching: Just as you add flour, water, eggs, sugar and whatnot every time you bake a cake, the codes in your PHP files are instructions to "compile" and make your requests. Opcode caching is the kind of caching that stores the compiled code, speeding up the process considerably.

      WordPress Plugins on Caching

      Our main chapters are the aspects of speeding up WordPress, so it might be off‑topic to review plugins. Nevertheless, it's a good idea to talk about a couple of plugins in each chapter. As for caching, I know you already know the two most popular plugins:

      1. WP Super Cache: This is the most popular caching plugin for WordPress, with over 6 million downloads and a 4.2 star rating as I'm writing this article. Simply put, WP Super Cache works by generating static HTML files of your pages and refreshing them with an interval that you set (an hour by default). This works like magic out of the box even in shared hosts, but may not be enough for high-traffic websites.
      2. W3 Total Cache: Being the second most popular plugin with almost 4 million downloads and a 4.5 star rating, W3 Total Cache is the kind of plugin that's more suitable for high traffic websites running from a VPS or a better hosting environment. With its wide range of settings and support for high-performance caching options, it might be the best solution for you if you know what you're doing. If you're not familiar with the jargon in the settings, however, you might as well use it out of the box and don't change any options, or you may break your front-end.

      Optimizing the Database in WordPress

      Databases are the "brains" of your website: They store the valuable data that you show on your pages. Static HTML websites store their data inside the pages, but content management systems have to rely on databases (SQL, NoSQL, XML, JSON and such) to store our data. WordPress is no different—it uses MySQL to store the static and dynamic content along with your website information, WordPress settings, user details and so on.

      Databases are a powerful standard to keep, serve and alter your data, but if you use them wrong and forget to maintain them, they can get fat and bloated. And like any other software, WordPress needs maintenance, too. WordPress doesn't build up too much bloat in the database, but that doesn't mean it won't slow down your website.

      You need to keep an eye on your post revisions, trashes of posts, pages, comments, etc., and any other kind of "stale" data. And every now and then, you must check your "database overhead", which is often compared to hard disk defragmentation or changing the oil of your car.

      It's possible to maintain all of these manually: You can empty your trash, disable the "revisions" feature, delete spam comments and optimize the database overhead by logging in to phpMyAdmin, but that's not an optimized technique for database optimization. Instead, you can use a WordPress plugin to do all the work.

      There are more than a few plugins that allow you to optimize your database with one click or even automatically. The one I like the most is WP-Optimize: It automatically cleans up and optimizes your database without any hassle.

      WP-Optimize lists its main features as follows:

      • Removal of stale post revisions
      • Removal of stale unapproved and spam comments
      • Removal of trashed comments
      • Removal of Akismet metadata from comments
      • Removal of other stale metadata from comments
      • Mobile device friendly, now you can optimize your site on the go
      • Removal of all trackbacks and pingbacks
      • Cleaning up auto draft posts
      • Removal of transient options
      • Clear out the post trash
      • Automatic cleanup of all the integrated options (also uses retention if enabled)
      • Ability to keep selected number of weeks data when cleaning up
      • Option to add or remove link on wp admin bar.
      • Enable/Disable weekly schedules of optimization
      • Apply native WordPress MySql optimize commands on your database tables without phpMyAdmin or any manual query.
      • Display Database table statistics. Shows how much space can be optimized and how much space has been cleared.
      • Enabled for Administrators only.

      Be sure to check out other database optimization plugins, but don't be negligent about maintaining your database.

      On to Part 2

      In the next part of the series, we'll be looking at the aspects of compression and minification, and using CDNs to make your WordPress website faster.

      What do you think about speeding up WordPress? Share your thoughts below in the comments section. And if you liked the article, don't forget to share it.



      Leave a comment › Posted in: Daily

    1. Using Squire, a Lightweight HTML5 Rich Text Editor

      Final product image
      What You'll Be Creating

      What Is Squire?

      Squire is an extremely lightweight HTML5 rich text editor best suited for your applications' rich input forms and simple document creation. It provides cross-browser support but deliberately avoids the complexity of supporting older browsers. It works best beginning with Opera 10, Firefox 3.5, Safari 4, Chrome 9 and IE8.

      Squire is not meant for creating and editing WYSIWYG website pages. However, for many rich text input and web application purposes, Squire may be just what you need. It provides the power without the bloat. It's also MIT licensed for flexible reuse.

      In this tutorial, I'll show you how to download Squire and build sample input forms with it. If you'd like to see Squire in action, visit the demo.

      Where Did Squire Come From?

      The FastMail team built Squire to simplify their webmail editor requirements. FastMail is an excellent cloud-based email alternative to Gmail—I'm a daily FastMail user. Because it's based in Australia and operates under different laws than in the U.S., there are slightly improved privacy protections for FastMail users. You can read more about this here: FastMail Says It's Free of NSA Surveillance.

      As the FastMail team wrote on their blog, they previously used CKeditor:

      While not a bad choice, like most other editors out there it was designed for creating websites, not writing emails. As such, simply inserting an image by default presented a dialog with three tabs and more options than you could believe possible...It also came with its own UI toolkit and framework, which we would have had to heavily customise to fit in with the rest of the new UI we were building; a pain to maintain.
      With our focus on speed and performance, we were also concerned about the code size. The version of CKEditor we use for our previous (classic) UI, which only includes the plugins we need, is a 159 KB download (when gzipped; uncompressed it’s 441 KB). That’s just the code, excluding styles and images.

      They decided to start from scratch and build Squire. At only 11.5 KB of JavaScript after minification and gzip (34.7 KB uncompressed) and with no dependencies, Squire is extremely lightweight. 

      The results are impressive. The combined code weight required to load their whole compose screen, base library, mail and contacts model code and all the UI code to render the entire screen now comes to only 149.4 KB (459.7 KB uncompressed)—less than CKEditor alone.

      Squire has no dependencies. There's no XHR wrapper, widget library or lightbox overlays. There's no user interface for a toolbar, which eliminates the bloat of having two UI toolkits loaded. It's just a simple <textarea> component which can be manipulated through JavaScript.

      How Squire Works

      Squire manipulates the DOM using selection and range APIs. This eliminates common cross-browser incompatibilities. Again, from the FastMail blog:

      Making a rich text editor is notoriously difficult due to the fact that different browsers are extremely inconsistent in this area. The APIs were all introduced by Microsoft back in the IE heyday, and were then copied by the other vendors in various incompatible ways ... most rich text editors execute a command, then try to clean up the mess the browser created. With Squire, we neatly bypass this.
      The general philosophy of Squire is to allow the browser to do as much as it can (which unfortunately is not very much), but take control anywhere it deviates from what is required, or there are significant cross-browser differences.
      Installing Squire

      First, visit the Squire Github page and clone or download the source code:

      Squire on Github

      Second, copy the contents of the build/ directory into your application.

      Third, edit the <style> block in document.html to add the default styles you would like the editor to use (or link to an external stylesheet).

      Using Squire

      Let's look at the demo application included with Squire. When using Squire, instead of a <textarea> element, you use an <iframe src="path/to/document.html">

      In the demo that's:

      Document.html is a blank canvas with default styles and it loads Squire:

      When using Squire, you attach an event listener to the load event of the iframe. When this fires, you can grab a reference to the editor object through iframe.contentWindow.editor. For example, the demo iframe includes:


      The demo has two types of links for manipulating content within Squire. Simple commands that can operate with any selected text look like this:

      <span id="bold">Bold</span>

      And complex commands that require additional user input look like this; they add the prompt c:

      <span id="setFontSize" class="prompt">Font size</span>

      Here's what the demo application looks like:

      Squire HTML Demo

      The JavaScript at the top of the demonstration page listens for any clicks to these span commands. If the prompt class exists, it collects more information from the user:

      Then, it calls the Squire editor with the command and any user-supplied value. Squire then applies the command to the currently selected text:

      editor[ id ]( value );

      You can learn more about Squire and see its complete API documentation in the ReadMe.

      Extending the Demo

      Just as an example, let's add two commands that read the state of the Squire editor. We'll add two links to the bottom of the demo's command header:

      When you select some text and click on it, the selection will pop up in the alert as shown below.

      Squire HTML Demo Extended

      Let's examine the more aesthetically pleasing demo and its toolbar:

      Squire Live Demo with Bootstrap

      The head block for this page integrates stylesheets for Bootstrap and one called Squire-UI. It also provides JavaScript for this Squire-UI.

      But on load, its JQuery $(document).ready function replaces the static #foo textarea with its SquireUI.

      The toolbar configuration is implemented with a fairly complex configuration of JQuery, AJAX, HTML5 and CSS. It's loading this HTML page to display most of the toolbar: http://neilj.github.io/Squire/build/Squire-UI.html.

      Here's a subset of the source code for Squire-UI.html so you can see what's being loaded:

      It might have been nice if they had provided a simplified Bootstrap toolbar in the distribution code as an add-on, but you can certainly learn from what they did in their own demo above.

      I hope you find Squire useful for your own applications. Please feel free to post corrections, questions or comments below. You can also reach me on Twitter @reifman or email me directly.

      Related Links



      Leave a comment › Posted in: Daily

  • Page 1 of 51 pages  1 2 3 >  Last ›
  • Browse the Blog


    Most recent entries