SitePoint

Making pixel-perfect layouts on mobile is hard. Even though React Native makes it easier than its native counterparts, it still requires a lot of work to get a mobile app to perfection. In this tutorial, we’ll be cloning the most famous dating app, Tinder. We’ll then learn about a UI framework called React Native Elements, which makes styling React Native apps easy. Since this is just going to be a layout tutorial, we’ll be using Expo, as it makes setting things up much easier than plain old react-native-cli. We’ll also be making use of a lot of dummy data to make our app. We’ll be making a total of four screens—Home, Top Picks, Profile, and Messages. Prerequisites For this tutorial, you need a basic knowledge of React Native and some familiarity with Expo. You’ll also need the Expo client installed on your mobile device or a compatible simulator installed on your computer. Instructions on how to do this can be found here. You also need to have a basic knowledge of styles in React Native. Styles in React Native are basically an abstraction similar to that of CSS, with just a few differences. You can get a list of all the properties in the styling cheatsheet. Throughout the course of this tutorial we’ll be using yarn. If you don’t have yarn already installed, install it from here. Also make sure you’ve already installed expo-cli on your computer. If it’s not installed already, then go ahead and install it: $ yarn global add expo-cli To make sure we’re on the same page, these are the versions used in this tutorial: Node 11.14.0 npm 6.4.1 yarn 1.15.2 expo 2.16.1 Make sure to update expo-cli if you haven’t updated in a while, since expo releases are quickly out of date. We’re going to build something that looks like this: If you just want to clone the repo, the whole code can be found on GitHub. Getting Started Let’s set up a new Expo project using expo-cli: $ expo init expo-tinder It will then ask you to choose a template. You should choose tabs and hit Enter. Then it will ask you to name the project. Type expo-tinder and hit Enter again. Lastly, it will ask you to press y to install dependencies with yarn or n to install dependencies with npm. Press y. This bootstraps a brand new React Native app using expo-cli. React Native Elements React Native Elements is a cross-platform UI Toolkit for React Native with consistent design across Android, iOS and Web. It’s easy to use and completely built with JavaScript. It’s also the first UI kit ever made for React Native. It allows us to fully customize styles of any of our components the way we want so every app has its own unique look and feel. It’s also open source and backed by a community of awesome developers. You can build beautiful applications easily. Cloning Tinder UI We’ve already created a project named expo-tinder. To run the project, type this: $ yarn start Press i to run the iOS Simulator. This will automatically run the iOS Simulator even if it’s not opened. Press a to run the Android Emulator. Note that the emulator must be installed and started already before typing a. Otherwise it will throw an error in the terminal. It should look like this: The post Cloning Tinder Using React Native Elements and Expo appeared first on SitePoint.

With ever-increasing usage of mobile apps, geolocation and tracking functionality can be found in a majority of apps. Real-time geolocation tracking plays an important role in many on-demand services, such as these: taxi services like Uber, Lyft or Ola food Delivery services like Uber Eats, Foodpanda or Zomato monitoring fleets of drones In this guide, we’re going use React Native to create a real-time location tracking apps. We’ll build two React Native apps. One will act as a tracking app (called “Tracking app”) and the other will be the one that’s tracked (“Trackee app”). Here’s what the final output for this tutorial will look like: [video width="640" height="480" mp4="https://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2019/09/1569381508tracking.mp4"][/video] Prerequisites This tutorial requires a basic knowledge of React Native. To set up your development machine, follow the official guide here. Apart from React Native, we’ll also be using PubNub, a third-party service that provides real-time data transfer and updates. We’ll use this service to update the user coordinates in real time. Register for a free PubNub account here. Since we’ll be using Google Maps on Android, we’ll also need a Google Maps API key, which you can obtain on the Google Maps Get API key page. To make sure we’re on the same page, these are the versions used in this tutorial: Node v10.15.0 npm 6.4.1 yarn 1.16.0 react-native 0.59.9 react-native-maps 0.24.2 pubnub-react 1.2.0 Getting Started If you want to have a look at the source code of our Tracker and Trackee apps right away, here are their GitHub links: Trackee App repo Tracker App repo Let’s start with the Trackee app first. Trackee App To create a new project using react-native-cli, type this in the terminal: $ react-native init trackeeApp $ cd trackeeApp Now let’s get to the fun part — the coding. Add React Native Maps Since we’ll be using Maps in our app, we’ll need a library for this. We’ll use react-native-maps. Install react-native-maps by following the installation instructions here. Add PubNub Apart from maps, we’ll also install the PubNub React SDK to transfer our data in real time: $ yarn add pubnub-react After that, you can now run the app: $ react-native run-ios $ react-native run-android You should see something like this on your simulator/emulator: The post Real-time Location Tracking with React Native and PubNub appeared first on SitePoint.

