You’re right, Simion … it only affects people using infinite load for posts. I do appreciate you all taking another look at this, however. If you’d like, I have two VERY strong WP developers that I work with that have been taking an in-depth look at this. I would be glad to connect you with them when you’re ready to look at this. Perhaps they can provide some info that would be helpful. Just ping me direct via my forum registered email address. Cheers!

I understand that you don’t have current plans to rework this, but that means that every publisher using TagDiv Newspaper or Newsmagazine is getting heavily inflated and false data from Google Analytics. This seems like a very important issue to fix for all TagDiv customers. How can we help push this up the queue to tackle? I’m more than willing to help fund this effort if needed.

It not only impacts Google Analytics, but also OneSignal integration (the bell icon), privacy / compliance systems like Iubenda, Meta / LinkedIn remarketing tags, and many other tags that media companies rely upon for analytics, remarketing, and compliance.

• This reply was modified 1 week by nearview.
• This reply was modified 1 week by nearview.

More information from one of the devs I work with:

——

The issue was that the main Google Analytics tracking code was being initialized more than once during TagDiv’s Infinite Scroll process.

Originally, GA4 was loaded directly from PHP. That worked correctly on the initial page load, but when TagDiv loaded additional articles through AJAX, that same GA4 initialization code could run again. Each time GA4 was initialized, it automatically created another page view even.

For the test on staging server, the main GA4 initialization was moved into a separate JS file and added checks: (\Newspaper-child\js\ga4-init.js)
GA4 initializes normally once on the initial page load.

If the page being loaded is a TagDiv AJAX/infinite-scroll request, GA4 is not initialized again.

When the reader actually scrolls into the next article and TagDiv changes the URL, the normal Infinite Scroll page view still fires.

The result is that we now get one page view for the initial article and one page view for each additional article, without the extra page view that was previously being generated when the url changed.

It will be interesting to see what TagDiv says about this.

Thanks, Simion. You and the entire team there rock!

Thanks Calin!

The code you provided previously still works correctly, and addresses the core issue. All we are looking for is for the widget to only show the immediate children, not children, grand-children, grand-grand-children, etc.

Calin,
So even with 12.7.5 this still is not fixed or included in the theme. The existing Subcategories widget remains untouched, and the new Category Siblings is missing the critical feature of levels of siblings to show. Right now it shows all levels of siblings which is the same issue we have had from the beginning.

Thanks, Calin … that confirms what I thought was happening. We’ll try the News Ticker again and see how that works. Appreciate the explanation.

BTW, is the “News Ticker” element subject to the “unique articles” setting on a page? Or does “unique articles” only affect article blocks?

Hey Calin,
The latest file you provided didn’t actually fix that issue. If you look at lines Line 1286-1294 you do have
if ( empty( $categories_objects ) && $show_siblings ) {
$categories_objects = get_categories(
array(
'parent' => $this->category_obj->parent,
'hide_empty' => 0,
'number' => $limit
)
);
}

However if $this->category_obj->parent is 0, get_categories() returns all top-level categories.

That should be changed to be

// if no child categories get siblings
if ( empty( $categories_objects ) && $show_siblings ) {

}

The same issue/behavior exists for taxonomies on Line 1114-1129.

Just hoping this gets incorporated in next version.

Can you upload your screenshots directly to your forum software? Your screenshot links above are broken.

Thanks Calin! That worked. Do you know if this has been implemented in the latest update that just came out yesterday? 12.7.4

Hey Calin,
This has been about 6 months now, and even with the release of version 12.7.3 the subcategories widget is still not working as it once did.

I just wanted to see if this issue is any closer to being fixed or reverted back to the functionality it used to have?

Calin, that’s not it. I can guarantee you that all of these WooCommerce add-on developers are not going to write special code just to support TagDiv themes.

The biggest issue is TagDiv’s lack of proper integration for standard WooCommerce hooks. THAT is what the various add-on developers are going to code for.

Hopefully TagDiv will implement changes similar to the one that we documented earlier in this thread.

When we manually added that code to one of our sites, magically the TagDiv WooCommerce blocks started working properly with add-ons like group subscriptions and more.

Thx, Calin!

Hi Anamaria. I’d also like to request that the Nextdoor social icon be added to the Newspaper theme. Nextdoor recently launched Nextdoor news and MANY publishers are now creating Nextdoor news accounts.

Here’s an article I wrote about it: https://nearviewmedia.com/nextdoor-news/

And here’s an example of a publisher Nextdoor news account: https://nextdoor.com/page/bethesda-magazine/

Thanks!

• This reply was modified 1 year by nearview.

Hello Bettina,
Has there been any movement on this at all?

Calin,
Bummer, is this something that you could bring up to your developers to possibly get on the roadmap for future release?

Thanks Calin! We will continue to use the CSS method we have in place currently.

Hey Calin,

I was able to dig into this further and found the issue. The TD Woo plugin does execute the standard WooCommerce hooks, but it omits the global $product variable from the templates. Because of that, any plugin relying on global $product won’t function correctly.

Until a proper fix is in place, here’s a workaround that should help anyone else who runs into this:

global $product;
if ( is_null( $product ) ) {
if ( class_exists( ‘tdb_state_content’ ) && method_exists( ‘tdb_state_content’, ‘get_wp_query’ ) ) {
$current_product_id = tdb_state_content::get_wp_query()->queried_object_id;

if ( function_exists( ‘wc_get_product’ ) ) {
$product = wc_get_product( $current_product_id );
}
}
}

Hope that helps!

I appreciate it, Calin. Please feel free to email me directly. I do realize and appreciate that you have a queue … we do as well. 🙂 As I mentioned, we’d be glad to pay whatever it takes to get special development focus on this.

Hi Bettina. So, here’s our site we’ve been working on (BTW, we will be using this for MANY more regional magazine publishers here in the U.S.):

https://hartfordbusiness.emds.dev/product/paywall-bypass-link/?url=https://hartfordbusiness.emds.dev/article/test-subscriber-only-article/

As you can see, there is NO field for the URL bypass … this is a injected using standard WooCommerce hooks.

Alternatively, here is a link to exactly the same thing, but on a different site that uses Elementor instead of TagDiv:

https://obj.ca/product/article-bypass-link/?url=https://obj.ca/developers-hope-proposal-makes-ottawa-more-attractive-for-builders/

You can see here that the field, “URL to Bypass” has been injected into the product page. On this site, we’re using Elementor’s WooCommerce widgets, but they properly allow for WooCommerce hooks.

We REALLY need to get this working as we have large-scale publisher sites running TagDiv and WooCommerce and they need this kind of functionality … not only for this paywall bypass feature, but for other elements like gift subscriptions and group subscriptions.

We are willing to pay for special development for this. Would that help?

Thanks, Calin. Didn’t realize that field also worked for custom taxonomy ID. Appreciate the help.

Bettina,
This has been going on now for almost 4 months now. Is there no response from your team on this?

Hey Bettina,
It’s been another week, is there any update on this?