Integration with North Commerce

Hello!

North Commerce is new to me. As a partner of WooCommerce, I can only welcome competition.

If products are not listed in the sitemap automatically and do not have a meta title, description, or social sharing support, they are likely not created using the WordPress Posts and Post Type APIs.

If I’m correct, its underlying infrastructure must be reconsidered, as it will be an everlasting battle for compatibility. WordPress is already the CMS; it shouldn’t have another CMS running with it.

Perhaps I’m wrong, and the sites you manage use a particular flavor of headless WordPress, or something else I haven’t considered yet is amiss.

Could you explain how products are managed via the WordPress interface (WP JSON shouldn’t be relevant)?
Also, do you have a product URL for me to inspect? Thanks!

Hey! Thanks for the response.

Yes, we love WooCommerce too! So competition is great for everyone.

Correct, North Commerce using custom tables with a more modern approach to the architecture/performance.

Here a product link for one of our North Commerce stores: https://whitchurch.builders/products/mot-type-1-sub-base-scalpings/

North Commerce does have a very solid Bricks Builder integration – so I am current adding some general meta tags via the Bricks page builder SEO settings.

Here’s a demo/playground for North Commerce: https://app.instawp.io/launch?t=north-commerce-preview&d=v1

The owner of NC is keen to work with you guys on an integration too after I praised The SEO Framework ??

Look forward to chatting more!

Hi again!

The product link you shared does not have a proper canonical URL, meaning the product cannot be indexed. This is because of the problem I described earlier: WordPress doesn’t know this product exists.

The SEO Framework grabs the canonical URL from WordPress literally via get_the_permalink(); TSF only changes http to https if needed, and fixes pagination issues. So, if TSF cannot generate a proper canonical URL, neither can WordPress — WordPress isn’t communicating with the plugin.

Even though WordPress’s Post and Post Meta APIs are dated and could’ve been improved, it’s what WordPress runs on. Reinventing that wheel only causes compatibility issues, often undetected, and we’ll end up with a triangle.

My past decade with WordPress primarily involved working with query APIs and not the parts that users see. From this experience, I must reiterate that “[NC’s] underlying infrastructure must be reconsidered, as it will be an everlasting battle for compatibility. WordPress is already the CMS; it shouldn’t have another CMS running with it.” The team behind NC can choose to either spend two months now changing its custom product architecture into a WordPress Post Type-based one or spend another decade fixing compatibility issues that pop up everywhere. Note that many of these kinds of issues can go undetected for years; just like this one with Gutenberg caused by working around the standard API, rendering pages unindexable by search engines.

Other plugins like ‘LearnPress’, ‘WordPress Classifieds Plugin’, ‘bbPress’, ‘Ultimate Member’, ‘wpForo’, and ‘The Events Calendar’ also built a CMS on top of the WordPress CMS, constantly bringing me headaches. For bbPress I went out of my way to fully support it; for many others, I have either left it to their developers to patch the issues, disabled TSF on their pages, or addressed the most pressing issues only.

I thank you for your praise of TSF. Still, I hope NC’s team can learn from the aforementioned plugins’ mistakes and avoid compatibility issues altogether, where we’ll only have to detect the Product pages as we do for WooCommerce (all other filters are for improved UX only, and some cleanup of duplicated tasks), and as we do for Easy Digital Downloads.

Hi @cybr! Thanks for starting this conversation @embarkstudio.

We currently use custom tables for North Commerce and we have setup these rewrite rules to query products and collections by slug.

This is what we use when we create the url to get a single product by slug so we can display a specific product.

  public function registerPageWithParams($page_id, $params) {
        $permalink = get_permalink($page_id);
        $path      = trailingslashit(substr(parse_url($permalink, PHP_URL_PATH), 1));
        $source_regexp = "^$path";
        foreach($params as $p) {
            unset($p);
            $source_regexp .= "([^/]+)/";
        }
        $source_regexp .= '?$';

        $dest_uri = "index.php?page_id={$page_id}";
        foreach($params as $i => $param) {
            $dest_uri .= '&' . $param . '=$matches[' . ($i+1) . ']';
        }

        add_rewrite_rule($source_regexp, $dest_uri, 'top');

        add_filter('query_vars', function($vars) use($params) {
            foreach($params as $p) {
                if(!in_array($p, $vars)) {
                    $vars[] = $p;
                }
            }
            return $vars;
        });

        return [
            'source_regexp' => $source_regexp,
            'dest_uri' => $dest_uri
        ];
    }

What do you recommend we do to make life easier for SEO implementations and integrations with plugins like yours?

Hi @kelleymuro,

Sorry for the delay.

I had hoped I made my recommendations clear in my previous reply.

To restate, I vehemently recommend using the WordPress Post Type API for products rather than modifying query vars. See
https://developer.www.ads-software.com/plugins/post-types/registering-custom-post-types/.

When you use Post Types, WordPress will handle all the rewrites, indexing, titles, categorization, APIs, etc. WordPress will keep expanding on these APIs; by using Post Types, your products will automatically evolve to the latest standards. One day, that might also include some database indexing optimizations.