React Native has different database storage mechanisms for different mobile app purposes. Simple structures — such as user settings, app settings, and other key-value pair data — can be handled easily using async storage or secure storage. Other applications — such as Twitter clones — fetch data from the server and directly show it to the user. They maintain a cache of data, and if a user needs to interact with any document, they call the APIs directly. So not all the applications require a database. When We Need a Database Applications such as the Nozbe (a to-do app), Expense (a tracker), and SplitWise (for in-app purchases), need to work offline. And to do so, they need a way to store data locally and sync it up with the server. This type of application is called an offline first app. Over time, these apps collect a lot of data, and it becomes harder to manage that data directly — so a database is needed to manage it efficiently. Options in React Native When developing an app, choose the database that best fits your requirements. If two options are available, then go with the one that has better documentation and quicker response to issues. Below are some of the best known options available for React Native: WatermelonDB: an open-source reactive database that can be used with any underlying database. By default, it uses SQLite as the underlying database in React Native. SQLite (React Native, Expo): the oldest, most used, battle-tested and well-known solution. It’s available for most of the platforms, so if you’ve developed an application in another mobile app development framework, you might already be familiar with it. Realm (React Native): an open-source solution, but it also has an enterprise edition with lots of other features. They have done a great job and many well-known companies use it. FireBase (React Native, Expo): a Google service specifically for the mobile development platform. It offers lots of functionality, storage being just one of them. But it does require you to stay within their ecosystem to utilize it. RxDB: a real-time database for the Web. It has good documentation, a good rating on GitHub (> 9K stars), and is also reactive. Prerequisites I assume you have knowledge about basic React Native and its build process. We’re going to use react-native-cli to create our application. I’d also suggest setting up an Android or iOS development environment while setting up the project, as you may face many issues, and the first step in debugging is keeping the IDE (Android Studio or Xcode) opened to see the logs. Note: you can check out the official guide for installing dependencies here for more information. As the official guidelines are very concise and clear, we won’t be covering that topic here. To set up a virtual device or physical device, follow these guides: using a physical device using a virtual device Note: there’s a more JavaScript-friendly toolchain named Expo. The React Native community has also started promoting it, but I haven’t come across a large-scale, production-ready application that uses Expo yet, and Expo port isn’t currently available for those using a database such as Realm — or in our case, WatermelonDB. App Requirements We’ll create a movie search application with a title, poster image, genre, and release date. Each movie will have many reviews. The application will have three screens. Home will show two buttons — one to generate dummy records, and a second to add new movie. Below it, there will be one search input that can be used to query movie titles from the database. It will show the list of movies below the search bar. If any name is searched, the list will only show the searched movies. Clicking on any movie will open a Movie Dashboard, from where all its reviews can be checked. A movie can be edited or deleted, or a new review can be added from this screen. The third screen will be Movie Form, which is used to create/update a movie. The source code is available on GitHub. Why We Chose WatermelonDB (features) We need to create an offline-first application, so a database is a must. Features of WatermelonDB Let’s look at some of the features of WatermelonDB. Fully observable A great feature of WatermelonDB is its reactive nature. Any object can be observed using observables, and it will automatically rerender our components whenever the data changes. We don’t have to make any extra efforts to use WatermelonDB. We wrap the simple React components and enhance them to make them reactive. In my experience, it just works seamlessly, and we don’t have to care about anything else. We make the changes in the object and our job’s done! It’s persisted and updated at all the places in the application. SQLite under the hood for React Native In a modern browser, just-in-time compilation is used to improve speed, but it’s not available in mobile devices. Also, the hardware in mobile devices is slower than in computers. Due to all these factors, JavaScript apps run slower in a mobile application. To overcome this, WatermelonDB doesn’t fetch anything until it’s needed. It uses lazy loading and SQLite as an underlying database on a separate thread to provide a fast response. Sync primitives and sync adapter Although WatermelonDB is just a local database, it also provides sync primitives and sync adapters. It makes it pretty easy to use with any of our own back-end databases. We just need to conform to the WatermelonDB sync protocol on the back end and provide the endpoints. Further features include: Statically typed using Flow Available for all platforms Dev Env and WatermelonDB Setup (v0.0) We’re going to use react-native-cli to create our application. Note: you may be able to use it with ExpoKit or Ejecting from Expo. If you want to skip this part then clone the source repo and checkout the v0.0 branch. Start a new project: react-native init MovieDirectory cd MovieDirectory Install dependencies: npm i @nozbe/watermelondb @nozbe/with-observables react-navigation react-native-gesture-handler react-native-fullwidth-image native-base rambdax Below is the list of installed dependencies and their uses: native-base: a UI library that will be used for look and feel of our app. react-native-fullwidth-image: for showing full-screen responsive images. (Sometimes it can be a pain to calculate the width, height and also maintain aspect ratio. So it’s better to use an existing community solution.) @nozbe/watermelondb: the database we’ll be using. @nozbe/with-observables: contains the decorators (@) that will be used in our models. react-navigation: used for Managing routes/screens react-native-gesture-handler: the dependency for react-navigation. rambdax: used to generate a random number while creating dummy data. Open your package.json and replace the scripts with the following code: "scripts": { "start": "node node_modules/react-native/local-cli/cli.js start", "start:ios": "react-native run-ios", "start:android": "react-native run-android", "test": "jest" } This will be used to run our application in the respective device. Set Up WatermelonDB We need to add a Babel plugin to convert our decorators, so install it as a dev dependency: npm install -D @babel/plugin-proposal-decorators Create a new file .babelrc in the root of the project: // .babelrc { "presets": ["module:metro-react-native-babel-preset"], "plugins": [["@babel/plugin-proposal-decorators", { "legacy": true }]] } Now use the following guides for your target environment: iOS Android Open the android folder in Android Studio and sync the project. Otherwise, it will give you an error when running the application for the first time. Do the same if you’re targeting iOS. Before we run the application, we need to link the react-native-gesture handler package, a dependency of react-navigation, and react-native-vector-icons, a dependency of native-base. By default, to keep the binary size of the application small, React Native doesn’t contain all the code to support native features. So whenever we need to use a particular feature, we can use the link command to add the native dependencies. So let’s link our dependencies: react-native link react-native-gesture-handler react-native link react-native-vector-icons Run the application: npm run start:android # or npm run start:ios If you get an error for missing dependencies, run npm i. The code up to here is available under the v0.0 branch. Tutorial As we’ll be creating a database application, a lot of the code will be back-end only, and we won’t be able to see much on the front end. It might seem a long, but have patience and follow the tutorial till the end. You won’t regret it! The WatermelonDB workflow can be categorized into three main parts: Schema: used to define the database table schema. Models: the ORM mapped object. We’ll interact with these throughout our application. Actions: used to perform various CRUD operations on our object/row. We can directly perform an action using a database object or we can define functions in our model to perform these actions. Defining them in models is the better practice, and we’re going to use that only. Let’s get started with our application. Initialize DB Schema and WatermelonDB (v0.1) We’ll define our schema, models and database object in our application. We won’t able to see much in the application, but this is the most important step. Here we’ll check that our application works correctly after defining everything. If anything goes wrong, it will be easy to debug it at this stage. Project Structure Create a new src folder in the root. This will be the root folder for all of our React Native code. The models folder is used for all of our database-related files. It will behave as our DAO (Data Access Object) folder. This is a term used for an interface to some type of database or other persistence mechanism. The components folder will have all of our React components. The screens folder will have all the

In this tutorial, we’ll explore WordPress theme file structure in depth, and learn how to create a basic WordPress theme from scratch. In the first part of this series, we introduced WordPress theming, and the fundamental terminology relating to WordPress theme development. We covered templates, partials, template hierarchy, WordPress post types, the style.css stylesheet, WordPress filter and action hooks, WordPress loop, conditional tags, and we briefly took a look at a typical simple WordPress theme file structure. Creating the Bare Minimum Theme The first thing we’ll do is install a plugin that will enable us to batch create WordPress posts and other content. This way, we’ll be able to quickly populate our development website without losing too much time. One plugin that serves this purpose is FakerPress by Gustavo Bordoni, available in the WordPress plugin repository. [video width="1280" height="720" mp4="https://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2018/11/1542590261faker.mp4"][/video] We quickly install and activate the plugin via WP-CLI. Now, when we log in to the admin dashboard, we’ll see that FakerPress is installed, and we can create all sorts of content in batch, including any custom post types we have. Now, using this plugin, we’ll create some fake content. This is the result, using the default TwentySeventeen WordPress theme: Now, we quickly dive in and set up a bare minimum theme that consists of the catch-all index.php file, and style.css, which we need for the WordPress templating system to recognize the theme: /* Theme Name: Botega Simple Theme Theme URI: https://botega.co.uk Author: Tonino Jankov Author URI: https://botega.co.uk Description: Basic WordPress theme for Sitepoint theme building tutorial Text Domain: bsimple Version: 1.0.0 License: GNU General Public License v2 or later */ This is the style.css, which consists only of meta CSS comments for now. These comments are required. This is the index.php file. It will catch all the requests for now: <?php /** * * @package Botega_Scratch_Theme */ ?> <!DOCTYPE html> <html <?php language_attributes(); ?>> <head> <title><?php bloginfo('name'); ?></title> <link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>"> <?php wp_head(); ?> </head> <body> <header> <h1><?php bloginfo('name'); ?></h1> <h3><?php bloginfo('description'); ?></h3> </header> <?php if ( have_posts() ) : /* Start the Loop */ while ( have_posts() ) : the_post(); endwhile; endif; ?> </body> We now upload and activate the minimal theme we have. I activate it using WP-CLI: [video width="1280" height="720" mp4="https://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2018/11/1542592865activating.mp4"][/video] The theme is now visible to WordPress, and is active: We haven’t provided a screenshot, so the display in the backend is basic. If we visit our website now in the browser, this is what we’ll see: Obviously, we have work to do. If we view the source code of the home page, we’ll see that the wp_head() function has outputted a lot of default WordPress tags in the <head>, like CSS, JavaScript, link and meta tags. The bloginfo() function is used to output website information. Our home page is empty, because we aren’t outputting anything inside the Loop — a pattern that WordPress uses in all of its templates to output content. The Codex page about the Loop goes deep into details about it. A typical structure for the loop — which is based on PHP while control structure — looks like this: <?php if ( have_posts() ) { while ( have_posts() ) { the_post(); // // Post Content here // } // end while } // end if ?> We need to fill that while loop with content — or with content-outputting WordPress tags. If we change our loop, by adding the_title(), the_excerpt(), and we add HTML markup and the_ID(), to look like this: <?php if ( have_posts() ) : while ( have_posts() ): the_post(); ?> <div id="post-<?php the_ID(); ?>"> <h2><?php the_title(); ?></h2> <div class="post-excerpt"><?php the_excerpt(); ?></div> </div> <?php endwhile; endif; ?> We’ll now get a list of posts on our home page, with no style applied: WordPress shows A blog page — an archive page for all the blog posts — by default. If we now visit single post URL — something like http://my-website.com/2018/11/14/sapiente-ad-facilis-quo-repellat-quos/ — we’ll see something like this: Our loop, albeit very crude, actually works. The post How to Build a WordPress Theme from Scratch: the Basics appeared first on SitePoint.

