Category: Computers & Technology - Page 21

Add arbitrary product data to order items in WooCommerce

This seems to be way more convoluted than it needs to be, but I’m not sure how much of that is that it’s actually convoluted, how much is that Woo’s documentation sucks, and how much is that everyone else’s tutorial on it is tl;dr.

Anyway… I just wanted to do something fairly simple. I want to have each product’s short description get sent into the order data. This is a specific use case with a client who’s syncing data over the REST API with an external system, and we’re shoehorning data into the short description that maybe could go somewhere else. The point is, use your imagination as to how this might be useful to you.

I’m stripping out a lot of the other details. All I want is a way to a) add the data to the item in the cart, and b) carry that data over into the order item meta data in the database. You may need or want more, but this will get you started.

// Add custom order item meta data to cart
add_filter('woocommerce_add_cart_item_data', function($cart_item, $product_id) {
  if (!isset($cart_item['short_description'])) {
    if ($product = wc_get_product($product_id)) {
      $cart_item['short_description'] = $product->get_short_description();
    }
  }
  return $cart_item;
}, 10, 2);

// Add custom order item data from the cart into the order
add_action('woocommerce_checkout_create_order_line_item', function($item, $cart_item_key, $values, $order) {
  if  (isset($values['short_description'])) {
    $item->add_meta_data('Short Description', $values['short_description'], true);
  }
}, 10, 4);

This is a major distillation of stuff I found in these two tutorials: How to Add a Customizable Field to a WooCommerce Product and Add Custom Cart Item Data in WooCommerce.

Please, web font vendors, learn how to use CSS @font-face properly!

This has been bugging me for years and I can’t believe it’s still happening.

Being able to use custom fonts has been a huge boon to web design. And font hosting services like Typekit (sorry, I will never call it Adobe Fonts) and Google Fonts make using custom fonts easy.

But sometimes you still buy a font license that involves hosting the font files directly on your own server, and that’s where things get absolutely maddening because, for some reason, someone early on grossly misinterpreted how to use @font-face and that error has been perpetuated by countless unthinking others.

(Yes, I’m being harsh. But this is really not that complicated. And getting it right makes writing your CSS and HTML so much easier.)

Here’s an example of some font-specifying CSS you might receive from a font vendor:

@font-face {
    font-family: 'Font-Name-Regular';
    src: url('Font-Name/Font-Name-Regular.woff2') format('woff2'),
         url('Font-Name/Font-Name-Regular.woff') format('woff');
    font-weight: normal;
    }
.Font-Name-Regular {
    font-family: 'Font-Name-Regular';
    }

@font-face {
    font-family: 'Font-Name-Regular';
    src: url('Font-Name/Font-Name-Regular-Italic.woff2') format('woff2'),
         url('Font-Name/Font-Name-Regular-Italic.woff') format('woff');
    font-weight: normal;
    font-style: italic;
    }
.Font-Name-Regular-Italic {
    font-family: 'Font-Name-Regular';
    font-style: italic;
    }

@font-face {
    font-family: 'Font-Name-Bold';
    src: url('Font-Name/Font-Name-Bold.woff2') format('woff2'),
         url('Font-Name/Font-Name-Bold.woff') format('woff');
    font-weight: normal;
    }
.Font-Name-Bold {
    font-family: 'Font-Name-Bold';
    }

@font-face {
    font-family: 'Font-Name-Bold';
    src: url('Font-Name/Font-Name-Bold-Italic.woff2') format('woff2'),
         url('Font-Name/Font-Name-Bold-Italic.woff') format('woff');
    font-weight: normal;
    font-style: italic;
    }
.Font-Name-Bold-Italic {
    font-family: 'Font-Name-Bold';
    font-style: italic;
    }

This is, in fact, the exact code I just received yesterday from a font vendor when I purchased a license, with the actual font name removed to protect the guilty innocent.

What’s so bad about this, you might ask? Aside from the conventions I dislike of indenting the closing } and using 4 spaces instead of tabs, there are two glaring problems with this:

