🇷🇺Russia @walkingdexter

walkingdexter → created an issue.

walkingdexter → created an issue.

The sitemap protocol still contains <priority> and <changefreq> values.

Closing due to lack of activity.

Closing due to lack of activity.

This feature conflicts with ✨ Override a non-indexed bundle on a per-entity basis Needs work and therefore cannot be implemented.

walkingdexter → created an issue.

Fixed errors and merged, thanks! We can't use autoconfigure for now because it would break backwards compatibility.

walkingdexter → made their first commit to this issue’s fork.

Merged, thanks!

walkingdexter → made their first commit to this issue’s fork.

Just realized that this is a duplicate of ✨ change sitemap.xml?page=1 to sitemap1.xml Needs review .

My current thoughts:

• In this issue we should focus on adding the ability to act on a processed entity. I propose to move the event subscriber (or hook implementation) to the Rabbit Hole module by creating a separate issue. Otherwise, I don't think it's right to drop support for Rabbit Hole 1. It's stable, and we'll have to support both versions.
• The discussion about events and hooks is relevant again because of this change record → .
• The proposed code must use all possible type declarations.
• All warnings from the CI pipeline must be fixed.

When a developer decides to use DATE_ISO8601, he will see that DATE_ISO8601 is deprecated and DATE_ATOM should be used instead. However, the <lastmod> date can be formatted in different ways and ATOM format is not the only option.

@introfini Sorry for the late response. All you need to do is add a custom submit callback to the node form and change the $form_state values related to the sitemap settings before they are saved.

There is no need to divide sitemaps by language. You can simply divide them by content type. URLs for other languages will be automatically included.

The sitemap page itself is not supposed to be indexed. See related issues for details.

The sitemap page itself is not supposed to be indexed. See related issues for details.

This looks like a feature request.

@damienmo The following may help you:

1. Set the "Maximum links in a sitemap" limit or reduce it if it's already set.
2. Turn off the "Exclude duplicate links" feature. With large numbers of links, this feature will lead to heavy SQL queries and memory issues.

If that doesn't help, try to find out what the largest data is.

Merged, thanks!

@handkerchief In your scenario I still get the 404 error. Can you provide more details on step 3?

• Is the Content Translation module disabled?
• What settings are set on /admin/config/regional/content-language?
• What settings are set on /admin/config/regional/language/detection?

I tested the following scenario on a clean install with 4.x-dev:

1. Enable two languages ​​- English and non-english.
2. Set English as default language.
3. Use the "Selected language" plugin for language detection and configure it with a non-english language.
4. Enable content translation for the "Article" content type.
5. Add a new node of type "Article" and translate it into a non-english language.

Now when I set a URL alias for the created node, I get a 404 error if the alias has a non-english language. If I change the alias language to English or unspecified, then the 404 error does not occur. The sitemap is also correct in this case.

So I can't reproduce the problem on a clean install. Maybe I'm missing something. Feel free to reopen if you can provide more information to reproduce the problem. In other cases see #4 and #5 for possible solutions. Also consider changing the URL alias language.

Merged, thanks!

I can't reproduce the problem from #4 - different sitemap results for different languages. This has probably been fixed in other issues. Speaking about the original problem, the proposed resolution is incorrect. If I understood the example correctly, then https://www.drupal8.loc/de/OeffentlicheSeite and https://www.drupal8.loc/en/node/401 are the URLs of the same node. In this case, the specified result is expected. This is exactly how the "Skip non-existent translations" functionality is designed.

Just tested, all bugs reported here have been fixed in 🐛 Unexpected language prefixes on sitemap index Fixed

@hmendes Instead of a class, you should use an interface.

walkingdexter → created an issue.

Simplified and committed, thanks! Thoughts from #21 are respected. Credits saved for the guys from ✨ New permission to only edit entity sitemap settings Needs review .

@selinav Sorry for the late response. There is currently no way to specify the date of last modification for views pages without custom code. However, I assume that this feature will be added one day. One possible approach is to get the date from entities that are displayed in a view.

@cosmicdreams This error is not related to the Simple XML sitemap because the ext-xmlwriter requirement is explicitly specified in composer.json. Also note that this PHP extension is enabled by default. If it was previously disabled, then it must be enabled again.

@_renify_ Please provide more information about the proposed changes. Are you looking for a way to add views pagination pages to your sitemap?

@_renify_ Please provide more information about the proposed integration.

Oops, just realized that we already have an issue for this.

@berdir Thanks for the issue!

@gbyte I think the whole code in \Drupal\simple_sitemap\Manager\EntityManager::setBundleSettings() after $bundle_settings->save(); should be removed.

• There is no reason to delete entity overrides in case bundle indexation is disabled. User can re-enable bundle indexation and overrides will be needed again.
• There is no reason to delete entity overrides which are identical to new bundle settings. User can change bundle settings and overrides will be needed again.

We also have a potential performance problem with \Drupal\simple_sitemap\Manager\EntityManager::removeBundleSettings() but this is a rare case. Also this shouldn't be a problem after closing #3034070: Store entity instance settings as fields on entity → .