WordPress themes give WordPress users the ability to completely change the look of a WP website, as well as add functionality to it. In this three-part series, we’ll introduce WordPress themes, showing how they work, how they’re structured, the PHP architecture behind them, and other relevant information. We’ll then embark on a journey to build a WordPress theme. This first article prepares us for this journey by discussing the theory behind WordPress themes. A Word or Two on the Basics WordPress was conceived as a blog engine, or a simple, blogging-oriented content management system. It was initially released in 2003, by Matt Mullenweg and Mike Little. Ever since then, its user base hasn’t stopped growing. WordPress is a PHP-powered web application that uses MySQL as its database, and is usually run behind a server program, such as NGINX or Apache. WordPress is basically just a bunch of PHP files that work together as an application. A PHP interpreter uses these files to produce web pages to web visitors. It produces HTML, to be more precise. The role of the templating engine of WordPress is to enable us to write (primarily) presentational instructions — instructions on how exactly to structure and style the HTML content that WordPress will output. These instructions are encapsulated in WordPress themes. Each theme consist of a folder with PHP, CSS, and sometimes JavaScript files. The files that every WordPress theme must have — at the minimum — are style.css and index.php. This is the technical minimum required for the theme to function, but no serious WordPress theme stays with only these two files. Basic template and Partials Files The minimum index.php file catches all the queries that don’t have their respective specialized template files within a theme. front-page.php, home.php, page.php, taxonomy.php, author.php, archive.php are some of the templates that we can use in our themes to further structure specific pages or queries in our theme. For example, the archive.php file will specify the HTML output structure when a visitor requests some of the pages that display list of posts. page.php will specify how to display individual pages, and so on. Partials files encapsulate repeatable parts of pages in WordPress website. For example, the header and footer are usually consistent across all pages on a website, so WordPress themes separate these page parts into header.php and footer.php. comments.php will be used to display comments wherever applicable. These files are then required from the template files that we explained. This way, we adhere to the DRY principle, and don’t repeat the code in all those files. Template Hierarchy In the WordPress templating system, there’s a hierarchy of template files that WordPress will try to use for each request. This hierarchy is based on specificity. WordPress will try to use the most specific file for each request, if it exists. If it doesn’t exist, it will look up the next, less specific file, and so on. To explain this on a page request — when the visitor visits a specific page on a WordPress website — WordPress will first try to find the template the page author assigned to it in the wp-admin backend. That can be a completely custom template file, even completely static. If there’s no such template, or it wasn’t assigned, WordPress will try to find a template file with a slug of that particular page in its filename. That would look like page-mypageslug.php — whatever our mypageslug may be. The next file WordPress will try to use will be a file with that particular page’s ID in its filename — like page-48.php. If none of those page-specific files exist, WordPress will try to use page.php — used for all the pages, unless otherwise specified. If it doesn’t find page.php, it will try to use singular.php. This template file is used when — for posts — single.php is not found, and for pages when page.php is not found. Now, if none of these are found in our page request example, WordPress will fall back to index.php. This, briefly, explains the WordPress template hierarchy. All of these template files we mentioned will usually incorporate (require) partials like header.php, footer.php and others as needed. They can also specify their specific partials to use — for example, a page-specific header. The next thing you need to be familiar with to understand theming is the WordPress post type. WordPress Post Types The content in WordPress exists in the form of post types. The built-in types are posts and pages. These are the logical ones. WordPress also has a built-in attachment post type, navigation menus and revisions. These are also, technically, post types. We can also specify our own post types, whether in our themes or our plugins. We need use the following: register_post_type( $post_type, $args ) Here, we specify the post type name, how it’s structured, how it’s represented in wp-admin, and so on. When we have this defined, we can also create template files specific for this post type. Custom post types, like pages and posts, have their own template hierarchy. More about the template hierarchy can be found here. The post How to Build a WordPress Theme from Scratch: First Steps appeared first on SitePoint.

