Adding Post Types and Taxonomies to Custom Admin Menu Pages

WordPress Admin Menu

Customizing the WordPress admin menu is something you’ll eventually need to or want to do at some point. Customizing admin menus with Post Types is pretty easy compared to Taxonomies.

When you create Custom Post Types and Custom Taxonomies in WordPress using register_post_type(); and register_taxonomy(); there’s a parameter for each function called show_in_menu.

If you look at register_post_type(); the parameter accepts a simple true or false but also accepts a string as an argument for show_in_menu:

show_in_menu
(boolean or string) (optional) Where to show the post type in the admin menu. show_ui must be true.

Default: value of show_ui argument

‘false’ – do not display in the admin menu
‘true’ – display as a top level menu
‘some string’ – If an existing top level page such as 'tools.php' or 'edit.php?post_type=page', the post type will be placed as a sub menu of that.

Note: When using ‘some string’ to show as a submenu of a menu page created by a plugin, this item will become the first submenu item, and replace the location of the top-level link. If this isn’t desired, the plugin that creates the menu page needs to set the add_action priority for admin_menu to 9 or lower.

Note: As this one inherits its value from show_ui, which inherits its value from public, it seems to be the most reliable property to determine, if a post type is meant to be publicly useable. At least this works for _builtin post types and only gives back post and page.

If you look at register_taxonomy(); the parameter accepts a simple true or false but DOESN’T accept a string as an argument for show_in_menu like register_post_type(); does:

show_in_menu
(boolean) (optional) Where to show the taxonomy in the admin menu. show_ui must be true.
Default: value of show_ui argument

‘false’ – do not display in the admin menu
‘true’ – show as a submenu of associated object types

Adding a Custom Post Type to a custom admin menu is simple. Just specify the slug of the custom admin menu as an argument for the show_in_menu parameter while using register_post_type();.

How about adding a Custom Taxonomy to a custom admin menu? That’s a bit tricky to do.

What I’m about to show you works for both Custom Post Types AND Custom Taxonomies. So do with it what you please.

Step 1 – Hook into init and register Custom Post Types and Custom Taxonomies.

 

Step 2 – Hook into admin_menu to create a custom parent admin menu, and add Custom Submenu Admin Pages, Custom Post Type pages, and Custom Taxonomy Pages all to the custom parent admin menu.

 

Step 3 – Hook into parent_file to correctly highlight your Custom Post Type and Custom Taxonomy submenu items with your custom parent menu/page.

If you need any clarification about how any of this works, read the following pages from top to bottom:

  1. Adding Custom Parent Admin Menus
  2. Adding Custom Child Admin Menus
  3. Roles and Capabilities in WordPress
  4. Registering Custom Post Types
  5. Registering Custom Taxonomies
  6. WordPress Plugin API :: Action Reference
  7. WordPress Plugin API :: Action Reference :: init
  8. WordPress Plugin API :: Action Reference :: admin_menu
  9. WordPress Plugin API :: Filter Reference
  10. List of All WordPress Hooks (including actions and filters)

Credits:

Original question asked by @numediaweb on WordPress Stack Exchange: Show custom taxonomy inside custom menu.
Answer to Question: Show custom taxonomy inside custom menu by @Michael Ecklund on WordPress Stack Exchange.

WordPress Multisite With Top Level Domain Names (TLDs)

WordPress Multisite With Top Level Domains (TLD)

The question of “How can I WordPress Multisite With Different Domain Names?”, seems to come up rather frequently.  There always seems to be a bit of confusion on this topic as well.

The WordPress Codex illustrates multisite to be used for subdirectories and subdomains of a single Top Level Domain (TLD). Granted, this is WordPress’s intended purpose for Multisite, it doesn’t mean that you CAN’T use multisite for TLD’s.

A lot of people seem to think that it’s a REQUIREMENT to use a 3rd party plugin in order to pull off using WordPress Multisite with TLD’s. Let me tell you, that’s absolutely NOT the case. There’s no requirement for third party plugins for use TLD’s with WordPress Multisite.

Why Use WordPress Multisite?

I’m not going to go into great detail about why you should use multisite in this article, but I do want to touch base on the basic reasons why I think it’s beneficial to use multisite to manage multiple WordPress websites.

If you’re maintaining multiple WordPress websites, you’re probably well aware of how much time is consumed with updating the core WordPress platform, along with any additional WordPress Plugins or WordPress Themes associated with each WordPress website. It can become a rather tedious process to keep everything updated and consistent across all websites that you manage.

