tictok

Okay, I understand now! Thanks for your advice, it make sense.

I think the route I’m going to take will be to develop the store separately and bring a little of the content (eg product info pages) over into the store for phase 1.

Phase 2 will be to massively simplify the structure of the existing magazine site and bring that into the store as in time I will probably need to allow users to login (eg either for account address details or content behind a paywall) or integrate things further. I guess that will be easier to achieve if everything is one place.

Related query: Is there anyway to display Woo-commerce cart info (at least number of items and total price) on a non commerce WordPress site?

I can see how it could be done with sessions and cookies, but does anyone know of a quick / easy way to achieve this.. maybe a plugin? Probably need to post a new question for that though!

Thanks
Stef

Hi – thanks for your reply.

Sorry, trying to understand (as I don’t think my original question was definitive enough), but I think you’re saying you think it’d be best to bring all content into the same WP install as the store?

Is there any significant speed penalty as database gets bigger? (I guess that depends upon server setup as much as anything)…

Thanks again

Thank you, you’ve been a great help.

It all makes sense but I think I’ve still got plenty to read up on and experiment with filters and tweaking the query this way before I can easily put it into practice.

Today’s one of those days where my WordPress knowledge and understandinh made a little leap forwards. ??

Awesome – can’t thank you enough. That does the job perfectly and I feel like I’m learning a lot too!

The $pieces variable is an array of the database query that’s been made by the WP_Query class (split in pieces).

So you defined $pieces in your function? It could’ve been called anything? i.e. $pieces isn’t reserved for WordPress?

$pieces['fields'] .= " ,month($wpdb->posts.post_date), if(month($wpdb->posts.post_date)>month(now()), month($wpdb->posts.post_date), month($wpdb->posts.post_date)+12) month_order";
			$pieces['orderby'] = " month_order DESC, $wpdb->posts.post_date DESC";
		}

Reading the above snippet I can understnad what it’s doing – not sure I’d be able to get anywhere close from scratch though. Not yet anyway!

You’ve made my weekend!

• This reply was modified 7 years, 6 months ago by tictok.

Oh, one more thing. I’m very close, but not quite across the finish line yet.

I need to alter this to show the current months posts (regardless of year) at the top, and then preceding months posts (regardless of year) follows on after that.

Would the best approach here be:
– modify category.php in my child theme? (I can kind of see a way of doing this)
– or should I stick with altering the query at source via pre_get_posts? (not so sure how I would this)

Thanks again, again!

W0W! Many thanks @keesiemeijer !

That gets me soo close. It does indeed change the query to display all posts, grouped by month, regardless of year – which is great!

It’s so much more elegant and efficient than I’m sure the bloated mess (along with hundereds of DB queries) I would’ve otherwise ended up with would have been.

Interestingly it keeps posts within any month in chronological order (i.e. all posts from May 2017, then May 2016, May 2015, April 2017, April 2016, April 2015 etc) then which is fine in this instance.

As I’m learning as I go, can I check that I understand what it’s doing correctly please?
$pieces['orderby'] = " Month($wpdb->posts.post_date) DESC, $wpdb->posts.post_date DESC";

So, that line is making a new array ($pieces), of posts ordered by month in DESCending order, but you’ve done this via a custom query to the database to look at just the Month within the post_date. You’ve then ordered those results (within each month) by descending date order too?

I’ve not looked into the $wpdb database class much before. Seems there’s a lot of potential for custom or otherwise difficult queries using that.

Thanks again – I’d give you a hug if you were close enough!

Many thanks keesiemeijer –

If I understand correctly, from reading your snippet, that shows all posts from current month, regardless of year (as you state), but just for the current month.

Unfortunately it doesn’t then go on to show all posts from the previous month (regardless of year), or the month before that etc. which is what I really need. I need to see all posts, but grouped by month – current month first (regardless of year).

I was playing around using pre_get_posts along with $query->set(‘monthnum’, $month); instead of a date_query, which I think returns exactly the same results as your suggestion.

Good tip on the child theme btw – thanks. I’m modifying a theme I created from scratch (using _S) a couple of years ago, so no need at the moment, but invaluable advice non-the-less!

Hi Codismo –

I’ve been thinking about different approaches a lot over the past 12 hours. I think that something like your suggestion is probably the easiest to implement, but I was hoping not to have to modify existing posts by adding new post meta.

The only other option I came up with, is that as I already have all the post data within an array $posts (as the query for category.php is generated before the page is rendered), I believe post dates are stored in the array in something similar to a DD/MM/YY hh-mm-ss format. I could potentially search within that $posts array for a partial match to a string (including month number) by using PHP to search the array with preg_match. I could hopefully then return post IDs, or add those items / posts to a new array for each month and display those? Could work? Sounds like a more fragile method to me, doesn’t feel like the ‘wordpress way’…

Hi

I noticed the same thing in my own custom theme after updating to WP 4.4.
All the wrappers / containers around the tag cloud appear to have disappeared breaking the styling.