Because the font-family name defined for each weight and style is different, when you go to use this font, you need to specify the font-family every time you want to use bold or italics in your HTML, or at least use the custom CSS classes defined here. No! No no no! You should not have to apply a class to get bold or italics to render properly. The  and  tags should do that on their own!
Don’t f***ing define a bold font with font-weight: normal;! If you don’t realize from this, alone, that something is wrong with your approach, stop coding right now.

So, how should this be done, you ask?

Well, it’s simple. Each @font-face declaration has four properties. One is src: which tells the browser where to find the correct font file(s) for this face. The other three properties work together to define the context in which this particular src should be used: any time this combination of font-family, font-weight and font-style come together.

You can use the same font-family in different @font-face declarations as long as font-weight and font-style are different. In fact, you’re supposed to! That’s the way it’s designed to work!!!

When you do this properly, you don’t need any custom CSS classes. Try this on for size:

@font-face {
    font-family: 'Font-Name';
    src: url('Font-Name/Font-Name-Regular.woff2') format('woff2'),
         url('Font-Name/Font-Name-Regular.woff') format('woff');
    font-weight: normal;
}

@font-face {
    font-family: 'Font-Name';
    src: url('Font-Name/Font-Name-Regular-Italic.woff2') format('woff2'),
         url('Font-Name/Font-Name-Regular-Italic.woff') format('woff');
    font-weight: normal;
    font-style: italic;
}

@font-face {
    font-family: 'Font-Name';
    src: url('Font-Name/Font-Name-Bold.woff2') format('woff2'),
         url('Font-Name/Font-Name-Bold.woff') format('woff');
    font-weight: bold;
}

@font-face {
    font-family: 'Font-Name';
    src: url('Font-Name/Font-Name-Bold-Italic.woff2') format('woff2'),
         url('Font-Name/Font-Name-Bold-Italic.woff') format('woff');
    font-weight: bold;
    font-style: italic;
}

Aside from the fact that this eliminates 1/3 of the lines of code, it also will make your HTML much cleaner and more properly separates content from styling.

Here’s an example of some HTML you might have to write using the first approach:

This is some regular text, which also
includes a bit of italics
and even a dash of bold.

Now, granted, my version does require you to define the font-family for your  tags in your CSS file. But guess what… you’re supposed to do that! Put this in your CSS:

p { font-family: 'Font-Name'; }

With that in place, the proper HTML for the same appearance becomes this:

This is some regular text, which also
includes a bit of italics
and even a dash of bold.

So, again… when thinking about @font-face, just remember these two simple things:

All @font-face declarations for the same font family should have the same font-family. (Seems kind of obvious when I put it that way, doesn’t it?)
The value for font-weight should be the actual weight of the font. Only the “regular” weight should have font-weight: normal; or font-weight: 400;. If you’re using font-weight: normal; on a bold font, you’ve done something wrong.

This change makes for cleaner code, easier maintenance, and proper separation of content from design.

Addendum

Shortly after I posted this, I went back and looked at the unnamed font vendor’s sample page, because I knew it referenced “the @font-face standard since 2017”. I could not believe that this approach was actually a “standard,” so I tracked down the source, an article Bram Stein published on A List Apart in 2017 called Using Webfonts.

Guess what… Bram Stein’s examples do it the right way!

I do know one place where I’ve consistently seen this wrong way I’m railing against… it’s the code generated on FontSquirrel (no link, on principle) whenever you download a font. Other “web font generator” sites like FontSquirrel probably do it to. They’re all wrong… but Bram Stein isn’t. Don’t drag him down with this bad code!

I spent 5 hours troubleshooting this WordPress problem so you don’t have to (starring: WooCommerce Action Scheduler)

Sorry for that “clickbaity” headline. I added the parenthetical so it might be at least marginally useful. Since my WordPress-related posts are always about how I solved a particularly weird or obscure WP issue, I usually consider their titles carefully. “What would I have googled to find a solution to this problem?” But honestly, I spent 5 hours on this yesterday partly because I wasn’t sure what to google. (And I use lowercase “google” as a generic for “conduct an Internet search”; I normally use DuckDuckGo.)

OK, so here’s the situation. This particular site is — among my normally very-low-traffic clients — one of the busiest I work on. It’s a WooCommerce site with hundreds of products and 20+ daily orders. (Yeah, 20+ orders a day is not huge, but on the scale I normally deal with, it’s a lot.)