By now, you probably use some kind of “Framework” or “toolset” of plugins / themes to keep all of your websites structurally similar behind the scenes. This makes maintaining your websites a lot easier, right? WordPress multisite can help improve that process.

You probably also notice once you begin to have several WordPress websites on a single Web Server, how much of a load that can produce. WordPress multisite can help reduce server resource consumption as well.

There are several reasons why you shouldn’t use WordPress Multisite. The biggest concern would be security, but I’m not going to get into all of the reasons why you shouldn’t use multisite right now. You can Google that, or perhaps I can elaborate more on that subject in a separate article another time.

If you’re the only one with access to the Web Server and Database Server, then those security concerns are basically nothing to lose sleep about.

How to Use WordPress Multisite With Different Domain Names

Step 1 – Install WordPress and Enable WordPress Multisite

  • If you’re unsure about how to install WordPress, click here.
  • If you’re unsure about how to enable WordPress Multisite, click here.

Note: It’s important that you configure WordPress Multisite to function as a “subdomain” based network.

I’ve experienced some strange behavior when using TLD’s with a subdirectory configuration. Switching over the the subdomain configuration instantly remedied the bizarre problems I’ve encountered.

Step 2 – Edit wp-config.php in the Base Directory of Your WordPress Installation

Here’s an example of how my wp-config.php file looks like (related to configuring WordPress as subdomain network):

Note: Replace www.primary-domain.com with the “Master domain”. I would recommend making sure this domain has it’s own Virtual Host on your Web Server. Each extra TLD you add to your network can simply be a Domain Alias of your Master Domain’s Virtual Host file. More on this further down the article.

Now in order to get TLD’s to behave properly, make some additional configurations to the wp-config.php file like this:

Step 3 – Edit .htaccess in the Base Directory of Your WordPress Installation

Here’s the basic configuration for your .htaccess file as a subdomain network:

Extra Notes on Using TLD’s With WordPress Multisite

Personally, I like to have one Apache Virtual Host for the primary domain in the network and then configure that virtual host with alias domains. Each alias domain being one of the additional sites in your network.

However you end up tweaking your setup, you need each domain’s DNS to resolve to the same Web Server, and each domain to be pointed to the same directory the primary domain is installed with WordPress. Each domain in your network needs to point to the same Web Server with DNS records and share the same directory path for the files used by WordPress.

Once you’ve got everything configured and setup properly as discussed above. Log into your WordPress administration area and navigate to the Network administration area to add a new site into your network.

When you go to add a site, it will enforce you to add the website as if it were a sub domain under your primary domain. Just roll with it. Enter something temporary.

Once the site has been added, then go find it under the list of sites in your network. Click edit on that specific site. Now, you can fully 100% change the domain name of that website. That’s when you would put the actual domain name for this TLD site.

I know it’s a bit of trickery to do it that way, but it works and you don’t need to use any plugins.

Credits:

Original question asked by @Kevin.a on WordPress Stack Exchange: WordPress Multisites with different domain names.
Answer to Question: WordPress Multisites with different domain names by @Michael Ecklund on WordPress Stack Exchange.

Widget Ready WordPress Template Files Displayed Conditionally

Widget Ready WordPress Template Files Displayed Conditionally

As a WordPress developer, part of my concern for my WordPress users is the ability for them to change their WordPress website content as much as possible; Without having to resort to contacting me to do so for them. This makes me think outside of the box on how I can make the WordPress theme have an intended layout, while allowing the flexibility of dynamic content. That’s where widgets come into play!

WordPress Widgets provide a structured way to allow dynamic content in a specific area of your theme without (or at least minimize the chance of) breaking the layout.

I really think widgets are the wave of the future with WordPress theme development. Especially with all the fancy updates to the WordPress theme customizer.

If you’re a WordPress theme developer and you’re theme’s aren’t “widget ready”, you should really change that. You can start by reading the rest of this article. 🙂

The following “How to Conditionally Display Widget Ready WordPress Template Files Tutorial” is very basic and bare-bones, but enough to give you the idea to run with.

Disclaimer: This “how to / tutorial” doesn’t cover WordPress theme options. This assumes you already have your WordPress theme settings managed in some way.

In this “how to / tutorial” I’ll demonstrate how you can give your WordPress users more control over the header section of their WordPress website. Although, don’t stop your creativity there. You could apply this basic idea in many other conventions.

