Rimas
Forum Replies Created
-
Well, I’m not holding my breath, but just in case you decide to take a look in the future, the new URL is here: https://codeberg.org/rimas/wp-woocommerce-feed-manager.
Dear @monircoderex, have you considered reviewing and accepting my patches?
Forum: Plugins
In reply to: [The Events Calendar] Non-Google mapsHi @d0153! For an idea that is already marked as “In progress” you’re very vague. 🙂
I guess that’s life then. I’m not going to subscribe to that feature request because I don’t want to create a yet another user account. I already have too many of those. Still, thanks!
I guess I’m marking this as resolved then.
Forum: Plugins
In reply to: [The Events Calendar] Non-Google mapsHi @d0153! Yes, that’s pretty much what I want. Any plans to implement it?
Hi, and thanks for the good news!
I’ve implemented a feed for kainos.lt in a separate commit as well, which can also be used (with some customization) for another aggregator kaina24.lt and its Estonian sister hind.ee.
Great, I’m looking forward to the fixes! Cheers!
Another example of where a feed with nested elements is needed: the most popular Lithuanian price aggregator website kainos.lt expects categories to be listed as
products > product > categories > category(also extra images and attributes need nested structure, but these can be omitted). I don’t think this can be achieved by using theCustommerchant, so I’ll either have to find another existing merchant which uses a similar feed structure (and I had trouble with that due to a PHP8 support bug I reported yesterday), or implement it in a new merchant like I did with varle.lt.By the way, looking for a potentially matching feed structure is currently a long and tiring excercise, because each try costs around half a minute. It would be nice to be able to see example feeds of each provided type without actually generating them all. Maybe documentation could be expanded to include such examples with one sample product for each feed?
Fair enough, I guess. Thanks for the clarification! 🙂
By the way, eMAG appears to expect weights in grams, whereas WooCommerce stores them in kilograms. Again, multiplication is needed, and this time it can’t be solved by a suffix without sacrificing ability to specify weights in fractions of kg.
To add to my initial suggestion: instead of creating multiple unit conversion filters, it would probably be better to allow specifying a multiplier when configuring a field (similarly to setting prefix and suffix), which should be applied if the value in the field is numeric. This way, a single option would cover conversion between all units of the same type as well as any other cases where multiplication or division would be necessary (I can’t currently think of any, but that doesn’t mean there are none).
For example, a multiplier of 10 would effectively convert centimeters to millimeters, and a multiplier of 0.1 would convert the other way around.
- This reply was modified 1 year, 3 months ago by Rimas.
Also on somewhat related note: when I set suffix to
0in an of a lazy conversion of cm to mm, that suffix was ignored, because"0"is an empty value in PHP, and both the prefix and suffix are tested for being empty here. Instead of checking for these values being empty, may I suggest you to just cast them to strings before using?Hi @monircoderex!
I’m sure I sent a reply yesterday with a link to my clone of your repo, but with varle.lt already implemented, but somehow it’s gone now. I wonder why.
Just in case, here’s the link. I implemented Varle.lt in a single commit, so you can just generate a patch from that commit and apply it to your own repo.
Cheers!
- This reply was modified 1 year, 3 months ago by Rimas.
Umm, ping?
Sure, I’ve found one already.