This article provides an introductory guide to WP-CLI, a command-line tool that was created to make developers’ lives easier, allowing them to manage a WordPress site through the command line rather than through the usual admin interface. WP-CLI was created by Daniel Bachhuber over a decade ago. Since then, it’s become an indispensable tool in every advanced WordPress developer’s arsenal — “deployed and relied upon by almost every major user of WordPress”, according to Matt Mullenweg. Since 2016, WP-CLI has been an official WordPress CLI tool. WP-CLI is used for installing and setting up a WordPress website, changing its options, administering users, and a host of other things. It can be leveraged to significantly speed up developers’ workflows. WP-CLI comes as a phar file — short for PHP Archive. It’s a standard for packaging multiple PHP files and other resources as a single application — for simpler distribution and installation. Installation WP-CLI presumes, obviously, that we have access to the system shell. This will be pretty straightforward on Linux and macOS systems — particularly on servers — as WordPress is served almost universally from Linux machines. If we have dedicated server hosting, or cloud hosting like AWS, Alibaba Cloud, etc., or if we’re using a VPS from Digital Ocean, Vultr, Linode and the like, SSH comes as a default access option, but these days many shared hosts offer SSH access options. (Some might even come with WP-CLI preinstalled.) For Windows users, WP-CLI can be installed via Composer, but we recommend readers get themselves acquainted with Windows Subsystem for Linux, because it makes it possible to have a native Linux environment available, along with Bash, package manager like APT, etc. WordPress is a PHP app, and PHP’s native environment is Linux. Further code samples presume we’re using Linux or a Unix-type system. To fetch the WP-CLI phar archive, we usecurl or wget: curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar This downloads our archive to the current directory. Then we make it executable: chmod +x wp-cli.phar We them move it so it’s available as a wp command: sudo mv wp-cli.phar /usr/local/bin/wp Now we have a wp command available: [video width="600" height="" mp4="https://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2018/11/1541465872wp.mp4"][/video] Now, upon typing the wp command, it displays all the options for us, and possible parameters. One caveat: if we’re running as the root user, we need to add --allow-root to our commands: Now that we have it set up, we can explore the commands, and possible usage scenarios. WP-CLI Commands WP-CLI aims to offer a fast alternative to the WordPress web admin interface. There are chunks of code or functionality that offer simple, precise interfaces for performing complex tasks. Beside the bundled commands, WP-CLI defines an API for integrating third-party commands — WP_CLI::add_command(). These can be distributed either as standalone packages, or as part of WordPress plugins or themes. In this guide, we’ll review bundled commands — those that come with the default WP-CLI installation — and some more notable third-party commands. Commands can come as basic, one-argument commands like wp somecommand, or as subcommands under the base command namespace, such as wp somecommand subcommand. wp core The wp core subcommand is a command/namespace that consists of sucommands that deal with WordPress core — so we can download, install, update, convert to multisite and get information about our WordPress core version: wp core download will download the latest version of WordPress into the current directory wp core install runs the standard WordPress installation process, with options like --url=somewebsite.com, --title=SomeWebsite, --admin_user=someusername, --admin_password=somepassword and --admin_email=some@email.com wp core multisite-install installs a new multisite WordPress installation, and wp core multisite-convert converts a regular installation into multisite. wp core update will update WordPress to a newer version, and wp core update-db will update the database. More details on wp core can be found in the documentation. WP-CLI really shines when we combine its commands in Bash scripts, so we can combine, for example, wp core download and wp core install into a single Bash command and streamline the installation. Worth noting here is that before we run the installation, we need to create a wp-config.php file, with database credentials and other details needed for the installation. WP-CLI provides a wp config create command for this. The post An Introductory Guide to Managing WordPress with WP-CLI appeared first on SitePoint.

In this guide, we’ll introduce the WordPress Settings API, and create a WordPress administration page where we demonstrate the use of this API. For the purposes of this tutorial, we’ll wrap this functionality into a plugin, but this can also be a part of a WordPress theme. As the WordPress Codex says, the Settings API was added in WordPress 2.7 to streamline adding different settings fields and sections in administration pages. Creating the Plugin To start, we’ll create and activate a plugin to encapsulate our options page. We’ll use WP CLI to simplify the creation, although this leaves us with way more files than this guide needs. [video width="822" height="352" mp4="https://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2018/11/1541423763plug.mp4"][/video] As we can see, we use wp scaffold plugin pluginname to create the plugin. Once it’s created, we activate it — optionally also using WP CLI, with wp plugin activate pluginname. Once it’s activated, we open the main plugin file — in this case sitepoint-settings-api.php. Creating the Admin Page It isn't necessary to use WP CLI for this plugin. We could have simply created a directory with the name of the plugin, and the PHP file inside it with the same name. Anyhow, the creation of the plugin has left us with a sitepoint-settings-api.php which looks like this: <?php /** * Plugin Name: Sitepoint Settings Api * Plugin URI: PLUGIN SITE HERE * Description: PLUGIN DESCRIPTION HERE * Author: YOUR NAME HERE * Author URI: YOUR SITE HERE * Text Domain: sitepoint-settings-api * Domain Path: /languages * Version: 0.1.0 * * @package Sitepoint_Settings_Api */ ~ Now we can simply add code after the comment end. To add our options page, we’ll use add_options_page() (more details about it here). This function takes arguments as follows: add_options_page( $page_title, $menu_title, $capability, $menu_slug, $function ); All the arguments are self-explanatory. $menu_slug must be a unique string that WordPress will use internally, but will also be reflected in the URL. $function is a string with a name of the function that will provide HTML output for our admin page. We will, therefore, add the following code to our plugin file: add_action( 'admin_menu', 'sitepoint_settings_page' ); function sitepoint_settings_page() { add_options_page( 'Settings API Page', 'Settings API Page', 'manage_options', 'settings-api-page', 'settings_api_page' ); } After we’ve saved the file (presuming we activated our plugin), we’ll open our administration dashboard, and we’ll find our Settings API Page under Settings in the left side menu. We can control, to a degree, the order or position of the submenu item by adding a priority argument to our add_action() function: add_action( 'admin_menu', 'sitepoint_settings_page', 1 ); If we want to have our menu item to be in the root menu — rather than the Settings submenu — we’ll use add_menu_page(), which takes similar arguments. Now, if we open the page in our browser, all we’ll see is an empty page, because we still haven't created the settings_api_page() function that we specified: The Settings API The WordPress Settings API is an intricate mechanism that attempts to provide an easy way for developers to create settings pages. Before we go into a full-fledged example of the settings page displaying and saving a setting to the WordPress database, we’ll explain couple of crucial functions that WordPress provides as part of its Settings API. register_setting() is a function we use to register a setting, which equals a row in wp_options table. Before we can create actual field (or fields, as setting can be an array of values), we need to register it. This way we’ll leverage the WordPress CRUD mechanism for settings. Function arguments are as follows: register_setting( string $option_group, string $option_name, array $args = array() ) The first two arguments are mandatory, the first one allowing us to assign fields to it, and $option_name, as we’ll see, is the actual option name in the WordPress database. add_settings_section() defines/adds a section to an admin page. Its arguments are as follows: add_settings_section( string $id, string $title, callable $callback, string $page ) $callback is a function that outputs an HTL header of the section (it can be empty), and $page is the slug of the admin page we’ll display it on. add_settings_field() defines a settings field within a settings section in an admin options page. Arguments for it are: add_settings_field( string $id, string $title, callable $callback, string $page, string $section = 'default', array $args = array() Of these, $id, $title, $callback and $page are required. The $callback function should output the HTML of the input field. The Settings API provides $page argument for add_settings_section and add_settings_field as a means to add sections and fields to existing settings pages. We’ll use stpPlugin for both our option group — in register_setting() — and for attaching the settings section and settings fields to a ‘stpPlugin’ page in the add_settings_section() and add_settings_field() functions. We’ll then “quote it” in the next two functions in our example, to output relevant HTML. settings_fields() outputs “nonce, action, and option_page fields for a settings page”. It takes the $option_group argument, used in register_setting(). do_settings_sections() outputs all the sections, with their respective fields, registered for a specific $page. $page is the only argument here. The post Using the WordPress Settings API to Build a Custom Admin Page appeared first on SitePoint.

This article on preparing for the XR future was originally published by Torque Magazine, and is reproduced here with permission. You’ve probably heard rumblings in the tech industry around the innovations in Virtual Reality, Augmented Reality, and Mixed Reality. These mediums can broadly be defined as Extended Reality or XR. My first venture into development in XR was in 2010 when I was exploring Flash development. My application was straightforward; show the webcam a Quick Response (QR) code and the program would superimpose a 3D model to the marker. In hindsight, this was such a life-changing moment for me. On top of being my first experience with manipulating digital 3D objects, it was also my first augmented reality experience accessible to the web. The concept of a screen will likely be an afterthought in the coming years as we start blending the lines between our physical and digital selves. We will likely be surrounded by personalized versions of our environments and all of this personalization will be stored as meta in a database someplace. It is crucial for everyone to be able to have the power to control this meta and I’m optimistic WordPress will have a place in this because that’s where it really shines. WordPress allows you to do all of the hard things in content management with little knowledge of how it is working under the hood. I don’t need to know how to build a user system from the ground up…I can just use WordPress. Content and meta will be a constant in our lives and, in my opinion, WordPress has secured a very nice spot in the future with the incorporation of the REST API. Anything that can make a HTTP request is now able to take data from WordPress and make intelligent decisions based on it. Maybe the structure of this approach will change in the coming years as different concepts such as GraphQL progress, but overall, the requirement of restful ways of handling data will likely remain constant for WordPress. How Would an MVP WordPress Look in XR? Last year, I sought to build a minimum viable VR WordPress using only the features we have available in a standard WordPress instance. I used Unity3D for my prototype as it was the lowest barrier to entry (FREE). The idea for this prototype was easy; use post data to populate UI elements in the VR world and use the featured 360 image of the post as a skybox around the user. My imagined use case for this was to be a mock travel blog. Here’s what that looked like: [video width="716" height="402" mp4="https://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2018/10/1539909478mars.mp4"][/video] Here’s the flow of data and requisites: This really isn’t too rough of a concept. We make a REST call via C# using the WWW function. We take the data returned from WordPress and save it to a variable that the Unity Dev would assign using the simple drag and drop editor tooling. Unity takes the defined UI elements and applies the text stored in the variable to their mapped text object. I’ve open sourced this project at the following repo. (Note: this was done in a two-day hackathon last year. This far from production ready code.) The post Preparing Your Content for the Extended Reality (XR) Future appeared first on SitePoint.

This article was originally published on Cloudinary Blog. Thank you for supporting the partners who make SitePoint possible. Videos in web sites and apps are starting to catch up with images in terms of popularity and they are a constantly growing part of the media strategy for most organizations. This means bigger challenges for developers […] Continue reading %The Complete Video Solution for Web and Mobile Developers%