Step 1 – Tell WordPress About the “Widget Areas” Supported by Your WordPress Theme.

The following code should be pasted in your currently active WordPress theme’s functions.php file:

Step 2 – Create the WordPress Template Files for Each Type of Header.

In this example, you’ll want to create 4 new template files in the root directory of your currently active WordPress theme:

  1. header-column-1.php
  2. header-column-2.php
  3. header-column-3.php
  4. header-column-4.php

Step 3 – Make Each New WordPress Header Template File “Widget Ready”.

In this example, I’ll demonstrate a 4 column header template (header-column-4.php):

Step 4 – Edit header.php in Your Currently Active WordPress Theme to Activate Dynamic Header Output.

There you have it! You can now “dynamically” display content in your header template file using widgets. Optionally, you could display static content which could serve as you “default content” or “fallback content” in-case there’s no widgets assigned to that particular widget area.

This small and simple change can really add a lot of flexibility to your WordPress theme.

Credits:

Original question asked by @AlonsoF1 on WordPress Stack Exchange: Show/hide widgets in WordPress admin based on current Advanced Custom Fields option.
Answer to Question: Show/hide widgets in WordPress admin based on current Advanced Custom Fields option by @Michael Ecklund on WordPress Stack Exchange.

Numerical Pagination w/ WordPress Archives & Custom Queries

Numerical Pagination

I came across an interesting question (Pagination doesn’t work) that just happened to “catch my eye” on the WordPress Stack Exchange, regarding a numerical pagination.

In the question asked by @Paul I noticed he made use of the WP_Query class to perform a custom query in order to fetch posts from a Custom Post Type.

That’s totally fine and actually very practical / common when dealing with various WordPress archives.

The problem when you create a custom query is: now you can’t use a lot of the default functionality as you normally would have; You need to make some adjustments.

Most of the WordPress functionality has to do with the default query which is performed on every page load. When you create a custom query using WP_Query, you’re not replacing the default query with your custom query. You’re adding a SECOND query (your custom query) to run parallel with the FIRST query (the default query).

Most (if not all of the WordPress functionality) expects the default query, but can be customized in-order to produce the desired result.

It would be best to only have ONE query instead of TWO queries for the requested page, especially if they’re querying the same source.

You can customize the default query several different ways, but the most common way would be to hook into the pre_get_posts action and modify the query before the query is performed. There are also more complex ways of modifying the query, for example, modifying the SQL using the filter hook posts_request.

This can be a tricky task and if not careful can actually cause unexpected behavior in other areas throughout your WordPress website.

This is why WordPress developers often choose to just create a brand new custom query using WP_Query to retrieve exactly what they want, without the worry of interfering with other areas of their WordPress website.

So in this article I’ll be demonstrating how to create a numerical pagination to add to your WordPress archive pages, when the posts have been fetched using a custom query via WP_Query instead of using the default query available by WordPress.

To begin, you’ll need to start by setting up your custom query. Your query might look something along the lines of:

If you want your numerical pagination to work with your custom query, then you need to be aware of the current page the request is performed on.

The current page number is actually referred to as paged. You can determine the current page number using some code like this:

Once the current page has been determined, you can setup your custom query to look similar to this:

Once the query has been performed, you then need to check if it’s located any posts in the database which match your criteria:

Finally! Now for the numerical pagination! I recommend using a WordPress function called paginate_links() for this part.

I don’t really understand the really unlikely integer part for the base, but that’s what’s demonstrated on the WordPress Codex page linked above.

  • You need to specify the current page (paged) — once again.
  • You need to know the total number of posts (which can be obtained from the $query variable object).
  • You need to specify a return type for this function. (Personally, I like it to be in array format, so that I can customize the pagination however I see fit).

This code needs to be placed within the condition which states that we have posts available. Not inside the loop, but immediately AFTER the loop.

Once the numerical pagination has been configured, it’s ready for output (or ready to be displayed). This is where paginated items are returned in array format.

I like to wrap it with a conditional check and then loop through the items performing additional conditional checks along the way.

 

Note: I use Bootstrap for my WordPress themes. So if you want your pagination to look awesome, with minimal effort involved. Try out Bootstrap.

To conclude everything mentioned above, here’s a all-in-one copy/paste starter solution for anyone looking to create a numerical pagination with a custom posts query using WP_Query.

 

Credits:

Scheduling Events in WordPress | WordPress Cron Jobs

Scheduling Events in WordPress | WordPress Cron Jobs

Automated Tasks Scheduled Events in WordPress Cron Jobs

