Author: Ben Rothman

Sometimes in WordPress or really on any other site you have to show something on your site that uses the results from another server like an API call or data about something someone else owns.

If you want to increase efficiency and not have to hit and wait for a response from the foreign resource every time a user does a search and the search itself is common, WordPress has a built in method for this called “transients”. If you have a bit of data that you have to call more than once and takes a lot of resources to get/calculate, you may want to store it in a transient so the data is stored in an easy-to-access place.

A transient is a single piece of data that is stored in the options table like an option, but they are different in that they expire. If I am storing API results, I would not want to store results in 2012 and then have a user in 2022 use the same data. There is a good chance that the API has changed and that data is no longer correct. So a transient is to store a bit of calculated, usually external data, for easy retrieval within a reasonable amount of time. If the transient has expired when the second user does the same search then the API results are gathered again and the transient is remade with the new data and with the expiration timer starting over. Let’s take a look at how transient code looks:

// if the transient does not exist or exists but expired
if ( get_transient('search_results_' . $search_term) == false ) {

            // get the search data for the term from the API
            $contents = wp_remote_get( 'https://APIURL/' . $search_term);

            // get only the body of the API response
            $body = wp_remote_retrieve_body( $contents );

            // decode the JSON array response for use into a PHP array
            $api_results = json_decode($body, true)['entry'];

            // delete expired transient if it exists
            delete_transient( 'search_results_' . $search_term );

            // since there was no valid transient for this search, store the results
            set_transient( 'search_results_' . $search_term, $api_results, 3600 );

        // the transient does exist so get the value from the database where it was stored last time
        } else {

            // since this search was done before and stored, get the stored results
            $api_results = get_transient( 'search_results_' . $search_term );

        }

I have been a supporter of WordPress for years, and will continue to support it’s mission to democratize publishing. So many of the ideas WordPress has introduced over the years have been amazing, but the theme.json beyond use as a description file was almost a good idea with much to be desired in the execution. As is done in Twenty twentyfour at the time of writing this, we should stick to using functions.php for all code and only have the theme.json file be there to give metadata about the theme. I am not suggesting we abandon the idea of a theme.json or roll it back entirely, I am just suggesting we do not try to use it to do things like add styles or load scripts. I think Sam Hermes gets this just right in his article at https://samhermes.com/posts/slowly-backing-away-from-theme-json .

The theme.json file is a cool idea, but the execution is not very cool. Having the file allows you to convey theme information which is useful but it also allows us to edit a lot of features of WordPress that most people do not need. It takes away features that people do need by hiding them or making them impossible. The process introduced by theme.json is also potentially alienating long-time users who are used to the way things already worked in “classic” WordPress, and the use of the file is not bringing in new users. “Did you hear that WordPress lets you just write JSON to edit the theme now? Sign me up!” Obviously no one who is not a developer ever said that so the feature that is supposed to attract developers with a more efficient workflow just ends up alienating them because the things they knew and loved about WordPress are gone or different now. The feature ends up attracting no one new and alienates the old user base so it is really a loser of a feature all around.

I suggest we only use the theme.json for limited metadata about the theme, and we go back to using functions.php for the important theme configuration. I want to emphasize that I am not saying to get rid of the theme file, I am just suggesting we make sure it is not important and go back to using the functions.php file for everything code.

At work, I work on several WordPress classic sites and one WordPress site that uses a theme.json. The theme.json site is not bad, and from the front-end user view it is no different from any other site. On the admin side of the site it is a different story, it does have a few differences which I find ok, but it also has a few differences which I do not find ok. Thankfully, we can and did use a supplementary functions.php with the theme.json file.

It sounds efficient to have your different kinds of code and theme functionality simplified by being set with one language and all sent from one place by json which is what the theme.json file does. In reality of course, if someone is editing a json file and writing code then they are a developer. This feature is meant to attract developers but does not. A random non-developer is never going to write a code file in the filesystem of their web server, and that should not happen. The WordPress platform out of the box with plugins allows users to make semi-complex sites without any assistance already, but that is kind of the limit of what a normal person can make without hiring some help.

This coming on the heels of the even worse decision to remove ‘Menus’ from the dashboard, stop using the header.php file as well as the footer.php. Why are we changing WordPress so drastically when it was the market leader for CMSs by far in a way that makes it more similar to it’s failing “competition”? I put that word in quotes because technically they were competition but they were all so far behind.

Can a regular person wire their house with electricity? Maybe in a few cases but the answer is generally no so they hire a specialist to do it. Who is WordPress core making this theme editing process better for? Some random, unassisted person is not going to write code, so why are we making it easier for them? The users the theme.json is made to help will never use it. Let’s pivot away from using theme.json to do theme code adjustments in favor of using it to store metadata (like theme headers and possibly a simplified way of adding fonts to the theme) and use the functions.php file to add/modify the code.

Several of the webpages and plugins that I have made with WordPress needed to update the database in some way or reference PHP on a button click. Since PHP and access to the database are run before page load, that seems impossible. This need to run PHP on as a response to user input when a button is pressed is exactly the case that an asynchronous AJAX call like the one I am about to show you comes in handy. Making this asynchronous call work is a multi-step process, but when it works it will do exactly what you want it to do.

First, in functions.php file, enqueue the script as normally but localize the script with a nonce which we will use for security purposes later:

wp_register_script( 'script', plugin_dir_url( __FILE__ ) . '/library/js/script.js', [ 'jquery' ], 'all', true );
wp_localize_script( 'script', 'cp_script', [
	'ajaxurl' => admin_url( 'admin-ajax.php' ),
] );
wp_enqueue_script( 'script' );

Then in the JQuery file, use create a handler for a user clicking a button and in the response include a $.ajax call, which is the asynchronous part. Also in the JQuery we are sending the AJAX to the ajax_url that we localized into the script and we also pass the nonce for use in the PHP for security purposes:

$( 'body' ).on( 'click', '.button_input', function() {	
	var data = {
		index: index,
		author: author,
		message: message,
		style: style,
	};
	
	
	$.ajax({
		type: 'POST',   // Adding Post method
		url: cp_script.ajaxurl, // Including ajax file
		data: {
		"action": "the_function",
		"data"   : data,
		"nonce": cp_script.nonce
	},
	success: function( response ) { // Show returned data using the function.
		console.log( response.data.message );
	
	}
	
        });
	
	
});

And finally in the PHP file, add both actions listed below with the prefixes wp_ajax_ and wp_ajax_nopriv for users of different types, define the function using the same name used in the JQuery and get any data sent from the JQuery from post variables. One of those bits of data is the nonce, it is used to verify that your code sent the command and not some malicious actor. From here you can update the WordPress database and then optionally send results of the update back to the JQuery:

add_action( 'wp_ajax_the_function', 'the_function' );
add_action( 'wp_ajax_noprivs_the_function', 'the_function' );
function the_function() {
// check the nonce to make sure the request came from a user of your code
check_ajax_referer( 'the_function', 'nonce')
// do whatever you want to update the database with PHP
$message = wp_unslash( sanitize_text_field( $_POST['data']) );
update_option( 'latest_message', data );
// optionally send data back to the JQuery that you got from the PHP
wp_send_json_success{ [
   'message'  => 'succeeded'
] );
}