This site runs on its own virtual private server, with 8 GB RAM and 4 vCPUs. Pretty substantial for a single site. And yet, for weeks it has been maxing out RAM and CPU resources. Not to the point where the site was in crisis mode that demanded my immediate attention, but it was frustratingly slow. Just slightly below the threshold of me dropping work on other new projects to try to fix this. (At this point I feel obliged to note that I did not actually build or maintain this site for its first couple of years of existence, so I don’t know its inner workings as well as I normally would. I just know it’s running way too many plugins and desperately needs some TLC I have not had time to give it.)

Yesterday things finally got to the breaking point. For me, at least. The client had contacted me about an unrelated issue, but as I was dealing with that, I got frustrated by seeing all of this inexplicable resource usage, so I had to address it.

As it happens, this post is actually a bit of a sequel to my last post, about getting Apache’s mod_status and mod_rewrite to play nicely on a WordPress site. About three weeks ago I finally got mod_status working on this site, and had planned to come back, when I had a chance, to investigate this issue.

If you are not familiar with mod_status, you should check it out. Apache is generally a bit of a “black box” but this lets you see exactly what’s happening with each thread — the requested URL, the requesting IP address, connection time, resource usage, etc.

I noticed an absurd number of threads were coming from the localhost and were requesting wp-admin/admin-ajax.php with a query string referencing WooCommerce’s Action Scheduler. But what to do with that information?

I’ll admit, this is where I wasted a bunch of time in fruitless searches, because I don’t know a lot about Action Scheduler. I read a few threads on the WordPress support forums and StackOverflow that kind of danced around the problem I was having but never really got at it.

Eventually I ended up in phpMyAdmin, scrutinizing the wp_actionscheduler_actions table, and trying to figure out where all of the wc_facebook_regenerate_feed actions were coming from. I used my old favorite Search-Replace-DB to try to find any instances of “facebook” in the database. (This was an utter failure, for reasons I can’t explain. But that failure was critical to why this took me so long to resolve.)

I went to Tools > Scheduled Actions in WP admin and discovered there were over 200,000 actions, although there were only about 70,000 (only!) showing up in wp_actionscheduler_actions. Mystery!

I went to wp_actionscheduler_actions again, saw that those wc_facebook_regenerate_feed actions had all been scheduled weeks ago, and decided to just chuck out the lot. I truncated the table, but within seconds it started filling up again with hundreds of wc_facebook_regenerate_feed actions, with the same weeks-old scheduled dates. Where were they coming from???

What was especially maddening to me about all of this was that I had already, weeks ago, determined that the plugin that had created these — Facebook for WooCommerce — had been causing some kind of trouble, and I had deactivated it. Yesterday I even went so far as to delete it. I scoured the theme code for references to Facebook. I looked in the file system for stray files that might be responsible. And as I mentioned before, I tried to search the database for any references to Facebook. I was getting nowhere.

Eventually I realized Search-Replace-DB was having problems, so I dove into phpMyAdmin directly and started searching individual fields, in individual tables, for “Facebook”. And that’s where I finally figured it out.

WordPress puts everything in wp_posts, and that’s a problem.

I’ve complained over the years about the database architecture in WordPress. Having built multiple custom CMSes in the years prior to when I finally, fully embraced WordPress in 2014, I have a fair bit of experience designing databases. And two things I learned in that experience were: 1) clearly define what your data tables are for, and 2) indexes make databases efficient. WordPress is awesome for many things, but it has far, far outgrown its original conception as blogging software. Custom Post Types and Custom Fields make it super-flexible, but shoving everything they create into wp_posts and wp_postmeta can create a disastrous situation.

Case in point, WooCommerce scheduled actions. In earlier iterations, those were custom posts! (As are, still, WooCommerce orders, which is totally f***ed up, if you ask me.) At some point Woo or Automattic realized scheduled actions don’t belong in wp_posts, so they created four new tables specifically for managing them. Plugins that use scheduled actions had to create new scheduled actions for migrating the old wp_posts scheduled actions into the new tables.

