leanderbraunschweig
Forum Replies Created
-
Forum: Plugins
In reply to: [Germanized for WooCommerce] Kassen-Features komplett deaktivieren?Danke für die schnelle Rückmeldung!
Klingt super und habe die Konstante bereits eingesetzt – leider werden weiterhin Anpassungen im Checkout / an der Kasse durchgeführt, u.a.
– CSS-Assets werden geladen und überschreiben unser Styling in Teilen
/plugins/woocommerce-germanized/assets/css/layout.min.css
– Der woocommerce-checkout-review-order-table taucht weiterhin doppelt auf, trotz Filterung (s.u.)Ich habe zusätzlich noch die Filter (via diesem Gist) gesetzt:
add_filter( 'woocommerce_gzd_insert_order_submit_fallback', '__return_false' ); add_filter( 'wc_gzd_checkout_params', 'my_child_prevent_gzd_checkout_heading_switch', 10 ); function my_child_prevent_gzd_checkout_heading_switch( $params ) { $params['adjust_heading'] = false; return $params; }aber leider ohne Erfolg…
Ich vermute, dass diese action damit zu tun hat:
add_action( 'woocommerce_checkout_order_review', 'woocommerce_gzd_template_order_submit', wc_gzd_get_hook_priority( 'checkout_order_submit' ) );Habe es daraufhin mit
remove_action('woocommerce_checkout_order_review', 'woocommerce_gzd_template_order_submit', 99999);probiert aber auch ohne Effekt…
Was mache ich falsch?
Danke & Gruß!
+1 – looking forward to a fix…!
Forum: Plugins
In reply to: [wp-Typography] Cannot process strings programmatically…?Ah, gotcha – that makes sense then…
I followed your documentation and there it doesn’t mention the
$is_titleparameter. I could / should have checked the source I guess 😐Anyhow, thanks for getting back and I’ll adjust the code accordingly.
- This reply was modified 3 months, 4 weeks ago by leanderbraunschweig.
Great, thanks a lot for all your work!! 🚀
I reverted said change, recreated the indices and cleared the cache – and this did the trick…!
The related posts are not identical any more 🙂
Maybe you can re-work this to apply to each situation (title only / title & content)?
Looking forward to the next version and many thanks for your input and efforts regarding fixing this!
Forum: Plugins
In reply to: [wp-Typography] Cannot process strings programmatically…?Thanks for getting back and sorry for the late reply…
I changed the line as suggested, re-created the indices and cleared the plugin cache but the related posts still appear in an identical fashion (only the current post gets substituted).
So unfortunately (?) the stopwords are not responsible for the change.
Any other ideas?
Thanks & regards!
Forum: Plugins
In reply to: [wp-Typography] Cannot process strings programmatically…?Hi @pputzer,
What does $tagline contain exactly?
Just a regular string… It works fine when activating the “hyphenate titles” option. And I tried with said string “Bei Profis und Amateuren gleichermaßen beliebtes Leinenschläppchen mit geteilter Sohle” directly to go around any possible issues with input or filters and could reproduce the behaviour.
Did you test on your end yet? Should be easily reproducible – at least that’s my guess.
(BTW, when you don’t change the settings as defined in the plugin options, you can omit the parameter, no need to copy the object.)
Makes sense 🙂 Thanks for pointing it out!
Forum: Plugins
In reply to: [wp-Typography] Cannot process strings programmatically…?Hi @pputzer,
sure thing:
Settings output
Filter / code used
// Add product sublines (via ACF) add_action('woocommerce_after_shop_loop_item_title', function() { $tagline = get_field('tagline'); if(class_exists('WP_Typography')) { $s = \WP_Typography::get_user_settings(); $tagline = \WP_Typography::process($tagline, $s); } echo '<p class="tagline">' . $tagline . '</p>'; }, 9);Besides the action hook I also tested directly in the template, thus the usage of a filter / hook or not doesn’t make a difference with regards to the missing hyphenation here…
I can also send you the link to our development environment where you can view the output directly if that is helpful.
Thanks so much for looking into this!
Hi @ajay,
thanks for testing on your install & getting back!
I went ahead and set up a development environment and updated to v
3.1.1in order to be able to directly compare the results and the underlying queries.At first everything appeared to working fine but after re-indexing and clearing the cache the issue became apparent again…
An exemplary query / request would be this:
string(738) "SELECT wp_posts.*, MATCH (wp_posts.post_title,wp_posts.post_content) AGAINST (' Sie emotional abhängig Ihrem Partner?') as score FROM wp_posts WHERE 1=1 AND ( wp_posts.post_date <= '2022-02-15 12:44:48' ) AND wp_posts.ID NOT IN (4239) AND wp_posts.post_type = 'post' AND ((wp_posts.post_status = 'publish' OR wp_posts.post_status = 'inherit')) AND MATCH (wp_posts.post_title,wp_posts.post_content) AGAINST (' Sie emotional abhängig Ihrem Partner?') ORDER BY FIELD(wp_posts.ID, 5162,5143,4927,4818,4787,4368,4235,3915,3628,3579,2960,2961,2495,1564,1970,1980,629,1269,1254,1986,1560,1440,577,728,1567,605,613,3500,3470,3708,1555,1443,3967,2424,3547,1455,4239,1976,1427,619,621,624,627) DESC, wp_posts.post_date ASC LIMIT 0, 8"The same post on the live site running v
3.0.7yields this request:string(710) "SELECT wp_posts.*, MATCH (wp_posts.post_title) AGAINST ('Sind Sie emotional abhängig von Ihrem Partner?') as score FROM wp_posts WHERE 1=1 AND ( wp_posts.post_date <= '2022-02-15 12:51:46' ) AND wp_posts.ID NOT IN (4239) AND wp_posts.post_type = 'post' AND ((wp_posts.post_status = 'publish' OR wp_posts.post_status = 'inherit')) AND MATCH (wp_posts.post_title) AGAINST ('Sind Sie emotional abhängig von Ihrem Partner?') ORDER BY FIELD(wp_posts.ID, 5162,5143,4927,4818,4787,4368,4235,3915,3628,3579,2960,2961,2495,1564,1970,1980,629,1269,1254,1986,1560,1440,577,728,1567,605,613,3500,3470,3708,1555,1443,3967,2424,3547,1455,4239,1976,1427,619,621,624,627) DESC, wp_posts.post_date ASC LIMIT 0, 8"Comparing the two requests I can see that the AGAINST-value is differentiating and this most probably is due to the stopword check.
Removing “Sind” & “von” is actually a great feature but I there must be something wrong with either how the string is handled (see the empty space at the start, could be troublesome for MySQL maybe?) or the index is being built with this regard?
Thanks for your assistance so far and luckily we could narrow the issue down a bit…!
If you need (frontend-)access to our DEV environment in order to view a few more queries then just let me know and I’ll send over the details.
- This reply was modified 4 months, 2 weeks ago by leanderbraunschweig.
Forum: Plugins
In reply to: [wp-Typography] Cannot process strings programmatically…?Hi @pputzer,
you are right – title hyphenation was unchecked / disabled and thus the
WP_Typography::process_title-function couldn’t work…But deviating from the code I have posted above I am actually using
WP_Typography::processin order to hyphenate my string and that doesn’t work as well despite not falling under said setting. Obviously the title-setting overwrites any hyphenation-processing?Guess we would like to not have the titles be hyphenated and still programmatically process strings – how would that be possible?
Thanks & regards!
Just downgraded to v
3.0.7and this resolves the issue – the variance returns and the posts shown are much more targeted and ‘related’ then with the newer plugin versions…Hi @ajay,
we are facing the same issue… All of a sudden the related posts are identical (with the exception of the current post being excluded from the list) :-/
I tried:
- Clearing the cache
- Tweaking the setting for “Related posts based on title and content” (title only before but no change)
How can I debug the query args that are being applied to the related posts query? Do you think there is an issue with the indexer?
Something else: Since saving the settings doesn’t automatically clear the cache any more you should alter the text on the tools page –> Clear the Contextual Related Posts cache. This will also be cleared automatically when you save the settings page.
Thanks for looking into this and especially for developing & maintaining this plugin!
Hey David,
many thanks for this!! Exactly the push into the right direction I was hoping for.
Will look into the code and report back once I have found a solution for our problem.
Kind regards,
Henning
Forum: Plugins
In reply to: [BackWPup - WordPress Backup Plugin] S3 bucket fails, again, again and again!I found the culprit:
You need to select a S3-Service in the destination settings that exactly matches the bucket’s AWS-Region – if they differ then said error is being thrown / the bucket cannot be addressed…
This is quite un-intuitive IMO and most probably you could gather the region settings from the bucket and one wouldn’t need to make a selection…? Alternatively the UI should reflect this and at least include a text notice with regards to this.