Michael Samson

To anyone reading this, I have also discovered that the Elementor Terms of Service contradicts itself in a way that appears deliberate and meant to deceive.

It clearly states the following at the top of their Terms page:

We offer a 30-day “no questions asked” money-back guarantee for our Pro and Hosting Subscriptions. If you are unsatisfied with those Services, you may request your money back within that time period and cease using our Services. Software you received under the GPLv3 shall remain with you under that license.

It then contradicts this statement further down the document:

We provide a 30-day “no questions asked” refund for new Pro and Hosting subscriptions. Refunds do not apply for upgrades or renewals or other subscriptions.

Not providing any recourse or allowances for refunds in this fashion is likely not enforceable within a contract. Contracts are supposed to be balanced and provide fair opportunity to settle disagreements. Now allowing access to any refunds violates this basic tenet of contract law.

I also discovered that their contract prevents the customers from initiating a class action lawsuit. Since this is in combination with a deceptive practice meant to cheat huge numbers of customers out of small sums of money, it is also likely not enforceable.

On top of all of this, their legal email address ([email protected]) which is cited in their terms is non-deliverable!

Based on everything I have seen this company should be subject to a class action lawsuit. They are forcing subscription renewals on their customers and not allowing any mechanism to recover renewal fees when disputed.

I’m filing a fraud claim with my bank to recover my funds. Again, I highly advise everyone to stay away from this very dishonest and brazen company.

• This reply was modified 1 year ago by Michael Samson.
• This reply was modified 1 year ago by Michael Samson.

@thebaumgartler We were actually using the free version of Yoast at the time. Having random 404s was a terrible issue, and it ultimately pushed us to develop our own SEO solution. I’m fortunate enough to have my own developers.

Yoast is a great plugin, but it is also very large and bloated. This is the case with most all-in-one plugin solutions. It’s not really their fault; they’re simply trying to provide the best tool for every use-case. But all that extra functionality and code can lead to unintended interactions, like these 404s.

When we actually examined what we needed out of Yoast, the requirements were very specific. So we developed our own plugin to meet our exact needs. I should mention this is for a large platform, and we do develop most of our own code. For the common user this wouldn’t be an option obviously.

Anyway, I feel your pain on this one. My guess is this is some kind of conflict. The problem is trying to pin that down. It is probably impossible without Yoast helping directly, and even then will be difficult.

I wish you the best of luck with it!

P.S. Developing your own SEO solution would be my recommendation, if that is within your power.

@thebaumgartler My company isn’t using Yoast anymore. We developed our own SEO plugin. But I’m not surprised to see this issue persists. It is very insidious.

When we were dealing with this we were able to establish that Yoast was the cause by disabling the plugin and retesting. The issue only occurred when Yoast was active. It seemed to occur fairly randomly, and only on certain types of pages. It also occurred with great frequency. In our case the result was always a 404, and not a redirect.

I wish I could share more insights with you. I only know Yoast was the cause, or at the least, the trigger for it.

I hope you can get to the root cause, but it’s probably very difficult to determine.

• This reply was modified 1 year, 8 months ago by Michael Samson.

@zluck @mazedulislamkhan

Love how they keep marking this thread as “Completed.” What a joke.

We were never able to solve this problem. When Yoast was active we had random 404s across our platform, and when Yoast was disabled those 404s disappeared. Yoast was the cause, but we never discovered the reason why.

We’ve since removed Yoast and written our own customized SEO plugin. Tbh we needed to do this anyway as we have particular needs and requirements.

I wish you the best of luck with this!

~ Michael

@msaari

Just wanted to say thank you for your earlier responses.

We were able to get Relevanssi Light working, but after considering several factors (mainly the need for flexibility), we decided to stick with the standard free version for now.

My thanks again for helping us!

~ Michael

Hi Mikko,

Thanks for the quick reply. I’m going to let my engineer (Chandan) reply here shortly. My local is using MariaDB version 10.4.21.