And that’s where I found myself. Through some curious set of circumstances with this particular site, which probably at some point included someone other than me disabling WP-Cron to try to fix some other problem, 200,000+ scheduled actions from the Facebook for WooCommerce plugin (in the wp_posts table) got queued up for migration to the new tables. And as quickly as I was deleting them from the new tables, Action Scheduler (which runs once a minute!!!) was dutifully refilling them.

(And obviously they were never actually running… perhaps because I had deactivated the plugin? Or because they were simply timing out? Who knows? But here’s something I see as a flaw with Action Scheduler: it should check to see if the plugin that scheduled an action is currently active, and if not, purge the action immediately.)

At last here was the fix. I had to run this SQL query in phpMyAdmin. (Proceed with caution! Don’t just use this code… look in your database for exactly what is causing problems and adjust accordingly.)

DELETE FROM `wp_posts` WHERE `post_title` = 'wc_facebook_regenerate_feed';

Note: I’m doing this from memory — and a glance back at my browser history from yesterday. I didn’t keep notes on exactly what the title was.

For a more generalized — and drastic — approach, you could also do this:

DELETE FROM `wp_posts` WHERE `post_type` = 'scheduled-action';

I’ll just conclude here with a nice little graph of the site’s CPU and RAM usage over the past 24 hours. It was 6 PM when I finally figured this out!

How to get Apache’s mod_status and mod_rewrite to play nicely on a WordPress site

Apache’s mod_status can be very handy for monitoring exactly what’s going on inside of Apache on a busy website, but it can be a bit difficult to set up, if your site runs something like WordPress that also relies heavily on Apache’s mod_rewrite.

Specifically even though I had set up mod_status according to the official instructions, and specifically had also added the code to the virtual hosts, I still found that trying to access a site’s /server-status URL was just redirecting me to the WordPress 404 error page.

Here’s the fix. Maybe there’s a “better” way, but this worked for me. I just needed to hijack the rewrite rules in the site’s .htaccess file.

If you’ve already got IP or Auth based access restrictions configured in the virtual host, you probably don’t need the RewriteCond line, but I prefer to err on the side of caution. I used my VPN’s IP address (masked as 9’s here, which of course is not a valid IP address)… you’ll want to fill in whatever IP address(es) you want to allow in.

RewriteEngine on
RewriteCond %{REMOTE_ADDR} ^(999\.999\.999\.999)$
RewriteRule ^server-status$ – [L]

Put this before the WordPress rewrite rules, or it won’t do any good. And of course this is missing the <IfModule mod_rewrite.c> wrapper you probably should include, but if you’re doing this you already know mod_rewrite is enabled, so I don’t bother.

How to get (Mac) Safari to stop showing Favorites and Siri Suggestions panel when clicking the address bar

Not only do I never use it, I scarcely ever even noticed it before, but in recent versions of Safari on the Mac, whenever you click the address bar, a large panel pops out under it, displaying Favorites and Siri Suggestions.

Like I said, I scarcely noticed it before, but I did notice it the other day when I was doing a screen sharing session with a client. Luckily I don’t have anything embarrassing in my browsing history for it to reveal, but my recent activity did convince Siri that I would be extremely interested in links pertaining to the Minnesota Twins. Which I was not at that particular time.

But then it occurred to me… I never — I mean never — click on anything in that panel, but it does add to the visual “noise” of my daily browsing activities. So there’s got to be a way to get rid of it.

Yes, there is. I hunted around for it, so you don’t have to.

First, let’s turn off Siri Suggestions. This is an insidious pathogen that has metastasized throughout macOS, so if you’re like me and never use anything Siri-related, let’s kill it everywhere.

Open up System Preferences and click on Siri

Then in the Siri preferences, click the Siri Suggestions and Privacy button.

I went through the full list of apps and unchecked all the boxes, but at the very least you’ll want to uncheck Show Siri Suggestions in App under Safari:

Now if you go to Safari and click on the address bar, you’ll see Siri Suggestions is gone, but the panel with Favorites still shows up. You can get rid of it entirely by going to Safari > Preferences and clicking the Search tab. (Which… uh… is that really the way its icon is supposed to look???)

Uncheck Show Favorites under Smart Search Field… and maybe everything else. Then put on your tinfoil hat, sit back, and relax!