Chris Flannagan: WordPress Dev, Musician, Husband & Father
Whitelist your User Agent and it should fix 🙂
This one took me FOREVER to track down. But the problem ending up being in the WP core wp-includes/general-template.php function user_can_richedit().
the function looks at what browser is being used by the request user agent headers. Cloudfront was sending “Amazon Cloudfront” as the user agent which was blocking tabs from being echoed out for the classic editor.
There’s a super nifty extension out there to give SearchWP it’s own REST API endpoint and it’s super useful! It’s made by my good friends at Caldera Forms and it may just solve your needs. But it wasn’t helping me solve a problem I had. On a project I have a very customized hooked into and filtered situation going on with the WooCommerce products endpoint on the API. I didn’t want to refactor to work with that plugin so I needed to get results going into the primary products endpoint we are already using.
To use the default WordPress search functionality in an API endpoint you tack on ?search=keyword. This is cool and all but we are implementing SearchWP. SearchWP works by intercepting WP_Query when it’s got the ‘is_search’ set. It then does it’s own thing and returns the results.
The issue is, it doesn’t intercept when doing a search through the REST API. Why? I forgot, I dug through code for hours and figured it out but I can’t remember or sum up the reason so I’m just going to give my solution.
First thing you will want to do is hook into pre_get_posts and inject SWP_Query search results into the query’s ‘post__in’ parameter. You need to also tell the query it’s not a search and be sure you are even in the right place to be doing this. Here’s a quick gist
https://gist.github.com/ChrisFlannagan/7c0ae5510482a9cea9fb488c7f088fca
We can’t just let this go and it will work. The query may still try to order by something other than the result of IDs we got from SearchWP. So we need to hook into rest_{post_type}_query. Here’s the gist of that.
https://gist.github.com/ChrisFlannagan/42488c578c3a9167ee2a7290f937d358
When you upload an animated GIF to WordPress, or well any sort of image file, WordPress will upload the full size then resize to an array of different settings for thumbnails and medium sizes. The issue is when it is an animated GIF the resized items are just a still of the first frame. WordPress doesn’t have a GIF processor for rebuilding each frame at different sizes.
There is a plugin out there, it’s a bit outdated but might still do the trick. If you aren’t planning on having hundreds of gifs slowing down your site then this code snippet will force all gifs to load their full size image when using the “Add Media” button. You can then resize it with your mouse in place.
https://gist.github.com/ChrisFlannagan/10c87837150684fc0ab2fae0480deefb
Woo doesn’t filter out products with hidden catalog visibility outside of main shop loop. This is important to remember when using the REST API for front end display or general search results. This code snippet will keep them from showing outside of the admin.
https://gist.github.com/ChrisFlannagan/f79ab49491c2b85b0925c66a7fe971fd
I’m working on a site that’s in Japanese. It’s a huge WooCommerce shop and they have a lot of custom meta fields we built for the English version of things. Customers have their first and last name in my account and also fields we made for English First Name and English Last Name.
On the Addresses endpoint of WooCommerce’s “My Account” section we wanted to display the names/addresses in both Japanese and English. This seemed easy except the Japanese state name that’s generated by Woo was being translated in the ‘woocommerce’ text domain. The work-around was to unload the text domain, reload the countries/states instance with the data, get our state then reload the text domain. This snippet did the trick:
https://gist.github.com/ChrisFlannagan/423cb29c9ffe9a55baa2e955add81ba6
Recently I was tasked with adding a field to the cash on delivery gateway in WooCommerce. They wanted a field they could put in a dollar amount that would be tacked on as a fee to orders using that gateway. Seemed simple enough with some googling but took a bit longer to tweak and get functioning correctly.
Adding fields in WooCommerce to its forms is pretty straight forward. You hook into the WC Settings API and adjust them using this hook:
add_filter( 'woocommerce_settings_api_form_fields_<id>', function( $form_fields ) { return $form_fields; } );
Replace <id> with the id of the form. In this case it’s “cod” for the Cash on Delivery form. In your hooked function you can manipulate the form fields array as needed. For my case I just needed to add a field at the end for a fee so I do this:
https://gist.github.com/ChrisFlannagan/bcfe4ea1cbfdcd629db7f292c22cc40c
Now that we have a fee set we need to hook into the checkout process. For this I use the action “woocommerce_checkout_create_order” to manipulate the order right before it’s saved. In WooCommerce 3.0 and over you no longer use the add_fee() function but instead create a line item fee object and add that to the order. Here’s how I did what I needed:
https://gist.github.com/ChrisFlannagan/ae68a43ec4b60ac741c95715e58dd001
Notice the add_item( $item ) call to place it in the order. If that’s all you do then you will see the fee on the order but the order total won’t include it. You need to make sure you run the order’s calculate_totals() function after adding the item.
I’m building a site for a Japanese company. They need a Gravity Forms address field with a different order. I spent a BOATLOAD of time trying to get this working and I finally did. Here’s some details.
I started by extending the address field. Simple enough. Made some tweaks to the get_field_input() function to reorganize. Made sure all other functions that used the .1, .2, etc. id’s for the inputs inside the field were updated in my field class.
After some trial and error with those I got the form field to be in the admin so I could add it to a form. Awesome! Went to the front and there’s my new beautiful field. But no matter how hard I tried it would not save any of the data.
I searched and searched through all the hooks I could find related to this. I almost gave up but then I found a comment that said something about default inputs were loaded in js.php file.
In the root directory of Gravity Forms is a file named js.php. This file runs a switch case on different field types and populates some data. If you look towards the bottom around line 838 at the writing of this post you will see:
<?php do_action( 'gform_editor_js_set_default_values' ); ?>
Right there you need to hook in your own default settings with field.inputs defined. That’s about it! I just copied the info they had for the address field, tweaked it to match my class’s data and voila.
I’ve just released the latest version of my plugin to the WordPress repo. You can now simply click a button to have a plain text version of the information copied to your clip board. Paste into an email or support forum with ease and no crazy html or code getting included.