Hi
apologies for the delay – I had responded in my head, but never put it to paper so to speak.
Regardless, looking at your site , your (wppizza related ) plugins – specifically the post/zipcode plugin – are several years out of date, so I would suggest you update those to to most recent version to start off with.
Furthermore, enabling debugging is also always a good thing to do if you have any issues ( see https://docs.wp-pizza.com/troubleshooting/ )

PS: your site also links to localhost images/links that do not work obviously

Hi

looking at your site, you are running a version of the postcode plugin that is over 7 years old (v 4.0.7 – Oct 2017) , so I would first of all suggest you update it to the most recent version (v5.2.3 as of writing).

PS: as a quick fix until either WP updates things their end or I find a suitable workaround – whatever happens first –
you could copy the language files you need – i suspect in your case wppizza-admin-de_DE.mo and wppizza-admin-de_DE.po from wp-content/plugins/wppizza/lang into wp-content/languages/plugins
so they will be read form there

Not sure if this was intentional or a mistake by WP’s devs, but suffice to say that’s quite a nasty change that happened there and I suspect will affect lots of plugins and theme’s (WPPizza or not)

Relatively easily fixed I think (though I have not yet 100% worked through all the the implications) but needs an update to the wppizza plugin (as well as – almost all – associated extensions) .
So that’ll be me being busy for a few days then…
I’ll make updates available asap – starting with the main WPPizza plugin of course..

Thanks for flagging it, I probably would not have noticed for quite some time otherwise.

wppizza is a custom post type, category__not_in will not work there. you will need taxonomy queries

$args['tax_query']['relation'] = 'AND' ;
$args['tax_query'][1]['taxonomy'] 			=  WPPIZZA_TAXONOMY ;
$args['tax_query'][1]['field'] 			=  'id' ;
$args['tax_query'][1]['terms'] 			=  array(16) ;/* 16 being your beer/wine cat */ 
$args['tax_query'][1]['include_children'] 			=  false ;
$args['tax_query'][1]['operator'] 			=  'NOT IN' ;

that said, having thought about this a bit more, I think this is actually going down the wrong path as you would also have to find a way to reload the page when switching between pickup/delivery . Do-able but somewhat unnecessarily complicated altogether if you ask me.

perhaps a (somewhat) better approach is actually some js here .

every item has a title with an id , that is made up of blogid, catid, postid, sizes(tier)id, in tier id like

<h2 id="wppizza-article-1-2-8-3-0" class="wppizza-article-h2">

so you can select all ‘wppizza-article-h2’ on a page , get the id’s , split by ‘-‘ to then get all ‘cat ids’ so to speak
and show/hide depending on pickup/delivery value and when switching between the two (you’d still need to set the session in the cart accordingly with a php filter)

advantage being you do not have to reload any pages so much faster (still many pitfalls on the way to be encountered , but personally i think a better approach)

I might make this sort of thing into a plugin myself as i can see the possible need for this in certain circumstances, but at the moment we are where we are

you would need to put your dough selection it into it’s own (custom) group . (with a “…choose one only…” setting I would think)
Otherwise it’s just another ingredient.

Regarding pickup / delivery :
there’s a ‘wppizza_filter_loop_args’ filter that lets you set the arguments (i.e the posts returned). so in conjunction with

if(wppizza_is_pickup()){
/* do something if pickup selected*/
}

for example (https://docs.wp-pizza.com/developers/?section=global-wppizza-functions)
I would think you could exclude posts (i.e post id’s ) as required . Probably simply getting all wppizza posts(ids) that belong to your beverages category and exclude/include as required

alternatively, some conditional – again , based on wppizza_is_pickup() that simply removes the beverages shortcode of the page where you have it (or exclude that page entirely from your site when it’s pickup)

Up to you which way you want to do this of course

Ok, now you are describing this, I can reproduce this (it’s got to do with your first one having an ident of zero most likely)

I’ll fix that

FYI: v5.3.1 should have this fixed now

I’ve no idea what happened there.

I’ll fix this in the next couple of hours or so with 5.3.1 update .
In the meantime, you could simply change

'name'=>$this->render_tags($v['item']) . $this->render_additives($k, $v),
back to
'name'=>$this->render_tags($v['item']) ,

so it stops throwing those errors (or of course downgrade back to 5.2.2 – whatever is easiest)

Apologies for messing this up

forget all of that . the render_additives function got lost in the upload somehow.
I’ll fix that asap.

thansk for reporting