Category Archives: WordPress

Background overlay on mobile for Oxygen builder

In Oxygen, you can apply a background image as well as an image overlay within the options. However, these settings can not be changed per break point. Why would you want it to change based on break point? If the foreground text is hard to read due to not enough contrast when in the mobile view(or any really) then you would want to increase the rgba transparency value. Here is what I do in oxygen to do this since the overlay can’t be changed per breakpoint.

First, I give the hero section a base class of .hero , in that class I only specify settings that will apply to all other hero sections layouts that are the same minus the variable background image be used. Then, I add an additional class that is only used and is specific to that page to dictate the background image and to handle the image overlay in  media queries in css.

i.e.

So here we have 2 different types of hero layouts. #hero and #hero2 – neither of these contain the background or overlay settings. The classes like .v2-page is only used for that page and contains the background image specific for that page. The overlay for mobile is also handled.

Flip Animation Bug in Oxygen Builder pro menu

Flip Animation Bug ( Animate on scroll issue actually)

If using a “flip” type animation there may be an issue where elements will appear when they shouldn’t. Such as below

Flip Animation bug Screenshot

The fix is below

 

 

WordPress Oxygen Builder notes

Easy posts and the repeater modules automatically include pagination. If you want to prevent this you can add “no_found_rows=true” to the custom query.

i.e.

If you want to edit the css for the pagination links here are the selectors.

 

Custom Conditions Example

 

 

 

 

WordPress REST API and Custom Post Types

In my examples, I will be using a custom post type of “recipes”

In order to get a custom post type to show on the REST API (i.e. https://jmrowe.com/blog/wp-json/wp/v2/recipes ) , two options when using register_post_type can be set.

show_in_rest  (boolean) (optional) Whether to expose this post type in the REST API.

rest_base (string) (optional) The base slug that this post type will use when accessed using the REST API. Default: $post_type

show_in_rest must be set to true

rest_base will be the “base” of the url when calling it in the rest API.  So if nothing is set, the $post_type slug will be used.. i.e. recipes. If rest_base is changed to say “recipes-api” then to call it via the REST api it would look like: https://jmrowe.com/blog/wp-json/wp/v2/recipes-api

Sending the rest_url from WordPress to Javascript

wp_localize_script should be used to send the rest api url to javascript in a portable way such as:

 

Creating new fields in the REST responses

To add more/custom fields in the REST response. A function that does so must be added to the hook “rest_api_init” so..

register_rest_field() is used to register/add the custom field in the rest response

 

A good reference for using nonces in custom REST endpoints: https://viastudio.com/wordpress-rest-api-secure-ajax-calls-custom-endpoints/

One thing to note from this example is that WordPress suggest passing the nonce via the header and not the request content data. So, below is the better way of passing the nonce from js back to WordPress: