Yoast SEO not work, google sitemap have forever error .loc

[w3b]

What issue or error are you experiencing?

I keep getting Yoast SEO won’t activate in debug mode, who even came up with this? if sometimes you need to make a standard static site, and it turned out to be half functional after switching to a locale. Why do you need to read kilometer manuals, how to turn it off, how to turn it on. To spoil such a good product with such ridiculous restrictions, honestly, there are no words.
There is also an error when I add the site map to Google, it says that there is an error.loc
I switched from openserver to this platform in the hope of getting everything better and easier, if I don’t find a solution to the problem with sitemaps in the near future, I will be forced to return to openserver and leave the lock forever.
You really need to be able to make such a cool product in the middle with such ridiculous restrictions!
Ubuntu+nginx+php 8.1.2.3+mysql 8

[Nick-B]

Hi @w3b

We may need some more clarification about your workflow and what errors you’re running into.

I keep getting Yoast SEO won’t activate in debug mode, who even came up with this?

Is this a Local error or something specific to Yoast SEO? Have you looked through their documentation or contacted them about this? Feel to share a screenshot.

if sometimes you need to make a standard static site, and it turned out to be half functional after switching to a locale. Why do you need to read kilometer manuals, how to turn it off, how to turn it on. To spoil such a good product with such ridiculous restrictions, honestly, there are no words.

I’m not sure what’s “half functional”. Is this because of the Yoast error? What restrictions are you running into?

There is also an error when I add the site map to Google, it says that there is an error.loc

Can you share a screenshot of the Google error?

I switched from openserver to this platform in the hope of getting everything better and easier, if I don’t find a solution to the problem with sitemaps in the near future, I will be forced to return to openserver and leave the lock forever.

To be clear, Local is not a “platform” or a “webhost”. This is simply an offline development tool for building and troubleshooting WordPress websites. It is not meant to be a web hosting solution.

[w3b]

In order to see the entire list of errors, install Yoast SEO, Simply Static, generate a static site with direct links and see how many parcels there will be, you can analyze and eliminate them. Everything works, the only thing that does not work correctly is the Yoast SEO plugin.

Tomorrow I will try to describe the entire list of errors in as much detail as possible

[Nick-B]

Hi @w3b

We would love to see more detail about the errors you’re running into. Was this a site that you imported into Local or were you trying to build and test a new one from scratch to take live to a host or your own server?

[w3b]

Ubuntu 22.04
LocalWP 8.3.1+6650
Nginx
PHP 8.1.23
MySQL 8.0.16
On a cleanly installed LocalWP, I installed Wordpress Wersion 6.4.3 from it, which is the default, after which I installed themes and necessary plugins. The first plugin with which the problem arose is Yoast SEO, by default it is deactivated in LocalWP, the rationale for the error does not work in the test environment. This problem occurs because every time the environment (*.domain.name) is started, the entry define( ‘WP_ENVIRONMENT_TYPE’, ‘local’ ) appears in the wp-config.php file; removed the entry as follows in the directory of the activated theme in the functions.php file, added the following line add_filter( ‘Yoast\WP\SEO\should_index_indexables’, ‘__return_true’ ); search engine optimization was turned on and Yoast SEO started indexing the pages, but there were errors with the indexing of the sitemap, I have not yet dealt with this problem. Because there are no errors in the debugger about the .loc error. So, the question is how to disable the automatic addition of an entry to the configuration file (‘WP_ENVIRONMENT_TYPE’, ‘local’) in the desired environment; and in another environment you can leave it.

it would not be bad to add an independent choice in the next versions, whether the author wants such records to be automatically generated in the configuration files or not, a toggle like SSL certificates, would be very cool.

Also, by default, when LocalWP starts a session, it generates domain records in the /etc/hosts file, and when it ends the session, it does not delete these records, I am not talking about all of them, but in my case it creates difficulties, if I create a site for a client, I immediately create a domain locally 1 in 1 with the client and so that in the future there will be no errors with plugins, themes and other settings. Next, I give access to the local server and when everything is in order, I transfer it to the network. On the open server, this function works by default, which is very useful, since even after disabling LocalWP, I cannot access domains in the global network until I delete the generated local hosts.

I also have another question about entries in the nginx configuration file, but I will write this question tomorrow, I will formulate it more correctly.

Overall, your product is the best of all! And I checked them, probably all of them that just now exist. A couple of small additions to the functionality will be make your app better in the world

[nickc]

So, the question is how to disable the automatic addition of an entry to the configuration file ('WP_ENVIRONMENT_TYPE', 'local') in the desired environment;

After Local writes this to your config file, you can edit your local wp-config.php to change it to a value other than ‘local’. For example, try setting it to the default of production. As long as that environment variable exists, Local should not add it again or override it. (The reason Local adds it by default is to stop ecommerce plugins and plugins that generate emails from behaving like a production site, which can have bad side-effects.)

when LocalWP starts a session, it generates domain records in the /etc/hosts file, and when it ends the session, it does not delete these records

Correct, and this is by design. With Local’s current security model (it always asks before it writes to your /etc/hosts file), if Local deleted /etc/hosts entries on stop, it would have to ask for permission to write the records to /etc/hosts again every time you restart a site. This would become annoying for the majority of users (who use Local’s default domain of .local instead of mirroring their local domain with their live ones as you describe).

In your workflow where your domains in Local match the live ones and you need to be able to remove the host entries locally to see the live sites, one solution is to write a small shell script to temporarily remove Local entries from your hosts file (by backing it up to another location, for example).