Our development and production environments are setup on AWS using Amazon Aurora. We haven’t tested Relevanssi Light there just yet. We wanted to first see how this would work on our locals.

I happen to know that our Aurora database is soon going to be updated because Aurora MySQL 1 (with MySQL 5.6 compatibility) is reaching end of life soon. So we’ll be using the latest version there.

But we encountered this issue on our locals. Please also note that both of our locals had the same problem. Chandan and I are using two completely different local setups.

I’ll let Chandan speak with you separately to further troubleshoot this.

Thank you again for your help!

~ Michael

• This reply was modified 2 years, 3 months ago by Michael Samson.

@fidoboy

I just wanted to point out that the issue you have discussed above is an entirely different issue than the one my team identified. It really belongs in a separate forum post.

The random 404s this thread is about have nothing to do with the feature in Yoast that removes the categories slug. It’s also completely unrelated to WooCommerce.

I’m mentioning this to help others avoid confusion when reading this post.

~ Michael

@mgnewton Sounds like the identical problem that we identified. I’m glad that our thread here helped to you to know Yoast was the cause. We spent a lot of time testing before we narrowed it down to Yoast.

@mazedulislamkhan From what I can see here, you have a very serious problem in Yoast that is causing randomized 404s for many users. I wish I could provide you with more specific information, but we simply don’t have it. All we can see is the result of this problem; endless random 404s.

We made a decision here as a company to abandon using Yoast completely. Since we have our own development team, we are writing our own code to cover the features we need from Yoast. This problem is simply too big a vulnerability, and we don’t know the intricacies of the plugin enough to find the trigger for the problem. We’re better off not using Yoast and writing our own code.

With that said, I highly recommend you look more into this. Perhaps some of the other users here like @mgnewton can let you into their sites to see the problem directly. This is not an option for us as we have developed a proprietary platform.

Good luck everyone!

~ Michael

@mazedulislamkhan

The publishing software is part of our platform (iazo), which is launching in a few weeks. It’s custom code, and not directly the cause of this 404 issue.

I can ask my engineer about the line numbers he suspected. He’s the person who told me about this.

I’ll get back to you with that information, but I should say this was only a suspicion. Yoast is a large and complex plugin, and we’re certainly not familiar with its code base.

I wish I had better information for you. This 404 issue is really nasty.

~ Michael

@mazedulislamkhan

While this issue does seem to occur at random, we did notice the following:

1. We have a front-end publishing tool, and noticed that the 404s would often occur when a new post was published.

2. In Yoast SEO we found code that led us to believe this was associated with “flushing rewrite rules” more frequently than normally expected.

I don’t know if this will lead to the source of the problem, but it’s all we have.

All my best,

~ Michael

As the originator of this thread, I wanted to say that indeed, this issue has never been resolved by the makers of Yoast SEO. I did not set this thread to resolved (despite it’s resolved status).

Far from it, this same issue persists, even in the latest version of Yoast. In fact, my development team has confirmed Yoast is the cause of these random 404s many times. We have tested this issue and are 100% certain the cause is Yoast. With that said, we were never able to find the exact cause within Yoast.

We run a very large WP site on AWS. It may be this problem is caused by some kind of conflict with another plugin we use, or perhaps something outside WP itself. We just don’t know.

What we do know is when we enable Yoast we get random 404s on our site, with no observable pattern. When we disable Yoast this problem vanishes.

We’ve unfortunately been forced to abandon our use of Yoast and are coding our own SEO plugin. I wish the Yoast SEO authors had taken this issue more seriously. We really didn’t want to give up using Yoast, but we can’t operate our site with random 404s.

If anyone else is seeing this issue, I highly recommend bringing this thread back to the attention of the Yoast development team.

Good luck everyone!

P.S. I was able to set this thread back to unresolved. Maybe it will get some attention.

~ Michael

