ionut.calara

I removed the templates, so the performance footprint should be no longer noticeable. As you mentioned loading scripts and styles is what is that makes the experience for people in the admin worse.

Thank you for pointing these issues out, this will make a difference for all the users.

@mathieu I think this can definitely be added, but to make sure that the plugin only runs in just the situations it needs to run I will probably have to split the settings part from the rest of the plugin, which is not super easy at this time. The main focus of the plugin was compatibility, the performance footprint should now be considerably reduced if the scripts are not loaded, but I will also add this about templates soon. Are you also concerned about the php running on pages that it’s not needed?

• This reply was modified 5 months, 1 week ago by ionut.calara.

@mathieu I have updated the plugin. I couldn’t easily change the loading to be later, as I needed to register the settings pages earlier, but I was able to not load the css and js if the wp_enqueue_media action was not called in the stockpackmedia class. This also removes the javascript error that you mentioned.

Thank you for diving deeper into this, let me know if you have any questions or issues.

I am closing this ticket, but feel free to reopen.

Hi @mathieu thank you for looking into this, the frontend_load_stockpack was initially called later, but was changed to improve compatibility with builders plugin that also work on the FE.

I will test the changes and see how I can make it also work with the builders and get back with a plugin update by the end of next week.

Hey @mathieu the latest release, 3.3.9 automatically removes the action right after the class that adds them is called, so you can safely update and remove the code that you added.

Thank you for the report once again, I will close this issue, but feel free to reopen if needed.

Hi @mathieu sorry for the delay in response, I was out of the office,

This issue is triggered by the third party settings class I am using, and it would only impact the color picker for settings, which I am not even using, but I didn’t notice it, and I didn’t modify the third party script. So removing this should be a good thing and I will investigate this deeper to see if I could disable it directly from the plugin.

I will update this post when an update for the plugin that fixes this is ready.

Thank you for reporting this issue!

@panograph thank you for the kind words!

The error might mean that initially there was a problem, but the funds where then made available. If it looks good in the dashboard it should be fine.

Hi there, we do not store the CVC anywhere in the plugin, so it shouldn’t be visible. Could you please write an email with a screenshot and send it to [email protected]?

Hi?@loano1 , in order to select the default provider, you will need to log into https://stockpack.co/providers and click the select button near the provider you want to be marked as default.

https://share.getcloudapp.com/6quYkWLk

I am closing this ticket for now, but feel free to reopen if you have any other questions.

Thank you,
Ionut

@malaga16 we have released update 4.0.0 which has support for HPOS.

If you have any issues please let us know.

Hey, thank you for the message, we will update the flow to go trough the HPOS system for new orders, and it should be available before this becomes the default.

Glad to hear that the translation working, thank you for the update.

Hi @sandornemeth I am afraid I couldn’t find anything specifc on how to make this work with Polylang, we’re using the standard method to store and display the title and description.

For the polylang compatiblity I only found https://github.com/hyyan/woo-poly-integration, but it seems it is no longer maintained. Did you ask the polylang support team?

Hi Andy, thank you for the report, I have just released version 3.3.5 with the corrections you outlined in the pull request.

I am closing this ticket, but feel free to reopen if needed.

Thank you,
Ionut