lookingahead

aww, thank you for that! you’re the best. ??

Oh hi there @wfasa

Why do you keep telling me it’s not a problem when my host says it IS a problem?

No, I’m not worried about being ‘friendly’ here — you’re not getting my meaning and so I have to be SUPER CLEAR. If you take offense to that that is an error on your part. I’m being exceptionally blunt in hopes that you’ll FINALLY get my meaning.

But apparently you either are unwilling to hear what I have to say or unable to hear it. That’s bothersome. And that just draws out conversation and leads to nothing getting done.

If you had told me from the beginning that the option no longer existed to disable cookies, not anywhere…then I could have solved my issue sooner.

Now, I’ve wasted time trying to re-state my issue over and over again, in hopes that you’d finally ‘get’ what I’m saying. To find out if Wordfence will allow users to disable its use of cookies.

Now, you tell me that there is not a way to disable cookies, not in any way.

That’s not good.

The problem isn’t WHERE Wordfence uses cookies — it’s that they use cookies at all.

Again — this is what my host confirmed. It is not a ‘guess’ or a ‘maybe’ — and it is not a problem, lol, with a particular cookie.

And again, I’ll state that this is a problem that Wordfence has known about for years — that’s why the helpfile I linked to at the start of this post existed. Because it was, and is, a known problem. But for some ungodly reason, Wordfence chose to take that solution away that they developed….WHY IN THE WORLD they’d do that, I have no idea.

It’s still a problem.

And for some reason, you’re trying to deflect blame for Wordfence un-solving a problem that the Wordfence plugin is known to cause. Just admit Wordfence made a very bad decision to take away that option for us to solve their incompatibility with managed hosting/CDN caching…and let them know to fix it, please.

Because at this point, all you’re doing is giving me “explanations” to a problem that is not the actual problem.

The problem is not “we disabled cookies on the front end, so all should be okay!”….the fact that you took away the ability for users to turn off your use of cookies is the problem, not, lol….the fact that cookies were used on the front end.

It’s that Wordfence uses cookies, takes them away from the host’s/CDN’s cache system. SO that renders it inoperable.

Front end cookies vs. back end cookies? IRRELEVANT.

And your, lol, taking them away on the front end is not a solution; it is possibly even a detriment.

Wordfence cannot take control of cookies over the site’s host taking control of cookies for its caching system. It’s just not gonna work. So we need to STILL have that option to shut them off.

Capesh?

AND HOW do I know that disabling all Wordfence cookies is STILL a valid solution….?

Well!

I went ahead and restored an older copy to my site; the only difference being the Wordfence plugin being from when you could still disable cookies….juuuuust like your own helpfile says to do.

And guesssss what?

My host no longer says that their cache is disabled because of Wordfence using cookies. Of Wordfence taking control of cookies away from my host’s cache system.

It’s Wordfence’s issue. One they knew about for years. One that they even went so far as to write a help page for it, to have users resolve it.

Why in the WORLD would Wordfence take away a solution from users? While not solving the problem on Wordfence’s end — the problem being that Wordfence battles with a host’s caching system, takes its use of cookies away from it…and renders that host’s caching UNABLE TO WORK AT ALL…??? This ‘cookie battle’ is a known problem, again……one that Wordfence has known about for years. It’s not like we can ‘uninstall’ these caches. We depend on them to keep our sites functional. And since I can’t uninstall my managed host/CDN’s caches, and DEPEND on them to have my site remain FUNCTIONAL…I have to either use an older copy of Wordfence where they STILL allowed us to solve the issue, lol…or upgrade to a version of Wordfence that no longer allows users to solve this issue.

You know how super not-intelligent that is of Wordfence to have done? How incredibly non-productive, non-helpful, and non-wise it is? It renders Wordfence USELESS.

SO for now, I’m using an old version of Wordfence. And looking at other security solutions as a result.

Great job on castrating your own plugin. Wonderful.

Please find a fix for this — I mean, seriously….give us back the option to disable cookies in the upcoming versions OR get your program to play nice with host caching/CDNs.

At the very least, if you’re gonna take control of cookies away from my host and render its caching system useless, then give us a warning. Say that Wordfence is no longer compatible on managed hosting/CDN plans.