Creating cron jobs in WordPress is actually really simple but yet, so many WordPress developers don’t understand WordPress cron jobs or they understand the concept of WordPress cron jobs but don’t know how to set them up appropriately.

This article is targeted to slightly more advanced WordPress developers while aiming to explain what WordPress cron jobs are, how they work, and how to use them appropriately.

Most of the content in this article was taken from an answer I originally posted on the WordPress Stack Exchange to the question “WP Cron desn’t execute when time elapses“.

What Are Cron Jobs?

I would like to clear the air a bit about WordPress cron jobs before moving forward.

Cron jobs are tasks that executed until completed at specified time intervals of time, which usually reoccur numerous times. Cron jobs are especially useful for automatically executing tasks that might have originally needed to be manually executed.

Web Server Cron Jobs vs. WordPress Cron Jobs

There is a difference between a cron job which is setup via your web hosting platform or web server and the cron jobs setup on WordPress. Cron jobs setup directly on the server are guaranteed to execute dead on the time intervals specified.

A WordPress cron job is exactly the same as a cron job setup via your web hosting platform or web server. They both execute tasks automatically for you at specified time intervals.

Executing Automated Tasks and Scheduling Events in WordPress with WordPress Cron Jobs

There is one draw back to using the WordPress cron jobs. WordPress cron jobs require a page visit to anywhere on your WordPress website in order for your tasks to be executed. That is because WordPress is a “pseudo-cron system”.

The positive to using WordPress cron jobs is that it’s incredibly simple to execute functionality specific to your WordPress website.

WordPress Cron Schedules

Firstly, define your custom WordPress cron job schedules using the WordPress filter hook cron_schedules.

Example: Defining a WordPress cron schedule every: 30 minutes, 1 hour, 2 hours.

Schedule WordPress Task at Specific Time Interval (WordPress Cron Schedule)

You need to decide where and when to actually schedule the event. Here is just an example snippet of code, which makes a call to a custom class method (This can be done with functions as well):

Here is the code which actually schedules the event:

Task Executed Automatically by WordPress at Specified Time Interval (WordPress Cron Schedule)

Now, all you need to do is make a call to the name of your custom cron task. In this example the cron task name is custom_imap_import.

So in this example, mbe_do_imap_import(); is called every 30 minutes (assuming you have enough traffic to your website).

Extra Information About Scheduling Events in WordPress using WordPress Cron Jobs

* Requires a page visit in order for your cron job to fire at correct times.

Example: If you scheduled a task at 30 minute intervals, but no one visits your site for 4 hours, your cron job won’t be fired until that visitor comes to your site 4 hours later. If you really truly need your task fired every 30 minutes, then it is advised to setup a legitimate cron job via your web hosting provider to visit your website at the desired intervals.

WordPress cron jobs don’t make your website slow!

Maybe you are thinking what if the cron-script takes a long time to be executed, will the visitors have to wait until the script is executed? Nope! How can that be possible? If you look at the wp-cron.php file you will find a line

ignore_user_abort(true);

It’s a php.ini configuration that sets that if you stop loading the site/script the script won’t stop executing.

If you look at the wp-includes/cron.php file you’ll find a line similar to this:

That means WordPress will wait only 0.01 second for triggering the execution then it will abort but as you have set ignore_user_abortto true the script will be executing. This functionality is a huge advantage to execute large scripts in WordPress cron jobs.

WordPress functions related to WordPress Cron Jobs

WordPress Stack Exchange

Remember, this article is just a summary of an answer to a question (WP Cron doesn’t execute when time elapses) I wrote on WordPress Stack Exchange.

If you have a question related to WordPress, you can asked it on WordPress Stack Exchange and someone will very likely provide an answer or solution to your question or issue.

If you don’t get an answer in somewhat of a timely manner, feel free to contact me with a link to your question on WordPress Stack Exchange and I will try to find time to answer it for you.

Calculating the padding-top Percentage of Aspect Ratio

Aspect Ratio

This is a mathematical formula which really comes in handy when trying to maintain the proper aspect ratio of let’s say a <div> container as the screen is resized.

Here’s the formula: ( B / ( A / 100 ) ) = C%

Here’s an Example:

  • Aspect Ratio: 16:9
  • Formula: ( 9 / ( 16 / 100 ) = 56.25% )

Here’s an example of pure HTML and CSS code used to maintain the Aspect Ratio of a <div> container.

CSS:

HTML:

Credits: