feedmeastraycat
Forum Replies Created
-
Forum: Plugins
In reply to: [Print Invoice & Delivery Notes for WooCommerce] Attribute formatting issue@priyankajagtap I understand that its summer and people might be away. So no rush. Just wanted to check in to see if there might be an ETA on if you will be able to fix/improve this or if I should try to go another route. 🙂
Forum: Plugins
In reply to: [Print Invoice & Delivery Notes for WooCommerce] Attribute formatting issue@priyankajagtap I did a test now. It’s an improvement but its not fully what I hoped for.
The HTML now looks like this:
<td class="product-name">
<span class="name">
Oxford - Täckplugg med M8 & M10 Gänga För Backspegel
</span>
<br>
<strong>Gängstorlek : </strong>M10
<dl class="extras">
<dt>Artikelnr:</dt>
<dd>OX756</dd>
</dl> </td>Or here is an example with two extra attributes:
<td class="product-name">
<span class="name">
Puig - Touring Vindruta till Triumph Tiger 1200
</span>
<br>
<strong>Färg : </strong>Tonad
<br>
<strong>Leveranstid 3-8 arbetsdagar : </strong>1
<dl class="extras">
<dt>Artikelnr:</dt>
<dd>21336H</dd>
</dl> </td>So its still much harder to format the “Gängstorlek” part then the “<dl class=extras>”-part. And there is still an extra space between the name and “:”.
Would be super if these variant names and what not could be printed in a <dl> type element as well?! 🙂
@jkohlbach Excellent!
Forum: Plugins
In reply to: [Print Invoice & Delivery Notes for WooCommerce] Attribute formatting issue@priyankajagtap Excellent! I will test it out and get back to you!
@jkohlbach Any ETA on the update?
I dont want to downgrade WooCommerce but I found a small piece of hack that worked for us *for now*.
In templates/print-content.php I changed line 160:
$item_meta_fields = wc_display_item_meta( $item, apply_filters( 'wcdn_product_meta_data', $item['item_meta'], $item ) );To just:
$item_meta_fields = apply_filters( 'wcdn_product_meta_data', $item['item_meta'], $item );It does not look as good. But the information is there at least. I dont know if this can cause other problems though. 🙂 But as far as a quick hack goes, it might help someone else.
**Backup before testing** 😉
The problem might be related to this WooCommerce patch:
https://github.com/woocommerce/woocommerce/commit/7332b64eeb63159b5c8b39390dec7df0a55142f8But I have not spent that much time testing it though.
@jkohlbach Great! 🙂
@jkohlbach I can confirm I have this issue as well after changing to HPOS.
I would assume this is something a lot of Swedish stores would be affected by. We have a shipping provider called “PostNord” so orders have a order data called meta_data[_postnord_servicepoint] which contains an object.
The object is basically a bunch of data about the pick up locations the customer selected.
The fix @hotcookie posted above for order_data.php works for me. Would be nice to have an official release with a fix.
You can test to duplicate the issue by just inserting a row or changing a row to contain this value:
O:8:"stdClass":2:{s:3:"foo";s:3:"Bar";s:5:"inner";O:8:"stdClass":1:{s:3:"bar";s:3:"Foo";}}@nigelrsb I found the issue! The site is a bit older and the options table was still on utf8mb3 for some reason and you guys are sending in an emoji in the notifications data. So when SBI_Notifications->update() runs update_option() it fails (it returns false, but that is never checked in the plugin).
It’s true that there is a cron job fetching the notifications once per week. But there is also a fallback to fetch the notifications on each page load if the cron has failed. And this fallback will run twice if update_option() fails. So when it the notification data contained a emoji, it failed, and it tried again. The cron works fine. But will also fail because of the same issue.
Might be a good idea not to use emojis. Or at least have some error handling when update_option() fails. Maybe set empty data just updating the timestamp so it does not try again.
@spyrosvl Sorry for hijacking your support thread. 🙂 But maybe you have the same issue!
If anyone else finds this issue and have the same problem it was fixed by changing the table charset, for example:
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;Remember to backup first!
- This reply was modified 1 year, 2 months ago by feedmeastraycat.
@nigelrsb I would also like to suggest that you use cache to store the result from https://plugin.smashballoon.com/notifications.json a couple of hours at least. I would say it might be enough to just do it once a day really. How often do you actually update the notifications anyway? 🙂
According to Query Monitor it does it twice per page load.
Here is some debug information you can send to the developers.
First time it goes (reverse trace):
SBI_Notifications->fetch_feed()
wp-content/plugins/instagram-feed-pro/inc/admin/class-sbi-notifications.php:141SBI_Notifications->update()
wp-content/plugins/instagram-feed-pro/inc/admin/class-sbi-notifications.php:403SBI_Notifications->get()
wp-content/plugins/instagram-feed-pro/inc/admin/class-sbi-notifications.php:332SBI_Notifications->output()
wp-content/plugins/instagram-feed-pro/inc/admin/class-sbi-notifications.php:495do_action('admin_init')
wp-includes/plugin.php:517
And the second time:
SBI_Notifications->fetch_feed()
wp-content/plugins/instagram-feed-pro/inc/admin/class-sbi-notifications.php:141SBI_Notifications->update()
wp-content/plugins/instagram-feed-pro/inc/admin/class-sbi-notifications.php:403SBI_Notifications->get()
wp-content/plugins/instagram-feed-pro/inc/admin/class-sbi-notifications.php:332SBI_Notifications->enqueues()
wp-content/plugins/instagram-feed-pro/inc/admin/class-sbi-notifications.php:427do_action('admin_enqueue_scripts')
wp-includes/plugin.php:517
I have not debugged it further to see if its a simple bug in SBI_Notifications or if the object gets initialized twice.
But yeah, even if that bug is fixed. Calling remote on every page load is a bit excessive. 🙂
I believe this is fixed with 2.19. Great job.
Forum: Plugins
In reply to: [Cookies and Content Security Policy] Remove jQueryGreat news! I updated the plugin on my “problem” site (where I had WPML cookie issue with regards to the “js in php” thing) and it looks like the problem is gone.
Vanilla js would be a big bonus. But its not a big issue obviously. 🙂
@jonkastonka Just checking, did you get my email? Let me know if you have time to look at it soon(ish). 🙂
@jonkastonka Yeah. Strange indeed. I think its just how the plugin loads WP that causes WPML not to do its stuff completely.
If the javascript was loaded fully through WP. For example if you had site.com/?load-cookie-error-message-stuff=1 as the javascript URL. And then used for example the template_redirect action to output the javascript. It might not be an issue.
Im thinking that what  js/cookies-and-content-security-policy-error-message.php does now is that it boots up WP to some extend. But it does not let everything load up completely.
But this is totally guessing here. I havent tested that far (yet). 🙂
Im gonna have a look if I can add you as a user to the site where we noticed it.
Forum: Plugins
In reply to: [WP Editor Widget] What will happen to exisiting widgetsSince WordPress have a built in widget with a wysiwyg I decided to not contintue to support the plugin. And with full site editing in the works its hard to say if it will stop working all of a sudden. There might be workaround with stopping the block editor widgets or something, I havent looked into it. I would recommend moving to another solution before it turns into an issue. 🙂
Black Studio TinyMCE Widget might also be another option.
If you disable the plugin WordPress doesnt know how to output them and they will disappear.
With regards to converting them its hard to say, because it depends on what you want to convert them to.
You can read here about where widgets are stored. Reading the WP Editor Widgets data might not be hard. And then putting them into something else depends on what other solution you want to use.
It might be easier to leave the plugin active and manually move widgets and disable the plugin once its done.