• This reply was modified 2 years, 5 months ago by Michael Samson.
• This reply was modified 2 years, 5 months ago by Michael Samson.

@stodorovic

I appreciate your willingness to help. Are you associated with the Yoast team?

If there’s a pattern to when the 404s occur, I haven’t been able to see it. It seems to be random in nature, but it happens often. I think it occurs more on taxonomy pages, but it isn’t limited to them if memory serves me.

I don’t typically release the names of our plugins. Many of them we have written ourselves. It’s possible there’s a conflict, but it will be difficult to track down.

We do use BuddyPress, and this is something we can look into on our end. Thank you for sending me the GitHub issues. We’ll look at all of these.

Let me show this to my own team first and then I can report back here when we have new information. There’s definitely something strange going on.

~ Michael

Hello,

This issue is not solved. One of our developers who had found some of the responsible code wasn’t able to locate it again. He spent some time looking but couldn’t find it.

I do not believe this issue has anything to do with our infrastructure. To be honest we have no idea why this is occurring. We only know that Yoast is the cause. It also isn’t practical for us to test Yoast by itself in a default WP setup. We can try conflict testing more, but that’s all we can do.

At this time we’re working on a number of big projects, and while this issue is important to us, we need to return to it later. There’s a strong chance we’ll have to abandon using Yoast completely if we cannot find the cause.

As I mentioned, one of our developers did find some responsible code (directly in Yoast), but then wasn’t able to find it the second time. We’ll try to relocate that and will report it here. But we need some time to get back to this.

~ Michael

Hi Michael,

I have my own development team and we have identified a possible cause of this problem directly in Yoast SEO. I should be able to provide you with this within the next 24 hours.

There are no errors produced when these 404s occur. It is extremely difficult to diagnose, as you said. However, we do not believe it is a conflict. I was informed yesterday of a possible cause directly in Yoast. I’ll send that over as soon as I have it.

All I ask is that you please relay this information to your development team so they can resolve the problem in Yoast core.

I’ll be in touch again shortly…

P.S. We are not using the remove categories prefix feature. So it’s definitely not that!

~ Michael

• This reply was modified 3 years, 4 months ago by Michael Samson.

Hi Suwash,

Thanks for getting back to me about this problem. I’ll answer your questions one by one.

1. Yes, we are using the most recent version of Yoast SEO, and always have been. This problem has been unchanged now for months despite always having the latest version of Yoast.

2. All of our software is fully up to date, including WP core, all plugins, and themes. We write most of our own code.

3. We’re running the latest version of WP core.

4. Yes, we meet all of your basic plugin requirements.

5. We have spent months troubleshooting this problem and do not believe it is a conflict at this point. In fact, we permanently removed several other plugins as part of this process that we felt may have been contributing to the problem. Ultimately this was how we discovered Yoast was the source.

Because the 404s occur randomly, it isn’t the easiest to test for. Sometimes you see a lot of 404s in a row, and other times you don’t see them at all. But the problem occurs very regularly (about 25% of all page visits).

Through lots of testing we found that when Yoast is disabled the problem completely goes away. We confirmed this by having Yoast disabled for weeks in our development environment. During that time not a single 404 was encountered. Literally the day I reactivated Yoast the 404s all came back.

I suspect this problem may be related to how Yoast functions in our infrastructure on AWS. We are not a typical use-case. We have a large platform in development and it uses a sophisticated infrastructure stack at AWS. This includes use of Docker, Cloudfront, and several other AWS services. I can only speculate here, but perhaps there is an issue with Yoast in AWS environments.

We have recently updated our php version as well and have been checking for all php related errors and correcting them. The php update did not resolve this problem.

…..

Have you ever seen this kind of behavior with Yoast before? Are you aware of any specific plugins that may cause a conflict like this? If so, I can check against our plugins. But at this moment I really don’t know what the cause is.

I welcome your thoughts…

~ Michael

• This reply was modified 3 years, 4 months ago by Michael Samson.