Adrian

I was able to reduce this to some issue with WPML String Translation and created a ticket there too.

@ckadenge For us, mails (i.e. order confirmation) are still sent in English. Even if I trigger the mails from the backend (which is shown in the correct language)

But we are also using WPML. Everything is updated…

This worked with 6.6.x…

• This reply was modified 18 hours, 47 minutes ago by Adrian.

The same here, but only for mails.. mails now sent in English instead of German. But we are also using WPML.

I don’t know if this is a Woocommerce problem or just because of the broken “translation” improvements in 6.7

I’m generally fine with not changing the slug and getting downloads and reviews… But the only reason should be an official – from both sides – planned handover (and not takeover).

But in this special case, there are other reasons too:

• Avoid confusion!
• The chance: as good as ACF is, there are quite some technical debts in it too and a “new” plugin can be a chance to clean this up. (this still can happen)

As much as I like ACF, and we are using it in every project (mostly the pro version)… if there is a core plugin with a similar feature set, we will just switch.

—

And there were other cases in the past, where a very good single-feature plugin got bought and transformed to some bloatware… We also have some free plugins, tried Freemium in the past. For me, there are reasons for this happening.
First and foremost: no direct git support (or better Github) support for the repo. They always speak of “community”, but thanks to missing git it makes very hard to contribute at all. And then, as a developer… you don’t get anything using the wp.org repo… never ever someone donated for my plugins… To be honest: Automattic is earning money, riding the GPL-train as hell, but don’t give plugin developers a way to at least cover costs…

@foosantos Thanks for your feedback… On a fresh installation, there are still a lot of ACF references, esp. in help texts.

But also the link to the documentation links to the original documentation… very confusing…

I don’t like how everything has worked out, still see this as a chance too.

But WP.org can’t make such a rushed move with all this “talk” and promises and then deliver such a mess. I’m a professional and can handle this, but average users …

@shameemreza Your responses are very confusing. Please don’t refer to the old shortcode….

• The original question was about the checkout block
• There are currently no plugins or simple solutions available to extend the block based checkout with new fields
• This is really annoying and frustrating:
  • Woo is advertising the new block based checkout
  • even if it is not compatible with Woos own API or expensive plugins

With the old checkout, it was super easy to add some fields. Now I have to invest hours for creating a bloated block, just for one input field.

Don’t get me wrong. I love Gutenberg, and I’m using it for all new projects. But this kind of thing makes it frustrating, it is time-consuming and expensive. I need a new technology and whole build pipeline, I’ve never used before…

• This reply was modified 9 months, 3 weeks ago by Adrian.

@jeffpaul

The problems we have are “random” server errors. Too much load, maybe… Nothing you can do something about…

I’m not sure, if it could work better with some “processing view”, which opens the pages within an iframe and could just do a random reload, if there is nothing happening in an iframe.

FYI we are currently at ~66% after ~10 days. On a test system. But we have enough time and can migrate the live system before a major upgrade (theme migration to Gutenberg)

A bug fix release breaking the entire plugin…

Hello Scott,

Thanks for your comprehensive feedback. I really wrangled with me, before writing this feedback. I also gave 3 stars, because pods itself is okay and solves a problem. Furthermore, I also appreciate your hard work.

<tl/dr> any project pods is involved is way harder to maintain (for us). I’m not sure why, but this is my experience over the years. Maybe, because Pods is quite invasive through custom tables, relationships, custom queries … IMO, this is something, which someone should avoid by any means (I know this is hard, as WordPress is missing essential features here)

—

We have 2 large pods projects and these are the hardest to maintain and migrate to newer stuff (Gutenberg related), because of a lot of pods related stuff (a lot of calls to pods(…) ) . I wasn’t the original maintainer for our large projects, just helped and eventually overtook it. Maybe we did something wrong in the beginning?

We used custom pods tables a lot and not the WordPress tables.
→ so I think this is the main reason we have to use pods over WP query i.e.

—

Updates with pods… We just have this regularly, just with the last pods update, in combination with WPML. We just rolled back, as we migrate to ACF anyway.

—

Yes, I was referring to Josh. I always thought he was the original author of pods too… nevertheless, working with Caldera Forms was horrible, I probably projected this to pods too…

Hello Phi,

Thank you.

Then this is a feature request, would be much easier to not write custom code ??

Adrian

I’m avoiding jQuery in WP projects since years now… it is easier than most people think, and really gives a boost in performance. (even WordPress itself is slowly getting away from jQuery too)

Imho, Advanced Forms is not that large, and you probably can get rid of jQuery quite easy.

ACF itself is something else, sure. But you could at least start…

There is also a critical error with Admin Columns (Pro)

Fatal error: Uncaught Error: Class "AC\Dependencies" not found in /[...]/wp-content/plugins/admin-columns-pro/admin-columns-pro.php:60 Stack trace: 
#0 /[...]/wp-includes/class-wp-hook.php(308): {closure}('dxdam_admin_use...') 
#1 /[...]/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters(NULL, Array) 
#2 /[...]/wp-includes/plugin.php(517): WP_Hook->do_action(Array) 
#3 /[...]/wp-content/plugins/dx-delete-attached-media/dx-delete-attached-media.php(339): do_action('after_setup_the...', 'dxdam_admin_use...') 
#4 /[...]/wp-settings.php(453): include_once('/www/htdocs/w01...') 
#5 /[...]/wp-config.php(99): require_once('/www/htdocs/w01...') 
#6 /[...]/wp-load.php(50): require_once('/www/htdocs/w01...') 
#7 /[...]/wp-admin/admin.php(34): require_once('/www/htdocs/w01...') 
#8 /[...]/wp-admin/plugins.php(10): require_once('/www/htdocs/w01...') 
#9 {main} thrown in /[...]/wp-content/plugins/admin-columns-pro/admin-columns-pro.php on line 60

• This reply was modified 1 year, 6 months ago by Adrian.

@wpmudevsupport13 Thanks for your feedback.

Unfortunately, these “benefits” don’t sell for me. I’m using BLC on about 50+ sites I maintain for years now, and never had any problems with performance or whatever, which would justify the change in any way.

Where is the cron the issue? BLC just runs in the background and does it check sporadically, only covering a couple of links from time to time…

It is just you, trying to sell the same features as “better”.
I understand, that it is hard to earn money, and you have to discover new ways.

BLC not really changed over the years, it has a single quite “simple” use case, which is totally stable and was working nicely. Hard to justify, i.e. another subscription model or whatever.

As I mentioned above, imo the concern is Automattic (and not us) not coming up with a solution for users and developers.

@maartenbelmans

Thank you, it is also triggered externally

In \SW_WAPF\Includes\Controllers\Product_Controller::validate_cart_data
-> Through WooCommerce filter: woocommerce_add_to_cart_validation

Which might be triggered from other plugins ??

@guicmazeredo Is there a public solution for this? I have the same problem.

The popup is showing a lot of times, even it is configured to only be shown on one page…