Anyone who’s dealt with e-commerce in any capacity probably knows that UPS won’t deliver to P.O. boxes. Well, technically they can’t deliver to P.O. boxes. And apparently they’ll forward packages on to the box owner’s physical address, but they charge a big extra fee to do it. So, you want to avoid it.
Unfortunately, WooCommerce and its UPS Shipping add-on do not account for this, and will accept UPS orders to P.O. box addresses. Not good.
Also, I’m not sure if the documentation is outdated or what, but their code sample didn’t work for me with the latest version (3.4.3) of WooCommerce, because of the wc_add_notice() function.
I’ve modified the original code to add a check for UPS shipping, and also to use the $errors variable. (I also considered removing the global $woocommerce; line since it seems unnecessary, but I didn’t take the time to test whether or not it’s definitely safe to remove, so I left it in.)
if (strstr($address1, 'pobox') || strstr($address2, 'pobox')) {
$errors->add('shipping', __('Sorry, UPS cannot deliver to P.O. boxes. Please enter a street address or choose another shipping method.' . $datadump, 'woocommerce'));
}
}
}, 10, 2);
Important notes:
1. This code may not immediately work for you; I believe the 'ups' string in the conditional line may vary depending on your Shipping Classes settings, so you may need to investigate exactly what values are returned in $data['shipping_method']. Since this code is fired off by an AJAX call, it can be difficult to debug. I was able to crudely debug it by commenting out the conditional, then appending print_r($data) to the error string.
2. This is using an anonymous function, so it won’t work in PHP versions below 5.3. But you’re not using a PHP version that old, are you? ;)
3. The original version checked the address line 1 and the postcode field, rather than address lines 1 and 2. I’ve United States-ified my code because that’s what I needed. If you’re part of the other 95% of the world, you may need to add that back in, with appropriate adjustments to the nested conditional. (I’m not really sure if this issue is as UPS-specific outside the US, so my modifications may not be relevant.)
Maybe it’s just hard to find because it’s such an edge case. Or is it?
Here’s the scenario: you’re converting an existing WordPress site that uses Custom Post Types (with archive pages) to Multisite.
Suddenly, when you’ve switched the site, your CPT archive pages return a 404 error.
Check this: insert /blog into the URL, like so…
Old URL
http://example.com/my-cpt-archive
New URL
http://example.com/blog/my-cpt-archive
Does it work? If so, good. If not, I can’t help you. *shrug*
Let’s just assume it does work, and continue…
You see, Multisite inserts /blog into the URL to prevent URL conflicts between the different sites. Problem is, it’s kind of stupid about it, especially if your site is not a “blog” (and despite what the core team thinks, I’m pretty sure most WordPress sites these days are not blogs). It doesn’t do anything to change page URLs, which are just as likely to conflict.
Anyway, there are two things you need to do. First, go to Settings > Permalinks. (Note that /blog has appeared in all of the permalink structures!) Switch to “Default”, save, then switch back to whatever you want it to be and save again. (Note that /blog has disappeared!)
This still isn’t going to fix your CPT archives though. For that you need to go into your functions.php file in your theme, or wherever you are registering the CPTs in your theme/plugin. In the register_post_type() function, you may have 'rewrite' defined, like this:
You’ll need to flush the rewrite rules by temporarily adding flush_rewrite_rules(); in the functions.php file, uploading it, loading a page, and then removing the code and re-uploading the file. Or, you can refresh the Settings > Permalinks page. (Much easier, but I haven’t tested to be 100% sure it works in this case.)
Suddenly, Advanced Custom Fields that use Select2 (any custom select dropdown, such as on Post Object fields) were broken. Testing plugins one-by-one narrowed it down to The Events Calendar. Apparently version 4.6.4 is loading Select2 and overriding ACF's own loading of Select2, breaking custom fields that use it.
Of course you knew I’d have to make a Steve Guttenberg joke to start this off. But maybe there’s something to it. (Side note: I just realized his last name has two “t”s, unlike Johannes, the inventor of movable type.)
I’ve been a professional web developer since before the term existed (1996, to be specific). I’ve been using WordPress for my blog since 2006, for occasional work projects since 2008, and as my primary web development platform since 2014. Working solo and being an introvert disinclined to participate in conferences, my contribution to the WordPress community has come mainly in the form of submitting a handful of plugins to the Plugin Directory. And, of course, writing a ton of blog posts here on various obscure problems I’ve encountered along the way.
I say all of this solely to establish whatever credibility I may or may not need in offering my half-baked assessment of what is, at the time of this writing, a half-baked WordPress plugin… but one that is destined — in short order, and for reasons that are up for much debate — to become the fundamental user experience of writing in WordPress.
So far documentation is (understandably) scarce, but I’ve poked around a bit to learn what I can and see how I might be able to customize it to meet my needs as a web developer building custom themes for clients.
I have a few things about Gutenberg that I’d like to explore with this post:
My initial reaction to the Gutenberg interface itself
Thoughts on how this will affect the work I do
Opinions and speculation on the motivation behind the project
Getting to know Gutenberg
Some of the reviews I linked to above are critical of Gutenberg, in ways I don’t think are entirely fair. Mainly because, yes, this is beta software. In fact, at this point I’d say even calling it beta is generous. This feels more like alpha testing, given how much of the development is still incomplete, and how much things are changing. I just downloaded version 0.9 yesterday and version 1.0 is already out, with a number of significant changes, including some that broke work I was doing on custom CSS styling for Gutenberg output just this morning.
The point is, there are plenty of things to criticize about how Gutenberg works at this point. But it’s important to consider whether or not those are things that are intended to be the way they are, or if they’re just incomplete features or unaddressed bugs. Here are a few of my favorite examples:
First, a screenshot from the special “Demo” page included with the plugin to help users familiarize themselves with how Gutenberg works.
Um… OK. Which “really wide” button would that be now?
One of the demo blocks is an image, and its caption suggests you try out a feature that — as far as I can tell — doesn’t yet exist. This should be your first sign that criticism of the tool may be, at this point, a bit premature.
Gutenberg is full of fun surprises, like things randomly breaking with no real explanation. Welcome to beta software!
Oh this poor, suffering block. Also “previewed” is an understatement. When this error appears, it also means you can’t edit the block in question. Hit Refresh and hope for the best!
But I think the real coup de grâce is the lack of polish on some fringe elements, such as how the text block you’re editing might randomly bounce around the page if there’s a floated image preceding it, as the editing tools surrounding the block you’re typing in appear and disappear. Or this… the beloved triple scrollbar!
Which one does what? Just scroll and see!
I’ve also discovered a fun bug that randomly inserts question marks when you switch italics on/off with keyboard shortcuts. But you don’t see them in Gutenberg, only in Preview mode. And then if you try to delete them in Gutenberg, it just starts randomly eating your text. That’s forced me to go into raw Text mode a few times in this very post to clean up Gutenberg’s mess. (Yes, my secret is out… I’m using Gutenberg to write this post!)
Many other reviewers have noted some of the drawbacks of Gutenberg’s features. It’s still not true WYSIWYG. It seems to want to be direct in-page editing, so why isn’t it that? Many elements are still dependent upon your theme for proper styling (like the margins below captions on this post — but I will probably have fixed that in my CSS before you are reading this). A lot of the blocks don’t really offer many styling options, which seems a bit self-defeating.
And, of course, it seems at this point that it will completely break the old “metabox” concept of the editing screen, and thousands of plugins and themes as a result. I really don’t know how the core team intends to resolve that issue, although sidebar metaboxes seem to be handled under the Document tab in the Settings sidebar. A lot of popular plugins (Yoast SEO, anyone?) that rely on more horizontal width will need to be drastically rethought to work in that context, though.
This leads into my next topic: how will Gutenberg affect the work I do as a web developer?
So… how will Gutenberg affect the work I do as a web developer?
My initial gut reaction to the news of Gutenberg was that it seemed to be eliminating the reason I exist in the WordPress ecosystem. As a developer specializing mostly in custom theme development for clients, it looked like Gutenberg was going to destroy my business. And as an occasional contributor of free plugins to the WordPress community, it looked like Gutenberg was going to create a lot of unnecessary (and unpaid) work for me, rebuilding my plugins to function in this new paradigm.
The latter may well be true, but the former won’t. Gutenberg does nothing at all to eliminate the need for theme developers — it just changes how we do a few things. And, importantly, the ability to create custom block types opens up new opportunities for developers of both themes and plugins to invent new ways of both displaying and working with content in a WordPress site.
The two big questions I’m left with, which are not yet answered, are:
Is this really an improvement over the existing TinyMCE editor, for developers and clients who are using WordPress not as a blog platform but as a general-purpose CMS?
Is it worth adapting to this new way of doing things? Or is this effectively Automattic showing me the door?
Pondering these questions takes me to my final topic…
Why this? Why now? Why at all?
I suppose there’s a “Who moved my cheese?” element to this. After all, I’ve spent the past two years honing my concept of modular design and the first eight months of 2017 perfecting a reusable core theme that relies heavily on Advanced Custom Fields (specifically, Flexible Content blocks) and the WordPress Customize API to achieve many of the same things Gutenberg does. My theme offers considerably more flexibility and formatting options than Gutenberg does, though I will readily acknowledge that Gutenberg seems easier to use than my heavily customized ACF Flexible Content blocks are.
The point is, I am already deeply immersed and heavily invested in a particular set of tools that are intended to achieve many of the same aims as Gutenberg, and that, in some ways, do a better job of that.
But wait, what really are the aims of Gutenberg? Who asked for this? Who is it benefitting?
While Matt Mullenweg talks big about how it will benefit practically everyone in the WordPress ecosystem — developers and agencies, plugin developers, theme developers, core developers, web hosts, and (last, but… not least?) users — it seems clear to me and to a lot of other critics of the project that the primary beneficiary is Automattic itself.
I find it curious that this project is named after the inventor of movable type, since one of the earliest WordPress competitors is called… Movable Type. This project is transparently an effort at fighting back against the likes of Wix, Weebly, Squarespace and Medium, each of which has in its own way been eating away at the potential market for WordPress.
But, you know, I cringe a bit at talking about “markets” when we’re discussing open source software. And that’s the crux of the problem. WordPress has, for many years, existed as a Jeckyll-and-Hyde duo of WordPress.org — the open source project underlying self-hosted WordPress sites and the huge developer and designer community of which I am a part — and WordPress.com — the commercial, hosted, software-as-a-service (SaaS) platform owned by Automattic.
That list of SaaS platforms I mentioned above — Wix, Weebly, Squarespace and Medium — represents competition to both sides of the WordPress dichotomy, but in significantly different ways.
To the open source WordPress.org community, they’re — mostly — competition in that they represent the “low end”. Small businesses and organizations that have limited budgets or a determined DIY ethic are inclined to use them, until they realize how quickly they are hamstrung by the limitations of the tools they offer. Then those businesses and organizations hire designers and developers like me to take their websites to the next level, and we use WordPress as a way to build exactly what they need, because its open architecture and self-hosting mean there’s no limit to our ability to customize WordPress to do exactly what we need. They are also a more ominous existential threat to our businesses, because they’re constantly improving, and eventually they won’t be so limited in ways that work to our advantage. So to that end, we need WordPress to evolve. But Gutenberg seems in some ways to be WordPress skating to where the puck is, rather than leapfrogging the competition, to mix metaphors.
But to WordPress.com, those SaaS platforms are much more direct competition, because they are offering exactly the same thing that WordPress.com offers: a hosted platform with limited customization capabilities. I have steered a number of clients away from Wix or Squarespace over the years, but I have steered just as many away from WordPress.com, and for the exact same reasons.
Medium is another story. In that it’s literally about stories. Automattic is definitely feeling the heat from Medium, but this is a world apart from the scenarios I described in the two preceding paragraphs. Medium is challenging WordPress.com specifically as a blogging platform.
It’s true that WordPress started as blogging software. But over the years it has become so much more than that. I have built over 100 websites on WordPress since switching to the platform full-time in 2014, but every single one of them has used WordPress as a CMS, not as a blog. Hardly any of those sites even have blogs. A key feature of one of the plugins I created, in fact, is to hide the Posts and Comments items in the WP admin interface, since hardly any of my clients use them.
Anecdotal evidence is not data. I wouldn’t suggest that my business use case for WordPress as a CMS necessarily means it should no longer be thought of primarily as blogging software. But I am hardly alone, and I’d be willing to bet that a large majority of my fellow developers who have made a substantial part of their career in client services, using WordPress as the underlying technology, would agree with me. Because… wait for it… blogs don’t make money. OK, a few do. But there aren’t enough profitable blogs to warrant an entire industry of paid designers and developers to build them.
This has been the most jarring aspect of the whole Gutenberg debate for me… the realization that Matt Mullenweg still thinks of WordPress primarily, if not exclusively, as blog software. And it seems that his singular passion is really what’s driving Gutenberg, above all else.
I do think Gutenberg, when it has a few more layers of refinements and polish, will be a superior content editing experience to what the current implementation of TinyMCE offers. But it is a huge change, and I don’t think it jibes with the way most WordPress.org sites use the platform. That’s not to say they can’t or won’t adapt. But it also says nothing about why they should.
The first sign that something was wrong was when I tried to create a new page on the client’s site. The blue Publish button I normally see was replaced with Submit for Review. What the…? That’s what WordPress users with the lowly Contributor role usually see. But I’m an Administrator — the most mighty role known to the world of (single-site) WordPress. (Yes, multi-site installations also confer the fearsome title of Super Admin upon a select few.)
Worse still, if I tried to click Submit for Review, it wouldn’t actually save!
Other problems abounded — I tried to create a new user with Administrator privileges, just to see if my own user account was corrupt. Couldn’t save that, either.
I had Debug Bar installed, and I noticed it was giving an error:
WARNING: wp-admin/includes/post.php:641 - Creating default object from empty value
get_default_post_to_edit
Well, that’s not good. Googling the error didn’t lead to anything immediately helpful, besides this comment that led me to explore the database structure in phpMyAdmin for any problems.
Yes, there were problems. Many of the tables, including wp_options, wp_posts, wp_postmeta and wp_users were missing their primary keys. A bit more digging into the WordPress core showed that, for complex reasons (i.e. I don’t totally get it), without primary keys on these tables, WordPress can’t determine the post type of a new post, and if it can’t determine the post type, it can’t determine the user’s capabilities with regard to that post type, which all comes back to…
WARNING: wp-admin/includes/post.php:641 - Creating default object from empty value
get_default_post_to_edit
Googling on the matter of WordPress tables missing their primary keys (or, perhaps more pertinently, their auto-increments), led me to a solution!!
Well, a partial solution. Because the database I was working with was not damaged in exactly the same way as the one the OP was working with, I couldn’t use the sample code directly. I had to go through the database and manually create a few primary keys, delete a bunch of auto-draft posts that all had an ID of 0, etc. Then I had to skip a few lines of the OP’s SQL code because they referred to tables that hadn’t lost their keys in my case, for whatever reason. But this is the… key… to solving the problem.
Now then, how did the database get this way? Well, the site lives on a fairly creaky old Fatcow (ugh, that name) shared hosting account, running an old version of MySQL and an almost unrecognizably ancient version of phpMyAdmin. We were undertaking major content changes on the site, so I copied it over to my own sleek, modern staging server running the latest and greatest of everything. The idea was that we’d get all of our changes in place just the way we wanted on the staging server, rather than mess up the live site for 2-3 weeks, and when we were done, we’d just copy everything back over.
Slick. Right? Sure, if both servers are running reasonably identical software versions. Which of course is never the case. Ever.
Apparently when I copied the site back to Fatcow, due to the older MySQL (or possibly phpMyAdmin) version, certain things like the primary keys and auto-increments — and, I’d be willing to bet, but I’m not sure it matters, the collation as well — got lost along the way.
