@aaron.ferris
This is a support ticket still - I'd like to hear from the maintainer. Your MR won't work properly as Stripe expects the last two digits to be the cents value, so 1234 will be 12,34 instead of 1234. The stripe field does not accept floating point numbers so there are more things to do here anyway. Just checking with the maintainer what the overall goal is and I'm happy to share my work afterwards.
Did you try your steps above to reproduce? Drupal\simple_sitemap\Entity\SimpleSitemap is of type SitempInterface so this error should not be a thing. Please check if you have updated the module correctly.
@gbyte, well actually we don't need the patch anymore, because I rewrote our code to deal with the queue differently.
Ah got you - it's your plugin that you rewrote. I was asking for a patch because I was under the impression you were referring to one of the default plugins (which I remember have not been storing entities in the queue for a long time).
A postupdate should be implemented.
Yeah maybe that's what we should be doing - feel free to create an MR. Alternatively adjust your deployment so it cleans the cache which has been the recommended approach since I can remember. I'm surprised your site doesn't break after every update.
Also please open up bug reports against the dev version of the module and only support requests against the stable version.
I may be wrong but your deployment might have been at fault - state was indeed replaced by the key/value store and the error you are getting may be due to a partially old code base or some cache. Please retry the update, run `drush updb -y && drush cr` afterwards and let me know if the modules works.
@kriboogh Please provide a merge request with your changes.
MR is ready. If you like it, I wouldn't mind being granted maintainer status for this project as I intend to use it in many of my projects and it clearly needs more love.
I'll create a MR later if required.
Thanks for bringing this to my attention, should be fixed now.
That does make sense, I'll look into it.
I fixed the documentation issue of the nomenclature sometimes being 'sitemaps' and sometimes 'variants' and explained using the sitemap index some more. Sorry for not using your MR - I find the structure a bit hard to follow.
@Jons I will be creating a release soon, as soon as I feel the dev version has been tested by the community. I don't think however not having a release should stop you from doing whatever it is you are doing, as you can just remove the google engine directly from the active configuration.
The generator should have its own interface 'GeneratorInterface' and additionaly implement the existing 'SitemapGetterInterface'. 'GeneratorInterface' should not extend 'SitemapGetterInterface'.
Closing support request as fixed.
Closing support request as fixed.
Sorry for the late answer, I missed this support request twice apparently. :(
It's possible to have external links to sitemaps in a sitemap index type of sitemap. Here is how:
- The simplest approach would be creating a new sitemap type via UI with "Sitemap index generator" as sitemap generator and "Arbitrary URL generator" as URL generator.
- Then create a sitemap of this type.
- Now implement hook_simple_sitemap_arbitrary_links_alter() and add the URLs programmatically. Example:
function hook_simple_sitemap_arbitrary_links_alter(array &$arbitrary_links, SimpleSitemapInterface $sitemap) {
// Add an arbitrary link to all sitemaps.
$arbitrary_links[] = [
'url' => 'https://some-arbitrary-link/',
// An ISO8601 formatted date.
'lastmod' => '2012-10-12T17:40:30+02:00',
];
}
There is of course also the cleaner way which is to implement a URL generator plugin yourself and using that instead of using the arbitrary link plugin. I hope this helps.
Closing this support ticket as fixed.
The simple_sitemap_views submodule should clean up after itself. Wondering if we should put in additional checks and throw a warning instead of an exception. I'll look into it.
gbyte → created an issue. See original summary → .
This is a support request that's been solved and not a feature or bug ticket. Even if it were one, it wouldn't be a duplicate or won't fix.
@YevKo thanks for the patch. It should not be necessary however, as we already do it inside SimpleSitemap::toUrl.
Can you double check if in fact your patch works?
I'm closing this support request as fixed. If you don't mind, please create a new task issue with the documentation tag and create an MR instead of a patch. This massively helps reviewing and commiting.
Having a setting that breaks one thing in order to allow something else is not an ideal situation. We turned off path processing in order to remove language prefixed paths. Instead of having two half-solutions, we should find a way to disable these language prefixes without breaking aliases. I'll be honest with you, it will have to be a quite clean solution to land. If you are still willing to look into it, thanks and good luck! Otherwise, this is quite niche so it's not at the top of my priority list.
This should be a non-issue if ever we implement #3034070: Store entity instance settings as fields on entity → . Postponing until then.
I have no knowledge of the internal workings of the diff module, but sitemap entity overrides are not stored as entity fields. Instead they are stored in a custom table "simple_sitemap_entity_overrides". I assume what you are asking will work when (if) #3034070: Store entity instance settings as fields on entity → gets implemented. Let me know if this needs more clarification.
Which "XML sitemap fields" are you referring to exactly? Can you provide a screenshot?
Sitemap paths are not your regular paths. They are purposefully not normalized (you can't visit a localized version of the path) and there has never been a plan to support aliases. Since sitmemaps are supposed to be ingested by bots, their URLs don't matter to most.
I haven't had a look, but how are you adding the aliases BTW?
I don't plan on testing and implementing this, but feel free to try convincing me by creating a merge request.
As with close to all the issues you've ever submitted, I wouldn't classify this as a bug from the get-go. XD
What you are asking is possible. Have you read the documentation?
SITEMAP VARIANTS
It is possible to have several sitemap instances of different sitemap types with
specific links accessible under certain URLs. These sitemap variants can be
configured under admin/config/search/simplesitemap. The module comes with the
default sitemap 'default' which is accessible under /sitemap.xml by default.
There is also the 'sitemap index' variant which is disabled by default and which
can be used to index all other variants. If there are multiple sitemap variants
it may make sense to enable the sitemap index variant and make it available
under /sitemap.xml by setting it as the default variant in the module's
settings.
Let me know if this helps.
On a side note, I know I mentioned it a few times to you, but it makes sense to create support requests if unsure if a bug or feature exists. Also when creating bug or feature tickets, it doesn't make sense to tag a stable version of the module. I can't go back and add a feature to a past release - we only work on the dev version.
3.x is unsupported, please test 4.x and tag the issue accordingly if needed. Reverting the issue status.
Finally, Google does not care about sitemap.xml! They track everything, and also report as error the new Drupal robots.txt exclusions! Shame on them!
They do care about the sitemap same as before. They just think they know when you update it without you having to ping them about it.
Uploading screenshot of what I'm understanding are the recommended settings to, again as I understand we should have to
You got it and your settings are fine.
Thanks for the ticket. I will be pushing an update forcefully disabling sitemap pinging for Google. Until then it can be disabled via UI here: /admin/config/search/simplesitemap/engines/settings.
Google just stopped supporting the sitemap ping protocol. Bing did the same a while ago, but they use an alternative - IndexNow (similarly to Yandex). Thankfully Google claims you don't need to submit your sitemap anymore for it to see changes and if it comes to other search engines, you are covered with this module, as it also supports the IndexNow protocol.
I will be pushing an update forcefully disabling sitemap pinging for Google. Until then, you can just disable it via UI here: /admin/config/search/simplesitemap/engines/settings
See 📌 Google sitemaps ping endpoint has gone away Active .
Let me know if this helps.
Bug reports are to be opened against the dev version of the module. Also, if changes need to be made in the seckit module, what's the reason of putting this in simple_sitemap's queue? I don't get any error in Firefox (not using seckit). Changing to support request until this is clarified.
Yes, I am using domain_simple_sitemap (Domain Access Simple XML Sitemap) already.
Moving to the domain_simple_sitemap queue.
Did you try searching the queue → ? This module does not support the domain_access module yet. You might try your luck with domain_simple_sitemap → .
Also never open bug reports against anything other than the development version of the module. The bug you are reporting might have been fixed already.
If I understand it correctly, the workflow right now is as follows:
You create a "sitemap type" (config entity) and assign a sitemap generator and one or more url generators
You then create a "sitemap" entity (config entity, also called "variant") and give it an ID, name, description, publication status and type
If you want to create a new sitemap type, you may need to do all of the above. If you only want what most of this module's users do, just use the provided hreflang sitemap and only visit the inclusion tab.
I'm just trying to wrap my head around why this module has "sitemap types" when they seem to serve no real purpose.
I appreciate things may seem redundant or over-engineered but that's because this module, while coming with one hreflang sitemap out-of-the-box, allows creating sitemaps of arbitrary content. To be able to do that, it needs an API for defining the structure and content of a sitemap. Let's take the two default sitemaps as an example:
- The default sitemap is a sitemap of type 'hreflang'. Sitemaps of this type need to look how Google wants them to look - this includes the sitemap structure (defined by the sitemap generator plugin) and the types of links allowed in it (defined by URL generator plugins). We need the sitemap type as there may be many sitemaps served for different purposes. For sitemaps served to search engines, this could mean e.g. image sitemaps or news sitemaps. But there are other use cases; think e.g. of one where a wholesaler serves product price lists to shops.
- If you look carefully, we also ship a sitemap of a different type - the sitemap index (albeit in a disabled state). While this module creates sitemap indexes for sitemaps that need to be split into sub-sitemaps because of their size, there are loads use-cases where a sitemap index is needed to index all or some other sitemaps created with this module.
Wouldn't it make more sense to get rid of types altogether and select your generators directly on the "sitemap entity" (variant) entity form and perhaps even configure them there?
I've been thinking about allowing to set inclusion settings right on the sitemap entity form, but we already allow doing it in the 'inclusion' tab and on the included enities' forms. Having a third place to do the same thing does not seem to be worth the code overhead. This module is far from its original simplicity as is.
In summary, your observation of the site builder UX being complex is due to this module's abstract and unassuming nature (usually a desired trait in a Drupal module). If you have an idea how to improve the UI/UX without proposing huge architectural changes (they mostly make sense in the bigger picture), please do create a ticket.
Setting to fixed, since it's a solved support request.
All hreflang pages are bundled in one sitemap. For SEO reasons it would be better to use a separate sitemap for each language. In our case: german, english, french.
If you split the sitempas into languages, you don't have hreflang sitemaps anymore. The whole point of this standard (developed by Google) is to combine all language variants of links into one.
but in the settings of the sitemap module still is the "ping" method used
If you are using the simple_sitemap_engines submodule to submit the sitemaps to search engines, got to /admin/config/search/simplesitemap/engines/settings and disable submission. Use IndexNow submission instead which this module suppports well.
Let me know if that helps.
This is still a support request and not a bug report, so changing back the priority. I have the module running on several servers and I'm not encountering this (anecdotal evidence, I know)
This sounds like an exception I used to get when having a space character before the opening php tag, but I might be misremembering.
In any case, I need a full stack trace to debug this. @greatmatter Maybe you're able to clone the environment and reproduce the issue along with a trace?
Also have a look at this, earlier issue: ✨ Add ability to display subtitles/captions Needs review .
Making it work with Drupal 10.x by replacing outdated methods.
8.x is deprecated, will be updating the patch.
@lamp5 Please explain in more detail what and why is getting unserialized?
@Ihnatsevych This would simply undo 📌 unserialize() is insecure unless allowed classes are limited. Use a safe format like JSON or use the allowed_classes option. Fixed and I don't think it's what we want.
@drumm
The major version would eventually get to 4.0.1 again, and having 2 codebases with the same version would defeat the purpose of versioning.
You may be misunderstanding the problem. The module was on 1.0.0 and instead of pushing the tag 1.0.1 I pushed 4.0.1 (4.x branch did not exist). So it would be tremendously helpful to delete the 4.x branch & that release so I don't have to pretend the module is on its 4th breaking iteration. Please reconsider.
I just tested the module on a multisite installation (without the domain module) and it seems to be working. Can anyone confirm this?
Regarding the domain module, it seems that at this time domain_simple_sitemap → is up to date and working with this here module.
Is this also your experience?
Marking as duplicate of ✨ Make functional in multisite installations & domain_access Active . The patches from this here issue won't be helpful in implementing this feature anyway.
Marking as duplicate of ✨ Make functional in multisite installations & domain_access Active .
Closing as per lack of activity.
How can I reach them?