Corey Salzano

I was surprised to learn that when editing a page using Elementor‘s page builder, is_admin() returns false. The reason for this is that Elementor is loading the page in an <iframe> element as if it were being viewed on the front-end.

Use code like this to detect when posts or pages are being edited in Elementor. Code like this is useful to me because sometimes I add a meta refresh element to automatically start a download, and I don’t want the redirect and download to happen while editing the page.

//don't do anything if we're editing in Elementor
if( \Elementor\Plugin::$instance->editor->is_edit_mode() ) {
    return;
}

Here is other code that relies on a URL querystring parameter.

//don't do anything if we're editing post 1112 in Elementor
if( isset( $_GET['elementor-preview'] ) && '1112' == $_GET['elementor-preview'] ) {
    return;
}

Here is a comment I just requested be added to the bottom of the register_setting() page.

If you plan to use your setting in the REST API, use both the rest_api_init and admin_init hooks when calling register_setting() instead of just admin_init. The show_in_rest argument is ineffective when hooked into admin_init alone.

Corey Salzano

Someday, when my comment is approved, you’ll be able to see it on this page and save an hour or two of debugging time. If you can see my comment on this page, please let me know.

I wrote a plugin to customize the Events List widget that ships with Modern Tribe’s The Events Calendar Pro plugin. The widget has an option to hide completely when there are no upcoming events. The alternative displays the dreaded “There are no upcoming events at this time” in an otherwise empty Events List widget. I love the idea of not including the widget at all if there are no events, but what if this is the only widget in a sidebar or widget area? Sometimes, I want to display something in place of the widget instead of leaving the space empty. Here’s a plugin that does exactly that.

Download plugin

https://github.com/csalzano/the-events-calendar-list-widget-replacement

Where does the replacement content live?

Create a file at wp-content/themes/your-theme/tribe-events/pro/widgets/list-widget-replacement.php that contains the content you wish to display in place of the Events List widget when there are no upcoming events.

If you’re using the free version of The Events Calendar, create the file at wp-content/themes/your-theme/tribe-events/widgets/list-widget-replacement.php

(This file sits right next to list-widget.php, the template you might create to modify the output of the Events List widget. I chose these locations in the spirit of The Events Calendar Themer’s Guide.)

Here’s what my file looks like–I wrote some HTML that mimics a widget so I didn’t have to write any additional CSS styles for the replacement content. My client is a local municipality, so I put together some numbers that describe the size and age of a small Pennsylvania township.

Here are some JavaScript snippets to manipulate WP_Term objects in WordPress using the REST API and the Backbone JavaScript client library.

Insert a term

Delete a term

This next example assumes you’ve used wp_localize_script() to make the REST API endpoint and a nonce available in an object myplugin. If you need help doing this, please leave a comment below and I’ll expand this example.

Edit a term meta value

Let’s add a term meta value to identify the number of speeds in this automatic transmission.

Thanks for reading. If you know a better way to edit terms and term meta in JavaScript, please leave a comment below.

Here is a file you could save in wp-content/your-theme/tribe-events/month/content.php that will disable tooltips on the month view calendar produced by The Events Calendar plugin.

This is a template override for the month view that adds a few lines of JavaScript to remove some event handlers, and it removes a call loading the tooltip template. The JavaScript beginning on line 17 and the commented-out template call on line 56 are our points of interest.

I found a few solutions on the plugin’s official support forums, but I didn’t like any of them. This one loads all of the tips and the scripting that powers them while simply hiding the tooltips with CSS, and I think that’s a bloated solution. This one left my site throwing a JavaScript errors each time the mouse cursor hovered an event title, and that seems half-baked.

For a ContactForm7 form that has this source:

<div class="wpcf7-lead-widget">[text* contact-name maxlength:50 placeholder "Your Name (required)"]
[email* email maxlength:50 placeholder "Email (required)"]
[text phone maxlength:15 placeholder "Phone"]
[vehicle_form_field]
[textarea comments x3 placeholder "Questions and Comments"]
[submit class:_button class:_button-small "Check Availability"]
[hidden context id:context "contact"]
[hidden do-not-send-mail]</div>

The $posted_data that is passed via the wpcf7_posted_data hook looks like this:

Array
(
[_wpcf7] => 10610
[_wpcf7_version] => 5.1.1
[_wpcf7_locale] => en_US
[_wpcf7_unit_tag] => wpcf7-f10610-p7983-o1
[_wpcf7_container_post] => 7983
[g-recaptcha-response] =>
[contact-name] => Corey
[email] => [email protected]
[phone] => 8005556666
[inventory-post-id] => 7983
[comments] => Super interested in this sandbox
[context] => contact
[do-not-send-mail] =>
)

The first item is the form ID, and all items after g-recaptcha-response are the values of the fields provided by the the user (or the source in the case of the hidden fields). inventory-post-id is the value of a drop down created by the shortcode in our form, [vehicle_form_field].

Exporting a GravityView and importing it into a different site is easy, and there are official instructions right here.

This process works very smoothly when the Gravity Forms and GravityViews on both sites are identical. That’s usually not the world I live in, however. I’m a back-end developer in sites that sometimes have multiple teams working on them. I am usually only responsible for some of the Gravity Forms in the site, and that means the IDs of the forms I import into the site aren’t predictable.

Migrating a GravityView from one site to another is easy as long as the ID of the Gravity Form on which the GravityView is built does not change. If the ID of the underlying form changes, the view loses all the fields on the multi, single, and edit lists. This is frustrating because GravityViews take quite a while to configure, and those field lists are the bulk of the work.

Let’s Run Some Database Queries

If you have the ability to run MySQL queries against the database of your WordPress installation, you can run a couple queries after importing a GravityView to update the view with the ID of the Gravity Form on the new site.

Query #1

UPDATE wp_postmeta SET meta_value = 1 WHERE meta_value = 42 AND '_gravityview_form_id' = meta_key;

You need to change the numbers 1 and 42, which are the new Gravity Form ID and the old Gravity Form ID, respectively. The IDs of your Gravity Forms are listed when you click Forms in the dashboard. Also, take care to make sure your table prefix is the default wp_ like this example, or change wp_postmeta to match.

Query #2

UPDATE wp_postmeta SET meta_value = REPLACE( meta_value, 's:7:"form_id";s:2:"42";', 's:7:"form_id";s:1:"1";' ) WHERE '_gravityview_directory_fields' = meta_key;

Look for our form IDs "42" and "1" again. If your form IDs aren’t two and one digits like this example, you’ll also have to change the s:2: and s:1: that precede the values to match. These are pieces of a serialized PHP array, where s means string and the :2 means that the string "42" has a length of two characters. (Likewise for s:7 identifying "form_id" as a string with a length of seven characters.)