Problem/Motivation

Tried to click a button in D8 again and all went down :)
I tried to generate a sitemap added nodetypes. Somehow he doesnt have a value but no details. Can we maybe set a default value?
Or any other ideas how to fix this?

Edit: Taxonomy terms are responsible for this.

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'lastmod' cannot be null: INSERT INTO {xmlsitemap} (type, id, language, loc, subtype, access, status, status_override, lastmod, priority, priority_override, changefreq, changecount) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12); Array ( [:db_insert_placeholder_0] => taxonomy_term [:db_insert_placeholder_1] => 11376 [:db_insert_placeholder_2] => de [:db_insert_placeholder_3] => /taxonomy/term/11376 [:db_insert_placeholder_4] => category [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => 1 [:db_insert_placeholder_7] => 0 [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => 0.5 [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => 60 [:db_insert_placeholder_12] => 0 ) in Drupal\Core\Database\Connection->handleQueryException() (Zeile 698 in /www/htdocs/w00bbe43/PRODUCT_DISTRI_5/web/core/lib/Drupal/Core/Database/Connection.php).

Steps to reproduce

Run an incremental taxonomy term migration or drush mim --update your_taxonomy_term_migration

Proposed resolution

Handle NULL values in the changed field of taxonomy terms.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Issue fork xmlsitemap-3153380

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

marcoka created an issue. See original summary.

marcoka’s picture

marcoka commented
Issue summary: View changes
dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Active » Postponed (maintainer needs more info)

As far as I know, taxonomy terms in Drupal 8 should have last modification dates that are not null, and your query indicates that the module attempted to index a taxonomy term. Which version of Drupal 8 core are you using?

marcoka’s picture

marcoka commented

8.9.1
I also updated from D7. So it may be a problem caused by core migration.
I now resaved the tags by hand, then the problem is gone.

vacho’s picture

vacho commented

The same issue with D8.9 recently migrated from D7 too. But this works well in D8 recently migrated, for some reason this starts to happen these days.

nchase’s picture

nchase commented

Same problem here with a site upgraded from d7.

nchase’s picture

nchase commented

Workaround:

  1. install views_bulk_operations.
  2. Create a view that lists all taxonomy terms
  3. Add a field Global: Views bulk operations
  4. Under "Action" select "Save Taxonomy Term"
  5. Save the view
  6. Open the views and select all terms and "save the term"

After that the rebuild of the sitemap works.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Title: Lastmod can not be null » Migrated taxonomy terms error with lastmod cannot be null
Status: Postponed (maintainer needs more info) » Active

Hrm, seems like this is definitely a migration issue. It looks like core attempts to migrate a 'changed' property in it's taxonomy migrations from D7 and D6, but there is no source to migrate from, so it should probably set a default value of zero.

sagar ramgade’s picture

sagar ramgade commented

I tried to solve it by setting a default value for changed property. The error occurs only when changed property is set to NULL, the following yml code sets it to 0:

  changed:
    -
      plugin: default_value
      default_value: 0
      strict: true
sd123’s picture

sd123 commented

I confirm this bug does still exist when migrating from D7 to Drupal 9.1.3 and XML Sitemap 8.x-1.0.

The solution in comment #7 did fix this bug but it would ease migration if this can be done automatically in the migration code.

quietone’s picture

quietone commented
Issue summary: View changes

This issue came up in #migration.

Regarding #8. I looked at the d6 and d7 test fixture and agree, there is no timestamp field to migrate. Neither the d6 and d7 Term source plugins create such a property for the migration row either. This means that the line in the migration yaml, changed: timestamp, has no effect and the 'changed' property does not exist on the destination row. If the row is saved the entity system uses the current timestamp for the 'changed' property.

#9 suggests that the error occurs when the changed property is set to NULL. The only way I see that happening in a migration is when an incremental migration is run or using drush mim --update. I confirmed that is the case. When I tried with --update I got the same error message as in the IS.

Is everyone experiencing this problem doing incremental/update migration of the taxonomy terms?

The core Term tables do allow a value of NULL for the changed field (unlike node) so I think xmlsitemap should handle that case and not cause a fatal error. Maybe add logic in xmlsitemap_xmlsitemap_process_entity_link()?

A work around is to change the migration and set a timestamp value for the changed property. If it is set to 0 as in this example the changed property will be set to the current timestamp when saved. I don't know why the entity system does not save 0 as a valid timestamp but that is something to learn about later.

  changed:
    plugin: default_value
    default_value: 0

It it is set to any other valid timestamp then that will value be the changed value for all the updated taxonomy terms.

pslcbs’s picture

pslcbs commented

Hi,
#7 not always works because in my case didn't

#11 worked ok.

Thanks!

shani maurya’s picture

shani maurya
Location Mumbai
commented

Hi,

#11 worked for me as well.
Update Below code in your taxonomy.yml file

changed:
    plugin: default_value
    default_value: 0

Thanks!

ElusiveMind made their first commit to this issue’s fork.

elusivemind’s picture

elusivemind commented

I have found that if you modify the insert command to typecast the value of lastmod to (int) ... it also resolves the problem

ElusiveMind opened merge request !25