Because it isn’t.

And that’s the truth.

And lol, no….Wordfence did NOT solve anything by taking cookies away from ‘the front end’…LOL omfg. It’s that Wordfence uses cookies. Period. Doesn’t matter where it uses them, because it always uses them like a greedy child. And doesn’t allow anyone else to use them.

Fix that, and you’ll have fixed the issue Wordfence KNEW ABOUT FOR YEARS and has now no longer allowed users to rectify. LOL YOU WROTE A HELP ARTICLE ABOUT IT, hahaha…..this is NOT NEW NEWS.

FFS.

omg please fix this ASAP, lol….i need this to tame my wordpress

please please please ??

thank you

I think you either misunderstand my issue or you are attempting to not answer my question, @wfasa.

It’s not a ‘name of a cookie’ — the hosting provider SPECIFICALLY NAMED THE WORDFENCE PLUGIN as using cookies and needing to disable its use of cookies. Not one cookie. All of YOUR use of cookies.

Tell me how. Please.

If there is no way to get your plugin to stop using cookies — which according to their analysis IS STILL happening — then your plugin will continue to conflict with my host.

Your plugin.

Your plugin’s use of cookies.

Tell me how to stop your plugin from using cookies, please. Thank you.

You’re welcome, @wfasa!

So……..my host is still telling me you’re using cookies which is preventing my host from caching.

Apparently SOMEHOW there is a use of cookies — you said “front end” so perhaps you’re still doing it on the backend?

Still need to turn your use of cookies off.

How?

thanks for the response, @matteomanna!

yep, it does; it’s like an evil island that dictates to the world — it takes preference in loading order over wordpress avatars and buddypress avatars, lol…

what i’m wondering….is this:

1.) is there any way to get the hierarchy of loading order to be wordpress’s avatar, then to export that avatar to buddypress? and get buddypress to wait for the avatar from wordpress to show, then to use the wordpress avatar as its own? bbpress does this, and i’m trying to do something similar in buddypress….

2.) if THAT isn’t possible, then this: is there a way to get buddypress to allow avatar uploads from the backend?

at this point, i’d probably want to see a plugin that allows a user to change the avatars from the backend in buddypress — specific to a user. via maybe user id. via maybe by using just raw code that i could put into a plugin template (php file), then upload it to my own plugins folder on the backend, and edit it whenever i wanted to edit a user’s buddpress avatar.

any idea how to achieve either?

ever thought of making a plugin like the one i describe in the second idea? ?? ((hint hint))…hehehhehh…. ??

P.S.: i need to redirect all 404 pages AND STILL be able to redirect other pages that are not 404 errors to wherever i want them to be…

so i need:
– a way to make all 404 errors go to the home page
– to still be able to enter in other redirects for various reasons, and not be restricted to using the plugin SOLELY for 404 redirects

thanks in advance for you helping us out with your fab plugin, @10up

cc: @danielbachhuber | @tollmanz | @jakemgold | @tlovett1 | @taylorde

@10up do you have any idea how to do this?

i’m looking for a way to redirect all 404 errors to the home page too….please let us know how to do that

THAT DID IT!!!!!!! <3 Okay, this is fantastic. Giving you a 5-star review now!

I used that code and made it into a custom plugin…which is always fun to do. I think that’s ok to do with this code, right? So far I’ve tested it and it’s all good.

And the phenomenal thing about this code snippet is that I, as a Keymaster, can still view my own profile — even though other users below my level cannot view their own profile. Which was also something I needed, but your code is so good I didn’t even have to ask for that!

Thank you, so very much. I am deeply grateful.

I hope you have a wonderful, wonderful day. <3

Same for me.

In fact, NOTHING I changed in BBPress Toolkit has worked. Nothing.

So incredibly disappointing.

@stantinv sadly your assumption that it is a “parent product (without selected options) into Wishlist from a product listing page” appears to be incorrect.

I’ve tested this, and this is not a YITH issue, nor are these ‘parent products’ that generate that message.

