Ward

After looking at the code I realized the default providers are listed according to your API and are not stored locally, which I understand due to integration with Trackship.

Can you at least provide a way or an update to hide them from the orders page droplist as long as they are disabled and only show active one?

was implemented, so I’m gonna close.

//

• This reply was modified 3 years, 8 months ago by Ward. Reason: Retracted

Which table are they stored in?
As they clutter my order screen, when you click filter by shipping provider you get a drop list with 300 providers which is not practical.

• This reply was modified 3 years, 8 months ago by Ward.

Unfortunately our current staging environment contains sensitive data.
I’ll try to setup a new empty staging websites and let you know.

Thank you for the follow up.

Hello,

There is no sensitive data that require an email.
Here’s my server information:
-PHP 7.4.9, MariaDB 10.5.5
-Server is Apache + NGINX
-Centos 7.0
-Wordpress 5.7.2
Let me know if you need any other info, I’m happy to share publicly.

I noticed the issue after the last update (Both WordPress and plugin were updated at the same time)

Hello, I’ve enabled debugging and debug logging and there is no records whatsoever related to your plugin in the log.

There is also no errors/notices in the PHP log relating to your plugin.

The same behaviour happens.

-Click re-index, it keeps loading and adds the products.
-Refresh the page and it’ll go back to 0 products.

Hello Salva,
Thank you for your response. I do completely understand what you mean and agree as well about versioning rationale from your side. I believe you did get my point as well. It’s not necessarily about those classes changes it’s about about how often they change or whether that change was necessary.

Your point about security/bugs is 100% valid but as you can imagine production websites do not update often unless a crucial vulnerability or bug is found. So a lot of the times we’re jumping a few release when we do our monthly maintenance/update cycles not just a single release.

Thank you for the civil discussion. I’ll make sure to keep ATUM/Addons versions in sync going forward.

We’ve been advocating for ATUM since we used it but we won’t be a good advocate if we didn’t mention the negatives along with the positive ??

Have a good day!

I did create a sandbox to help you debug the issue. and it works as intended if it was only WordPress, woocommerce and code widget installed.

The issue does appear to be a plugin conflict, something about wp-nonce failing. While I do not currently have the time to debug this further, I’ve ran into this issue with other plugins before and how we solved it together was by changing how you track the dismissible action.

It’s a low priority issue I’m sure since it shouldn’t affect every one. If you have a github repository with the plugin, please link it I’ll perhaps send you a pull request to fix the issue (keeps the advertisement by make it dismissible without conflicting with other plugins).

Regards,

Thank you for your response Pavel,
I’m a developer as well so I do understand the need for constant updates, my concern here is the functionality-breaking updates. At least a warning before major changes is welcome.

For example almost every Woocommerce update that has core changes that could break other plugins or integrations gives you a warning message “this is a major update, back up your site …etc”. I believe this has more to do with your version numbering than with the updates themselves, you push the major changes as minor patches not new versions.

We do our tests and upgrades in staging websites, but the whole point of staging is to debug before pushing to live and this is where we found the issue mentioned here.

I do check the changelogs, hence my note about the “refactoring” thing. Basically every time you have “refactoring” in your changelog it means it most likely will break compatibility with addons.

I’m not in the position to tell you how to manage your own plugin, it’s an open source project and we appreciated you sharing it with the community via www.remarpro.com, my concern was with your update process and what I think is safe to say “unnecessary” refactoring. Woocommerce for example which ATUM here extends keeps deprecated functions working for a long time after they’ve been changed to allow devs to rewrite their code to the new functions. A similar practice for ATUM would be welcome.

Anyhow, I do believe this discussion would go no where, as it’s your business model/choice, and I’m in no position to suggest you change that. Just take this as a recommendation.

We’ll get yet another license but as someone who’s been using ATUM for my own projects and clients for 2+ years, I truly wish you take into consideration my recommendation.

I understand it’s hard to maintain paid plugins with all the illegal/nulled sharing platforms and your change would make sense to render those useless, but your change is damaging paying customers too which is why I do not think it’s a good idea.

I’ll just go ahead and mark this as solved, there is not much more than can be said in this thread.

Have a good day,

For anyone who finds this, I believe you can send a report to [email protected] since author falsely marked this as resolved while his plugin did indeed infringe the guidelines. Pretty sure un-dismissible advertising admin notices is against the plugins guidelines.

Anyhow, I personally uninstalled the plugin and coded a small snippet alternative for my own use.

Just leaving this here for anyone who looks up the issue.

Thank you for your response and quick action, I had manually commented out the code prior to your comment.

Regardless, thank you for taking the time to look into it, keep up the good work!

EDIT: I do not see any new versions uploaded to wordpress SVN, if you’re fixed something kindly push the update so everyone can enjoy it.

I would assume it’s an issue with nonce if it was really intended to be dismissable, you can start looking there.

• This reply was modified 4 years, 1 month ago by Ward.

The issue is solved by this commit:

https://github.com/facebookincubator/facebook-for-woocommerce/pull/1676/commits/e661a0fd779c5bf7238a81159b51d70ca78330aa

I manually implemented the change into my website, you can do too until the next version is out.

This is the culpirt code:

if ( empty( $value ) ) {
			// Check normal product attributes
			foreach ( self::get_available_product_attributes( $product ) as $slug => $attribute ) {
				if ( strtolower( $attribute->get_name() ) === $key ) {
					$value = $product->get_attribute( $slug );
					break;
				}
			}
		}

I can confirm this, using google product categories breaks sync by triggering the above error.