divydovy

Closing ticket.

Super weird but thanks so much for investigating. Sounds like it must be an issue my end. Feel free to close the ticket and I’ll try to troubleshoot and report back. Won’t be for a month or so tho.

Thanks again Ross.

OK that is weird. Can you show me what you have in the CMS side of things?

Thanks Ross. Pls shout if I can help at all ??

Thanks for getting back to me Ross.

It’s behind a VPN I’m afraid.

But the page contents are just:

[searchandfilter id=”2449″] [custom-layout id=’2451′]

When I use the default template, everything is good.

With a custom template, all other fields are fine except the excerpt which just displays the shortcodes above.

I can only think maybe there’s an issue with the ‘excerpt’ code which is looking at the wrong post it – maybe there’s a wp_reset_query() or something somewhere?

I can jump on a screenshare if you want? I’m UK.

Awesome – thanks for the review and the post. Let me know if you spot anything that can be improved or if you hit anything that doesn’t work as expected.

Thanks Nick. Nailed it and good to see where the github repo is.

add_filter(‘ngettext’, remove_theme_from_dash’);

You’re missing a ‘

Not sure if that’s the underlying issue but a typo won’t help. Try:

add_filter(‘ngettext’, ‘remove_theme_from_dash’);

Obvious mistake was to leave the last url unchanged, but you knew that right?

Hi @mrnick,

Looks like the fonts aren’t loading. The browser’s trying to load them from: https://cardtherapy.co.uk/..fonts/dancingscript-regular-webfont.woff

The way your theme’s custom CSS works is by outputting it at the root via https://cardtherapy.co.uk/?action=display_custom_css_code

So, change your CSS to:

@font-face{
	font-family: 'dancingscript-regular';
	src: url('/wp-content/themes/expound/fonts/dancingscript-regular-webfont.eot');
	src: url('/wp-content/themes/expound/fonts/dancingscript-regular-webfont.eot?#iefix') format('embedded-opentype'),
	     url('/wp-content/themes/expound/fonts/dancingscript-regular-webfont.woff') format('woff'),
	     url('/wp-content/themes/expound/fonts/dancingscript-regular-webfont.ttf') format('truetype'),
	     url('..fonts/dancingscript-regular-webfont.svg#webfont') format('svg');
}

h1,
h2,
h3 { font-family: 'dancingscript-regular'; }

And that should do the trick.

@shashank – confirmed this plugin is causing issues for us too – seems to be overriding a core function that’s now changed.

We’ve opened a WooThemes ticket.

I have the same issue.

Theme: WooThemes Function
Plugins:

Antispam Bee
Features
Google Analytics for WordPress
Gravity Forms
Groups
InfiniteWP – Client
Jetpack by WordPress.com
jQuery Vertical Mega Menu
The Events Calendar
The Events Calendar PRO
WooCommerce
WooCommerce – Gravity Forms Product Add-Ons
WooCommerce SagePay Form Gateway
WooSlider
WooThemes Updater
WordPress Importer
WordPress SEO

Haven’t diagnosed cause yet but thought this list might help centralise discussion. Will update once a fix/cause is located.

Sure. I get that. I think we’re talking cross-purposes a little here but I really appreciate your time.

All I’m saying is that I’d have found it really helpful to be able to define in_same_tax as a custom taxonomy that’s non-hierarchical. I get that including tags or multiple taxonomies at once would confuse people.

But I don’t have to develop or support the plugin so I totally respect your reasoning, time and coding skillz. Thanks again.

Thanks for your time.

Tried to hit you on Skype but here goes for public bravery. If I understand your question, you’re asking how the query knows which term to use to match the prev/next post to.

It looks like the $in_same_term_sql is an array of all the cat or tax term ids, optionally with any post_format id’s too.

Is the answer then that running an IN on a whole bunch of tag term IDs at once is (a) going to hammer MySQL and (b) produce few results because the more tags there are, the fewer matches there will be?

Sorry if I’m missing the point…

Thanks @ambrosite for taking the time to explain/respond.

Yes, line 91 doh.

Feedback if it’s helpful is that it’d be easier to understand if:

– the plugin clearly states that in_same_cat works only for categories and not tags by default
– but if you want to use tags then treat it as a custom taxonomy

If people are asking to use a custom taxonomy then it’s likely they’re either aware of it being flat and how it’s used in the site OR (as with my case) I’m using a custom tax/post type generated by a plugin where I don’t have the luxury of using a hierarchical tax.

If you’re open to collaboration I could do my best to fork and pull request on Github.

Hope this is helpful and appreciate the plugin/support. Cheers!