However I have a function in functions.php that reduced the number of tags shown in certain categories. Removing this appears to fix the issue (and my tags are once again wrapped in appropriate divs and therefore styled correctly with CSS), although I’ve now lost the control over how many tags are displayed in certain places.
I’ve not looked into why this happens yet as this fix will do me for now. When I have time I’ll look a little deeper.

Below is the code I’ve commented out in my functions.php. I originally added this myself, so unlikely to be in your functions.php, but the point is that I’ve tried to modify the tag cloud, and although it worked previously, fiddling with the tag cloud output in that way appears to break things or have changed considerably in WP 4.4.

/**
* Change output of Standard WP Tag widget - this seems to break things after update to WP 4.4
**/

add_filter('widget_tag_cloud_args','style_tags');
function style_tags($args) {

	//Show fewer tags on Some-Category archive page
	if (  is_category('some-category') ) :
		$number = '24';
	else :
		$number = '30';
	endif;

	$args = array(
		 'largest'    => '10',
		 'smallest'   => '10',
		 'format'     => '',
		 'number'       => $number,
		);
	return $args;
}

Cheers
Stef

Only just seen your reply raamdev. Thanks very much.
I had to put the Varnish thing on hold until I get around to updating my VPS to a 64bit OS.

Thanks again

Okay – so the issue is still there. I contemplated removing CPT-onomines, but it’s such a great tool that I really want to keep it. At the moment I’m just using it to link Reviews (existing CPT) and FAQs (existing CPT) to Products (existing CPT), with products being the CPT-onomy.

I figured a rough and ready work-around that seems to be doing the trick and allowing me to see any new child-categories on a standard category.php page.

All I did was to force the query on category.php pages to look at sub-categories too. Now it no longer misses any child-categories added since installing CPT-onomies. Currently I’ve tweaked the Query directly in the template file, but suspect I should’ve done it via pre_get_posts instead.

My code probably isn’t that elegant and I’m sure there’s probably a leaner way to do it, but I’ve added the following snippet of code before the loop on a category.php

<?php if ( have_posts() ) : ?>

<?php
// Tweaking the query in category.php to make sure it looks at child categories.
// Should probably be using pre_get_posts instead

if (is_category()) :
	$category = get_category(get_query_var('cat'));
	$child_cats = array();
	$child_cats = get_term_children( $cat, 'category');
	$args = array(
	'category__in' => $child_cats
	);
	query_posts( $args );
endif;
?>

<?php if (have_posts()) : while (have_posts()) : the_post();

Cheers
Stef

Hello Rachel – Fantastic plug-in, but bad news I’m afraid as I think I’m having a related issue.

Its on a site that’s due to go live on Sunday, so is in the last stages of dev.

By default wordpress category pages (category.php) also show posts from child categories, which is exactly what I want.

I created a CTP-taxonomy with your plug-in and for a few days thought everything was fine. Now noticed that posts from any NEW categories (created after installing CPT-onomies) do not show up on a parent category.php page. However posts from child-categories created before creating the CPT-onomy still display as expected. The archive sole for a child cat still works fine.

Removed most stuff from functions.php and disabled plugins until I stumbled on CPT-onomies as the culprit. If I deactivate the child-category, posts come back on the parent category page.

Removing just the CPT-onomy doesn’t fix it, the posts only come back if I disable the plugin completely.

For what it’s worth, the parent cats and sub cats that are affected are the standard wordpress Post type. There’s no CTP-onomy or custom Taxonomy attached to them at all.

Happy to help troubleshoot where I can.
Thanks
Stef

edit: PS ran the snippet you suggested above but there’s only the standard taxonomies listed

Array
(
    [0] => category
    [1] => nav_menu
    [2] => post_format
    [3] => post_tag
)

Not mine, but found this elsewhere, although think it may need tidying a little to check nav menu exists and that there are items in the array first. Going to test now.

add_filter('body_class','menu_class_to_body');
function menu_class_to_body($classes)
{
        $items = wp_get_nav_menu_items( 1 ); //change to suit your menu id

          foreach ($items as $item):
                $menuClasses = $item->classes;
                $objectId = $item->object_id.' ';

                if ( is_page($item->object_id) ):
                    $current[] = $menuClasses;
                endif;

          endforeach;

        $classes[] =  $current[0][0];

        return $classes;
}

Seems to be working for me so far…

HIya – just to chime into my own post a little;

I watched Andrew Nacin’s Wordcamp talk on wp-query.
https://wordpress.tv/2013/03/15/andrew-nacin-wp_query-wordpress-in-depth/

Learnt so much! Definitely going to try using pre_get_posts on a conditional basis in functions.php

So, I understand a lot more now, but I don’t understand why both get_posts and wp_query exist? Why not just one of them?

Sure wp_query returns more data than get_posts (I think?), but where would it make sense to use get_posts instead of new wp_query? Is the only real difference the get_posts returns it’s results in an array and all data stays within that function?

Thanks

You sir, are a star. Thanks.

Reading up now on add_meta_box() now.

Wondering if it’s possible to make it conditional so meta box only shows up when a specific category is selected. Probably over thinking things a little though!