Already fixed in 📌 Fix PHPStan errors Fixed , see this commit for details.

I can't reproduce the problem on a fresh install (did a quick debug for the views exposed form). According to the error trace, the problem is related to starting a new session at the end of the request. This can cause many problems and not only for this module. Feel free to reopen if you can provide additional details.

walkingdexter → created an issue.

The post_update hook was used for a reason 🐛 Update from 2.x or 3.x: Export does not get imported Fixed .

See 📌 TypeError: Argument 1 passed to Drupal\simple_sitemap\Form\Handler\EntityFormHandlerBase::isSupportedOperation() must be of the type string, null given Closed: works as designed for details. Feel free to reopen if you can provide additional information on how to reproduce the problem.

It looks like we have a problem with multidomain/multilingual installations. However, the proposed resolution doesn't seem to be the best choice in my opinion. I need a second pair of eyes here.

Closing as per lack of activity. Feel free to reopen if you can provide more details about the problem.

Closing as per lack of activity.

I'm not sure this change is necessary. A similar result can be obtained by overriding the simple_sitemap.form_helper service in your custom module. But let's take a second opinion.

Added BC layer and committed, thanks!

Deletion of translation entries for taxonomy.

@catcat811 I can't reproduce the problem with these steps. Please provide more details.

Please review the attached patch.

@ananya.k Your patch doesn't fix anything.

Is there any loss to be had adding a sanity check here besides a milisecond or two of time?

I'm not a fan of adding unnecessary checks that go against the documentation. Incorrect implementation can lead to errors not only with this module. The above case clearly shows that the problem is related to the third party.

I don't think it's fair to say that getOperation() returning NULL is a third party problem, since getOperation does not specify return types.

@jnicola The return type is specified in PHPDoc, which is respected by PHPStan.

The proposed resolution broke the script, as @benjifisher noted. All we need here is to make the parameter required.

Merged, thanks!

At the moment I don't see any suitable native alternative to jQuery TableSorter with similar functionality, especially in terms of accessibility (ARIA). Postponed for now.

I am not a fan of increasing MINOR when adding functionality as it seems to create a fork and two versions to maintain, correct?

There is no need to maintain two versions. We just increase the minor version and move on.

In addition people stay on the previous version forever as they often have something like "^4.3" in composer. What are your thoughts?

This always allow non-breaking updates. ^4.3 means >=4.3.0 <5.0.0.

Also in regards to the upcoming release - we bumped compatibility from D9.3 + D10 to D10.2 + D11. What would be your preferred new version number?

According to https://www.drupal.org/project/ideas/issues/3357742#comment-15651225 🌱 Guidelines for semantic versioning and Drupal core support Needs review , I prefer 4.2.0 version (increase the minor version).

We are approaching the release of Drupal 11, so should we expect stable version for this module before that release?

I don't have permission to create new releases. Only @gbyte can do this.

WalkingDexter → created an issue.

FYI 🌱 Guidelines for semantic versioning and Drupal core support Needs review

Already fixed in 📌 Automated Drupal 11 compatibility fixes for simple_sitemap Needs review .

WalkingDexter → made their first commit to this issue’s fork.

Already fixed in 📌 Automated Drupal 11 compatibility fixes for simple_sitemap Needs review .

WalkingDexter → created an issue.

WalkingDexter → created an issue.

Merged with changes and additions, thanks! Also dropped support for Drupal 9. All credits saved.

WalkingDexter → changed the visibility of the branch 3434566-d11-ready to hidden.

WalkingDexter → changed the visibility of the branch project-update-bot-only to active.

Merged, thanks!

Closed due to lack of activity.

This feature cannot be implemented in a general way for arbitrary links, #6 is the best solution.

Closed because 3.x is unsupported. Feel free to reopen if the problem is present in 4.x.

Closed due to lack of activity.

Closed because 3.x is unsupported. Feel free to reopen if the problem is present in 4.x.

Closed because 3.x is unsupported. Feel free to reopen if the problem is present in 4.x.

I still see a lot of unnecessary changes that are not related to the issue. Please explain why these changes are needed. In my opinion, the only changes we need here are the changes that Project-Update-Bot suggests. Also we cannot rely on DeprecationHelper as it's available since version 10.1.3 (see the change record → ). We must either drop support for Drupal 9 or implement a workaround.

WalkingDexter → made their first commit to this issue’s fork.

The changes made break the value options. Attached the correct patch.

I'm not sure about these changes:

• https://git.drupalcode.org/project/simple_sitemap/-/merge_requests/90/di...
• https://git.drupalcode.org/project/simple_sitemap/-/merge_requests/90/di...

They need to be carefully reviewed. At least there is no need to change the file mode. Additionally, any errors from the validate step should be fixed.

These phpcs violations should be fixed in 📌 Automated Drupal 11 compatibility fixes for simple_sitemap Needs review . I also see a lot of unnecessary changes (like file mode) and ignoring the current phpcs configuration.