Works as advertised, code looks clean.
Please open bug reports only against the dev version.
I feel like your second solution would be a good emergency break for these relatively rare set-ups. The first solution seems to require too much additional complexity.
Feel free to provide an MR and optionally a test for this.
Something seems wrong with your site. When I open your site in a new browser, I get redirected to the front page (hence google says it's html instead of xml). On the second try I get the sitmemap. That seems to be the problem; try to disable any modules that may redirect the user on the first visit. Maybe something is redirecting to front page then setting a cookie like a language module or something? Good luck!
Feel free to reopen this issue if you need further help.
Can you give me the link to the sitemap? If you prefer, you can do it through the Drupal email functionality
Feel free to send me that link.
I checked with some online checker and seems content-type header is set to text/html; charset=utf-8. I guess, happy debugging session for me.
It should definitely be application/xml
Do I understand correctly that sitemap.xml is not always generated on the fly? Ie, there is no more actual file sitemap.xml laying on server?
It's stored in your database and fetched when the sitemap route is being visited. There is no actual file but it is not generated on the fly.
First of all, please always test on the dev version before submitting bug reports. Secondly, its more courteous to submit tickets as support requests if you are unsure of it being a bug. Can you give me the link to the sitemap? If you prefer, you can do it through the Drupal email functionality
I see the upstream module's DI has been implemented for many years while this module kept on working. This is a quite nice case in point that shows why not implementing DI on our side was the right decision. Let's keep it this way. Feel free to discuss.
As smtp_multiple → seems to correctly override the SMTP configuration, I believe this issue can be closed. I'm not sure how OP encountered this here issue.
See 🐛 SMTP multiple configuration not working for from mail and from name Closed: cannot reproduce .
I have just tested it and this module correctly overrides smtp_from and smtp_fromname. Not sure why you encountered this issue, but please make sure to test with the newest version of the module.
Good catch @leontin!
Thanks for the patch; I found it cleaner however to remove the state from the service and just reset the SMTP configuration right after sending each email. This seems to be working but I'd appreciate you double checking. Also if you find the time, feel free to write a test for this.
I feel like this is a mostly cosmetic release, but I'm happy to tag: https://www.drupal.org/project/simple_sitemap/releases/4.2.2 →
Clsoing as per lack of activity. Feel free to contribute to the core module in a separate feature issue.
Code has been refactored, so this can be implemented more cleanly.
Since it's a support request now, it's fixed now.
gbyte → created an issue. See original summary → .
We are careful with adding too much meta information because of memory constraints. The issue you linked is fair enough, I'll see if it makes sense to add bundle information; but in this case I feel like it's too much of an esoteric use case. Feel free to argue why you need the language info; closing this for now.
Let's continue this in 2.x, as Drupal 8/9 is not supported anymore.
I haven't tested the code, but why would different emails use same credentials? The new mail data arrives as the message parameter within the mail() function having new values and so changing of the values should be evaluated anew depending on the message ID?
Why not open up a support request if unsure if this is a bug or not?
This is done by design and it's implemented here: \Drupal\simple_sitemap\Entity\SimpleSitemap::toString
Why would you like to have it display a 404?
There seems to be a rare problem with changing the sitemap ID column to serial in simple_sitemap_update_8401 and having data in that table. Since apparently this is so anecdotal and spinning up an ancient D8 instance is a bit of an inconvenience, I'm just going to close this issue as not reproducible. If you are a snowflake and encounter this, try and empty the simple_sitemap table and run the updates again.
Sorry I don't get it.
Then don't change this issue's Metadata if I explicitly set it please.
If so, how can I do it with standard Drupal and/or module settings ? (I mean not changing the code)
The less technical answer is you can't. Easiest way is to make sure your home page is a node and that you save it after changing the blocks.
Easiest would be no to bother as the lastmod value has little effect anyway.
For other engines there is Index Now that this module also supports (see submodule) but Google doesn't support it...
We can't get your frontage's last modification date if it's not the core entity (implementing the 'changed' property) that is changing. If we tried, we would have to create a lot of exceptions for a lot of cases.
You could hook into the module to update lastmod upon generation, or implement a URL generator for your Frontpage. Or update the embedding entity's changed value upon saving the blocks.
Or you could do nothing seeing that this parameters are seemingly being ignored by google anyway...
This is a Drupal CMS ("Starshot") issue ATM. Simple XML sitemap will be moved to the "Advanced SEO recipe" and there is work being done on the missing XmlWrtier support breaking the WebAssembly runtime.
#3470830: Create an advanced SEO Recipe →
📌
Remove Simple Sitemap because it breaks the installer in a WebAssembly runtime
Fixed
gábor hojtsy → credited gbyte → .
Duplicate of ✨ Provide more granular permissions Needs review .
We usually don't get these kind of reports which indicates the module is quite scalable.
I have even updated my AWS EC2 server from a T3 Small (2G RAM) to T3 Medium (4G RAM) and it did help reduce the errors a bit, but they're still happening. I am using a T3 Small for the AWS RDS DB (perhaps 2G isn't enough for the DB? to use this module?).
4GB RAM isn't much but it should be enough. Maybe PHP is running out of memory and so the database query does not finish? How much memory is PHP allowed to use in your case? You can check it by visiting /admin/reports/status
7. Maximum links in a sitemap: 20000 (tried lower and higher numbers too)
Try to keep this low - for the sake of testing maybe 200
8. Sitemap generation max duration: 15 (have tried 30, 60, 200 - still get error)
That might be a problem, you want a lower value to save memory. Try 5 for the sake of the test and go from there.
There are also mysql configuration options that you could look at, but I personally never had to change those... Example:
[mysqld]
wait_timeout
max_allowed_packetMaybe there is some strange query error because of a broken data set? Can you try and regenerate the sitemap with different content?
You could also look at mysql logs.
Going with this:
Generates standard-compliant hreflang XML sitemaps to enhance your site's SEO, notifies search engines of website changes via IndexNow and sitemap ping protocols, and provides a framework for developing other sitemap types.
am I) right to assume that this feature would allow exposing sitemap settings in views?
If this were in, we possibly might need an additional views hook but that would be very easy to implement. So yes.
I just checked again, I get a similar error as you, but after clearing the site's caches the error is gone. After removing drush, you can clear the site's caches by visiting /core/rebuild.php or /update.php
I support walkingdexter on this matter - I do sometimes work around other modules' problems, but those modules better be in core, otherwise this is a never ending endeavour.
We can do better than this, I'll look into it.
Core issue 🐛 url() should return / when asked for the URL of the frontpage Needs work which should fix this problem has not been fixed yet - I hear you guys, I'll take another look at working around this in this module soon.
For 4.x see ✨ Respect front page configuration Closed: won't fix
For 4.x see ✨ Respect front page configuration Closed: won't fix .
Further work in ✨ Respect front page configuration Closed: won't fix
Hey, creator of simple_sitemap here. I'm happy to work with you on a solution (like finding a replacement for xmlWriter) in case you are interested in keeping this module in the code base - let me know.
That was quick. Looks good, thanks!
Off topic, but on the topic of simple_sitemap_engines: To whoever is responsible, maybe it would make sense to include simple_sitemap_engines with its IndexNow functionality into such a Drupal CMS receipe.
Changing category to task as this is not a bug in my book.
Just as an FYI, this issue is likely to block inclusion of Simple Sitemap in Drupal CMS. :-\
And we don't want that to happen, do we? :)
I updated the config files to match the order of what Drupal exports.
Looking at the MR diff config/install/simple_sitemap.sitemap.default.yml seems off - ID is changed from 'default' to 'index'
Please fix that and also look at the sub modules, especially simple_sitemap_engines. Does making a recipe with that module create a similar issue?
Thanks, I'll make sure to merge that in a timely fashion.
I hear you. Let's create the release as soon as we sort out #3399117: About semantic versioning.
Done → .
This has already been fixed in a different issue. Please let me know if you still encounter this problem.
Thanks.
Thanks.
Isn't ATOM a subset of ISO8601? How is this a bug? Why am I not surprised to see your username in this issue. ^^
I don't see how adding entity keys to configuration that do not exist in the entities themselves solves any problem; rather this seems to be a strange workaround. Neither sitemap nor sitemap type entities have a language code, because a language code does not make sense. Sitemap type entities don't have a status as there is nothing to unpublish. These are custom entity types for a reason - we don't need everything a node entity provides.
I have not used recipes yet but only taking under account your description, this seems to be more of a problem on their side. Please correct me if you feel I'm wrong.
This always allow non-breaking updates. ^4.3 means >=4.3.0 <5.0.0.
Obviously - sorry I worked the night and am pretty tired.
There is no need to maintain two versions. We just increase the minor version and move on.
Yeah I did that last time, it means unpublishing the last release - AFAIK creating new minor versions creates multiple published versions.
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).
Alright thanks for your input.
Regarding this issue: I won't be creating new minor versions for minor new features. I'll try to stick to the other things you pointed out though.
Thanks for looking into this.
@vipin.mittal18, darren.fisher
I hear you. Let's create the release as soon as we sort out 🌱 About semantic versioning Active .
@walkingdexter
I am not a fan of increasing MINOR when adding functionality as it seems to create a fork and two versions to maintain, correct? In addition people stay on the previous version forever as they often have something like "^4.3" in composer. What are your thoughts?
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?
Either create a new URL generator by code and use it within the UI or just use the sitemap links alter hook (see Readme) to filter out entities beyond a certain creation date.
When it comes to having certain content types indexed in certain sitemap, this is already possible without custom code.
Let me know if yiu need further pointers.
@jimmb If /homepage is a node, why not exclude that single node from index? (Edit the node and exclude it under the sitemap settings.)
And to answer your question (but in your case the above solution would be better I think): The default homepage is being indexed in the custom link area - removing the '/' from there means excluding the home page (or its duplicate) from index.
@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.