I myself am using WooCommerce Wishlist with single sale items. They have no additional product options, either. Now, there is one element here that nobody else may have noticed: this error message (for me, at least) appears ONLY when I try to add a product to the cart that is already IN the cart. It doesn’t appear at any other time. I select ‘add selected to cart’ for a product that is already in the cart, and that is when this message appears — right under the message telling me that I can’t add another of the same product to cart (which is a message that needs to be there)……

And please note: I’ve been trying to do dumb things to test the site, to see how plugins would react and what error messages they’d throw up. I have done this same test before in previous editions of WooCommerce Wishlist, and that message has never appeared.

Fwiw I’ve used a plugin to find where this code is located, and it’s in your plugin…not in other plugins, and not in WooCommerce. So it’s generated from inside your plugin.

The version of the message I get: Product “Favorites” could not be added to cart because some options are not specified. Please, select some product options before adding the products to your cart.

If anyone else wants to find this string, search from the word “could” and beyond — you can’t copy the words before that because they are going to change based on the thing it is that it is telling the viewer. Strangely it is not saying the EXACT product name — it’s calling my product “Favorites”….which means to me that it’s telling itself that itself cannot add an Favorites list item….again, it’s a bug within the WooCommerce Favorites plugin side. That behaviour of the error message calling my product “Favorites” (and not its single product name) tells me that its conditional logic is screwy. And not due to a plugin conflict.

@deanmkd please see this thread:

https://www.ads-software.com/support/topic/error-wishlist/

P.S.: this is happening with the latest edition of your plugin.

And again, I’ll stress — this is not a plugin conflict as you first assumed. It’s a problem with your plugin recognizing the qualities of the products added from the Wishlist plugin to the cart.

I noticed in another thread here that the user was using the YITH plugin, and had the same issue. I believe you thought it was YITH related, and then this latest update covered that. That’s great.

But it’s not limited to merely YITH users. I’ve deactivated EVERY other plugin except WooCommerce and your plugin, and this message appears — again, only when I try to add a product to the cart from the wishlist that is already IN the cart. It for some reason behaves appropriately and says that I cannot add another “(insert product name here) product” to the cart, which is great. But then it adds that additional message.

I have tested your plugin like this before, in previous editions, and that message telling me about product options NEVER came up before. So, this must have been added or adjusted within the last 5 updates or so.

Thanks again in advance for fixing this issue on your end in the next update.

I do not have that plugin — “WC Fields Factory” — and this is not an issue with other plugins acting as a conflict.

That message is generated from the WooCommerce Wishlist plugin itself.

I’ve used a plugin by the name of, “String Locator” to find this message, and it came up as a message buried within your plugin. This message in your plugin is located on lines 298 and lines 413. In the “wp-content/plugins/ti-woocommerce-wishlist/public/wishlist/buttons.class.php” file.

The only time I see it come up is when I choose “Add Selected to Cart” and that item is already IN the cart. Otherwise it does not appear. I’m trying to “break” my site and do things that are “forbidden” by plugins to test what happens, and that is when I saw this message come up.

Granted, it’s only appearing when a user tries to add a product to the cart that is already IN the cart, but still. It’s confusing as hell, and it isn’t even an appropriate message for my product type. They are all single sale items.

So no, this is not an issue that is, as you first said, “The issue may appear if you are using some additional Woo add-ons. There are hundreds of WooCommerce addons on the web that allow to use custom meta data. Unfortunately there is no global solution to make our wishlist compatible with all of the other plugins. In most cases it requires integration of these plugins from our end.”

And if you DO support “all WooCommerce types” as you stated, then you should be able to support single sale items. There are no additional “options” for these items, so having the plugin tell customers they need to select additional items is not correct — so that message should never appear.

Please fix this in your next update. Pretty please. Thank you.

thanks for the response, @robin-w

here’s the link to the topic from 8 months ago that i was referring to:

https://www.ads-software.com/support/topic/topics-can-still-be-viewed-with-the-link/

and i found another with similar issues…this one:

https://www.ads-software.com/support/topic/private-groups-leaking-via-rss/

it looks like both threads cover security issues, and there is information left out at the end…don’t know if this is still a potential issue or if both cases were solved and the security vulnerabilities were shored up….