Install additional language: Change user language:

Background:

A site that was developed some years ago with WordPress 4.x and ACF 4.x got moved to a new server. During the migration process, WordPress and the Plug-ins were updated to their latest version – I assume, before the MySQL DB got migrated, which let to the following complaint:

“ACF are not showing in ACF 5.x”

After some detective work, I realise that the data was still present. ACF v4.x was storing the ACF data in wp_options, ACF v5.x is storing it in wp_termmeta.

Which is great, because all that is needed, is to update the DB! But how to do it?

First attempt: Re-install ACF 4.4.12, then update to ACF 5.x

Didn’t work as expected.

Second attempt: change the acf_version in wp_options

In the wp_options, the acf_version is set to the current WP version, 5.7.6 in this case. Setting it to 4.4.12, triggered the ACF DB update script, the ACF data got migrated to wp_termmeta, the site is working again as expected.

Shout out to the ACF Support Pages for solving the last piece of the puzzle.

$l = get_nav_menu_locations(); $m = wp_get_nav_menu_items($l['footer-menu']); foreach($m as $i) { // $i->url; // $i->title; }

// update_option('siteurl','http://127.0.0.1/my-site'); // update_option('home','http://127.0.0.1/my-site'); // add excerpts to pages add_post_type_support('page', 'excerpt'); // remove auto-p in blog content remove_filter('the_content', 'wpautop'); // replace \n with <br /> // substitute
for line breaks in the content function addLineBreaks($content) { return str_replace("\n", "\n<br />", $content); } add_filter('the_content', 'addLineBreaks'); // register menu function register_theme_menu() { register_nav_menu('footer-menu', 'Footer Menu'); } add_action('init', 'register_theme_menu'); Show WordPress Theme Menu

functions.php function register_theme_menu() { register_nav_menu('my-menu', 'My Menu'); } add_action( 'init', 'register_theme_menu' ); Menu Location $l = get_nav_menu_locations(); $m = wp_get_nav_menu_items($l['my-menu']); foreach($m as $i) { // custom HTML echo $i->url; echo $i->title; }

if ($wp_query->is_posts_page) { $id = $wp_query->queried_object->ID; }

...$nr // number of posts $args = array( 'posts_per_page' => $nr ? $nr : get_option('posts_per_page'), 'paged' => get_query_var('paged', 1), 'post_type' => 'post', ... ); $wp_query = new WP_Query($args); while ($wp_query->have_posts()) : $wp_query->the_post(); // display endwhile; // getPagination()

function onSavePosts($post_id) { if (wp_is_post_revision($post_id)) return; // Remove Post Categories, set post categories to empty array wp_set_post_terms($post_id, array(), 'category'); } add_action('save_post', 'onSavePosts');

I recently came across the following situation. A new server, a client-defined database, a database name like this: ‘my-database’. Checking if the DB exists in PhpMyAdmin, everything checks out. Putting all the details in wp-config.php should also work, right?

define('DB_NAME', 'my-database');

Hmmm. No, not quite. Error establishing a database connection Could it really be, that the dash in ‘my-database’ messes up the DB_NAME? Apparently yes.

define('DB_NAME', "my-database");

Ok, problem solved. As for why, that’s still an open question.

The WordPress way of loading Javascript files is through wp_enqueue_script. This ensures that no scripts are loaded twice, and it allows for a mechanism to specify dependencies. I had the following situation: A plug-in was loading a JS file with wp_enqueue_script, something like this:

function addMyPluginScript() {
	wp_register_script('my-js', plugins_url('/my.js', __FILE__, array('jquery'), '1.0', false) );
	wp_enqueue_script('my-js');            
}    
 
add_action('wp_enqueue_scripts', 'addMyPluginScript');

In my theme’s functions.php I had the following:

function load_scripts() {							
	wp_enqueue_script('jquery');
	// ... other scripts
}    
add_action('wp_enqueue_scripts', 'load_scripts');

But although I specified the dependency of ‘jquery’ in the plug-in’s code, the plug-in’s JS got loaded BEFORE the theme’s jQuery. Hmmm… The solution was a closer look at the add_action function. Usually it is called with 2 parameters, the hook name and the callback function. But there’s also a third, optional parameter: priority. It defaults to 10, and Lower numbers correspond with earlier execution, and functions with the same priority are executed in the order in which they were added to the action. The fix for out problem: Load the functions scripts before anything else:

function load_scripts() {							
	wp_enqueue_script('jquery');
	// ... other scripts
}    
add_action('wp_enqueue_scripts', 'load_scripts', 1);	// 1 is smaller than the default 10...