MeetMe Lite is the free version of the MeetMe Resume HTML template by UIdeck. The free version includes this neat CV layout featuring a fixed header navigation (that smooth scrolls to sections), biography with profile photo, education timeline, work experience, image gallery with Lightbox functionality, stats and contact details.
This article on developing a WordPress REST API app was originally published by Torque Magazine, and is reproduced here with permission.
Excitement over the WordPress REST API has been building for what seems like an eternity, but we’re still pretty much at the starting gate in terms of what it’s actually going to mean for site owners and developers once it finally lands.
Though I’ve written extensively about the potential implications of the REST API, I’ve been holding back on actually diving in and getting my hands dirty to date. With the REST API finally taxiing on the runway, now seemed a great time to grasp that nettle and really start digging into detail.
Over the course of this series, I’ll be taking the new hotness for a spin by putting together a simple JavaScript app that uses the REST API to power its content. It promises to be an intense learning experience, but one that will hopefully serve others who are coming from a non-technical background as well.
Though WordPress has long been a passion of mine, I’m a writer and entrepreneur by trade. I can’t pretend to be coming at this project from any type of serious development background. “Knows just about enough to be dangerous” would be how I’d charitably classify my coding experience to date.
So, this series won’t be quite the deep dive you might expect from a theming professional such as Jack Lenox, or a senior web developer such as Ramsay Lanier. It should also be no great surprise that I’m not approaching this from the point of view of an established top-tier digital agency looking to kick the tires of the latest technology.
Major agencies such as Modern Tribe are already working with the REST APINope, this series will be much more along the lines of an average WordPress user looking to get to grips with the next generation of the platform via a practical, exploratory project.
Hopefully that’s an approach that will also resonate with a significant percentage of other site owners out there. Put it this way – if your eyes instantly start to glaze over at the introductions of other (admittedly excellent) tutorials such as the one below, this is the series for you:
In the following weeks, through a series of articles, I’ll explain how I’m using Node.js and Express on the backend with a GraphQL server hooked up to a MYSQL WordPress database that uses Apollo to fetch data and pipe it into React components. Don’t worry, I’ll still be using the tried and true WordPress admin interface.
With those caveats out of the way, let’s briefly recap why now is a great time to be really rolling up your sleeves and using the REST API in earnest.
The launch of Calypso and Matt Mullenweg’s State of the Word address back in late 2015 made it crystal clear which way the wind is blowing in the world of WordPress at large. To put it in a nutshell, the REST API is going to be at the centre of the next stage of the platform’s future, and developers are going to have to get on board with JavaScript sooner rather than later.
We’ve already seen entire conferences devoted to exploring the implications of the REST API, and increasingly large real-world projects basing themselves around it, despite its late arrival. From Microsoft to the New York Times, blue-chip companies worldwide are chomping at the bit to really explore its power.
If you’re a theme or plugin developer, you can rest assured that the vast majority of your competition are already, at the very least, actively researching the topic. If you’re a site owner, you can expect the next five years or more of your site’s development to be significantly defined by the possibilities that the REST API opens up. No matter what way you look at it, now is the time to get on board this particular train.
The post Developing a WordPress REST API App: Getting Started 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.
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.
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.
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.
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.
Such a beautiful design in this One Pager for ARK, an initiative by Cregital Agency to help charitable causes in Nigeria. Lovely touch with the friendly animated characters, the floating team members, the unique contact form design and of course the dark mode. My only real crit is there needs to be a ballpark USD comparison to the Nigerian Dollar amount for context.
