Adrian Mörchen
Forum Replies Created
-
@ahmeddr Thanks for you reply.
Looks like ads are rendered infinitely instead of only times.
Current setup in our test environment
- Theme: Twentytwentyfive
- Only 2 plugins activated: Advanced Ads, Advanced Ads Pro
@janilyn409 They are shown there, because it is implemented separately for these cases in your plugin (from what I see).
But other plugins, using get_meta have a problem now and need to implement something special only for your plugin: https://woocommerce.github.io/code-reference/classes/WC-Data.html#method_get_meta
The problem is
- since 2.1.0 the data is stored as “hidden” metadata only
- but up until 2.0 the data was saved in both variants… “hidden” and as plain “Title” : value pair
This really is a breaking change not communicated anywhere…
My opinion: if it is shown as “plain text” metadata in the backend, it also should be stored as this… I know Woocommerce is not perfect with this kind of data.
I can confirm, that order item metadata is not working correctly anymore …
Short: it isn’t possible to call
$order_item->get_meta('Included ... ')to get custom data from WCPO anymore…- This reply was modified 4 months, 2 weeks ago by Adrian Mörchen.
👍 Thank you for the quick fix.
Forum: Plugins
In reply to: [Klarna for WooCommerce] _load_textdomain_just_in_time()@klarnaplugin How long until the fix?
This problem is known since some time within the WP ecosystem and the fix is very simple. From a company like Klarna, I expect this kind of issues to be fixed very soon … in this case even before the official WP release containing the new warning.
Now, it is just flooding our logs …
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 1 year, 4 months ago by Adrian Mörchen.
Forum: Plugins
In reply to: [WooCommerce] Language suddenly switched to another languageThe 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
Forum: Plugins
In reply to: [Advanced Custom Fields (ACF®)] Still shows as ACF, even if SCFI’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…Forum: Plugins
In reply to: [Advanced Custom Fields (ACF®)] Still shows as ACF, even if SCF@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 2 years, 2 months ago by Adrian Mörchen.
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…
Forum: Reviews
In reply to: [Pods - Custom Content Types and Fields] Please don’t use PodsHello 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…
Forum: Plugins
In reply to: [Meta Field Block] Not working on custom taxonomy page (ACF)Hello Phi,
Thank you.
Then this is a feature request, would be much easier to not write custom code 😉
Adrian