Bekende problemen bij het updaten van Drupal 6 of 7 naar Drupal 8

Drupal 6 naar 8

Aggregator categorieën

In Drupal 8 bestaat het concept van aggregator categorieën niet meer en daarom worden ze niet gemigreerd naar Drupal 8.

Toegestane protocollen

Drupal 8 bewaart nu protocollen in de containerparameter «filter_protocols». Als je de variabele «filter_allowed_protocols» hebt aangepast, voeg deze dan toe aan het bestand services.yml.

Toegestane taxonomie-referentievelden woordenlijsten

In Drupal 6 wordt de lijst van toepasselijke inhoudstypen voor een bepaalde woordenlijst gedefinieerd in de woordenlijstinstellingen. In Drupal 8 kunnen toegestane woordenlijsten worden ingesteld in de instellingen van het taxonomie-termreferentieveld. Deze instelling wordt momenteel niet gemigreerd, waardoor alle woordenlijsten in Drupal 8 kunnen worden gerefereerd. Je kunt handmatig de instellingen van het taxonomie-termreferentieveld in Drupal 8 bewerken na de upgrade en toegestane woordenlijsten selecteren.

[Opgelost] Datumformaten

Alleen de standaardformaten kort, middel en lang worden gemigreerd. Alle andere standaardformaten hebben een fallback-formaat en moeten opnieuw worden geconfigureerd na de migratie.

Velden die ontbreken in het bewerkformulier of op de weergavepagina

Een andere verwarrende situatie kan optreden wanneer je een migratie uitvoert die succesvol lijkt, maar daarna zie je je velden niet in het bewerkformulier. Ga naar de beheerpagina van de inhoudstypen en open het tabblad «Beheer formulierweergave» voor elk inhoudstype. Velden die door de migratie zijn toegevoegd, kunnen verborgen zijn in het bewerkformulier. Als dat zo is, sleep ze naar boven zodat ze zichtbaar zijn. Op dezelfde manier, als ze niet verschijnen in de nodeweergave, kunnen velden die door Migrate zijn toegevoegd verborgen zijn op het tabblad «Beheer weergave», en moet je ze daar zichtbaar maken. Bij de migratie van aangepaste velden naar een entiteit kan de module Migrate Plus helpen.

Startpagina laadt niet en thema werkt niet

Bij het uitvoeren van een migratie is de pagina soms wit en laadt slechts enkele elementen. Dit lijkt op een gebroken thema. Door /user te bezoeken en terug te keren naar de startpagina wordt dit meestal opgelost.

Menu UI

De variabelen menu_primary_links_source en menu_secondary_links_source worden niet gemigreerd, omdat ze geen equivalent hebben in Drupal 8.

Modules en thema’s

Voor het starten van de migratie moet je de nieuwe modules en thema’s inschakelen, evenals een admin-thema instellen (indien beschikbaar).

Node inhoudstypen

De standaardconfiguratie in Drupal 6 bevat de inhoudstypen Story en Page. De standaard inhoudstypen in Drupal 8 heten Article en Basic Page (met de machinenaam 'page', net als in Drupal 6).

• De migratie zal het inhoudstype Drupal 6 Page mappen naar het inhoudstype Drupal 8 Page, omdat de machinenaam hetzelfde is.
• De migratie zal een inhoudstype Story aanmaken in Drupal 8. Je kunt er voor kiezen het inhoudstype Drupal 8 Article te verwijderen, als je het niet nodig hebt. Voor meer informatie, zie #2236289: Migratie van «story» nodes uit D6 creëert een nieuw inhoudstype in D8.

Node vertalingen

In Drupal 6 en 7 werden node-vertalingen opgeslagen in aparte nodes, terwijl ze in Drupal 8 nu worden samengevoegd met hun bronnodes. Het migratiesysteem zal de nodevertalingen samenvoegen, maar dit betekent dat sommige links nu kunnen wijzen naar nodes die niet meer bestaan. Zie #2746527: [META] Behandel gegevens met betrekking tot node-vertalingen van Drupal 6 en 7.

Merk op dat revisies van vertaalde nodes nog niet gemigreerd zijn. Zie #2746541: [backport] Migratie van revisies van D6 en D7 nodes naar D8 voor meer info.

Overzicht van het upgraden van meertalige Drupal 6 naar Drupal 8.

Profielcategorieën

Velden die in Drupal 6 door de profielmodule gegroepeerd werden, zullen in Drupal 8 niet gegroepeerd worden.

Profielveld (lijstselectie)

De instelling «toegestane waarden» van het resulterende veld in Drupal 8 zal een combinatie zijn van alle aangepaste waarden die gebruikers hadden geselecteerd en de huidige toegestane waarden in Drupal 6, en niet enkel de toegestane waarden in Drupal 6.

Statistieken

Instellingen van toegangslogboek en statistische gegevens zijn niet i18n gemigreerd. Consolidatie van i18n statistieken is gemigreerd vanaf Drupal 8.5.2. Zie #2930101: i18n/statistieken – node teller wordt niet bijgewerkt voor vertalingen.

Tekst / invoerformaten

Filterformaten die niet herkend worden door Drupal 8 worden gemigreerd als filter_null, een filter dat gewoon een lege string teruggeeft. Dit betekent dat elk invoerformaat dat een onbekend filterformaat gebruikt, geen veldinhoud zal weergeven, ook al staat de inhoud in de database. Dit kan verwarrend zijn. Zie #2618332: Betere afhandeling van ontbrekende filters met filter_null en #2630578: Dubbele formaten in D6 migratie

Niet-herkende filterformaten in Drupal 8 zijn onder meer de beruchte PHP-code filter en elke andere filter geleverd door een contrib-module die niet beschikbaar is in je Drupal 8 installatie.

De PHP filter wordt niet ondersteund in de Drupal 8 core – dit is een zeer slechte praktijk, maar je kunt de PHP module gebruiken als je dit echt nodig hebt.

Om dit probleem op te lossen, heb je verschillende alternatieven:

• Controleer of modules die filters leveren een Drupal 8 versie hebben en installeer die
• Bewerk en sla de betrokken invoerformaten op. Dit verwijdert de koppeling naar filter_null en de inhoud begint weergegeven te worden. Let op dat, omdat het oorspronkelijke filter niet bestaat, de inhoud niet gefilterd wordt en ongefilterde tokens of zelfs beveiligingsproblemen zichtbaar kunnen zijn
• Bewerk de inhoud en verander naar een ander invoerformaat. Dit brengt dezelfde problemen met zich mee als het vorige punt

Tijdzones en datums

Drupal 6 gebruikt een tijdzone-offset om lokale tijd te berekenen. Drupal 7 en 8 gebruiken een tijdzone-naam. Helaas genereert de PHP-functie timezone_name_from_abbr() verschillende tijdzonenamen afhankelijk van of zomertijd op de server aan of uit staat. Bijvoorbeeld, een offset van 3600 converteert naar Europe/Paris als zomertijd uit staat, en Europe/London als zomertijd aan staat. De migratie is ingesteld om zomertijd te negeren. Afhankelijk van de serverconfiguratie kan de Drupal 8 tijdzone-instelling foutief zijn na de migratie (#2353679: ontbrekende migratievariabele D6->D8: date_default_timezone).

In tijdzones met zomertijd kan de datum in Drupal 8 anders geïnterpreteerd worden dan in Drupal 6. Bijvoorbeeld, rond middernacht kan de datum als een andere dag worden beschouwd. Dit veroorzaakt problemen, vooral als datumtokens gebruikt worden voor padopbouw (zoals URL-aliases, bestandspaden). Twee mogelijke oplossingen zijn te vinden in #2926421: Afhandeling van datumverschillen tussen D6 en D8.

URL-aliases

Wanneer URL-aliases worden gemigreerd voor een taal die niet ingeschakeld is op de nieuwe Drupal 8 site, zal geen van de aliassen werken totdat je de taal inschakelt op de nieuwe Drupal 8 site.

Views

Views worden nog niet gemigreerd, je moet de weergaven in Drupal 8 handmatig aanmaken. Voor meer informatie, zie #2500547: Upgrade pad voor Views van Drupal 6 en 7 en de module Views Migration.

Instelling gebruikersactiviteit-blok

Instellingen van gebruikersactiviteit worden niet gemigreerd. Dit moet handmatig aangepast worden in de juiste view in het gedeelte filters/toegang (#2169327: migreer de instelling van het gebruikersactiviteit-blok).

Drupal 7 naar 8

[Opgelost] Toegestane taxonomie-term woordenlijsten

In Drupal 7 wordt de toegestane woordenlijst voor een taxonomie-termreferentieveld ingesteld in de veldinstellingen. Deze instelling wordt momenteel niet gemigreerd, waardoor alle woordenlijsten in Drupal 8 kunnen worden gebruikt (zie #2763637: D7 taxonomie-termvelden worden niet gemigreerd met toegestane woordenlijsten). Je kunt handmatig de instellingen van het taxonomie-termreferentieveld in Drupal 8 bewerken na de upgrade en toegestane woordenlijsten selecteren.

Geblokkeerde IP-adressen

De kolom id van de ban_ip tabel in Drupal 7 wordt niet gemigreerd.

Commentaartypen

Drupal 7 laat toe dat commentaren verschillende velden hebben voor verschillende inhoudstypen. Gewoonlijk hebben commentaren de velden Auteur, Onderwerp en Commentaar. Omdat verschillende D7-commentaren verschillende velden kunnen hebben, worden tijdens de migratie aparte D8-commentaartypen aangemaakt voor elk inhoudstype:

• Het inhoudstype Foo zal een commentaartype hebben comment_node_foo
• Het inhoudstype Bar zal een commentaartype hebben comment_node_bar

De enige uitzondering zijn forumcommentaren. Wanneer de D8 Forum module is ingeschakeld, wordt automatisch een commentaartype comment_forum aangemaakt. D7 forumcommentaren worden naar dit commentaartype gemigreerd.

Belangrijke opmerking: standaard Drupal 8 installatieprofiel en inhoudstype Artikel
Als je Drupal 8 site is geïnstalleerd met het standaard installatieprofiel, heb je een inhoudstype genaamd Article.

• Dit inhoudstype wordt geleverd met een commentaarveld genaamd comment.
• Het migratiesysteem kan niet aannemen dat de D8 site met het standaard profiel is geïnstalleerd. Daarom wordt een commentaartype comment_node_article aangemaakt, en D7 commentaren voor het inhoudstype Article worden naar dit type gemigreerd.

Als gevolg hiervan heeft je inhoudstype Article nu twee commentaarvelden:

• comment, afkomstig van het standaard D8 installatieprofiel en ongebruikt
• comment_node_article, aangemaakt door het migratiesysteem

Waarschijnlijk wil je niet twee commentaarvelden voor het inhoudstype Article, dus moet je handmatig het commentaarveld «comment» verwijderen uit Article (admin/structure/types/manage/article/fields). Daarna kun je ook het commentaartype comment verwijderen (admin/structure/comment), als je dat type nergens gebruikt.

Het wordt aanbevolen om het onnodige commentaarveld uit het inhoudstype Article te verwijderen voor het uitvoeren van de migraties, omdat Drupal 8 core momenteel een bug heeft met het verwijderen van een commentaarveld, zie #2906470: Verloren commentaren en records in comment_entity_statistics na verwijderen van een commentaarveld.

PHP-code

Filterformaten die niet herkend worden door Drupal 8 worden gemigreerd als filter_null, een filter dat gewoon een lege string teruggeeft. Dit betekent dat elk invoerformaat dat een onbekend filterformaat gebruikt, geen veldinhoud zal weergeven, ook al staat de inhoud in de database.

Niet-herkende filterformaten in Drupal 8 zijn onder meer de beruchte PHP-code filter en elke andere filter geleverd door een contrib-module die niet beschikbaar is in je Drupal 8 installatie.

De PHP filter wordt niet ondersteund in de Drupal 8 core – dit is een zeer slechte praktijk, maar je kunt de PHP module gebruiken als je dit echt nodig hebt.

Om dit probleem op te lossen, heb je verschillende alternatieven:

• Controleer of modules die filters leveren een Drupal 8 versie hebben en installeer die
• Bewerk en sla de betrokken invoerformaten op. Dit verwijdert de koppeling naar filter_null en de inhoud begint weergegeven te worden. Let op dat, omdat het oorspronkelijke filter niet bestaat, de inhoud niet gefilterd wordt en ongefilterde tokens of zelfs beveiligingsproblemen zichtbaar kunnen zijn
• Bewerk de inhoud en verander naar een ander invoerformaat. Dit brengt dezelfde problemen met zich mee als het vorige punt

Platte tekstvelden

Tegenstrijdige tekstverwerkingsinstellingen in Drupal 7
In Drupal 7 worden tekstverwerkingsinstellingen ingesteld in de veldinstellingen van een instantie. Dit betekent dat hetzelfde veld gebruikt kan worden voor twee (of meer) inhoudstypen, en dat tekstverwerking «Platte tekst» kan zijn voor één inhoudstype en «Gefilterde tekst» voor een ander.

Drupal 8 heeft aparte veldopslagtypen Text (plain) en Text (formatted). Er zijn ook Text (plain, long) en Text (formatted, long). Het belangrijkste punt hier is dat de keuze plain/formatted wordt gemaakt op het niveau van de veldopslag. Met andere woorden, de plain/formatted keuze kan niet verschillen per inhoudstype.

Het migratiesysteem maakt geen aannames. Als het migratiesysteem tegenstrijdige tekstverwerkingsinstellingen detecteert, worden deze velden overgeslagen met een logbericht. De sitebouwer heeft twee opties:

1. Pas de tekstverwerkingsinstellingen aan op de Drupal 7 site zodat alle inhoudstypen die het veld gebruiken dezelfde instellingen hebben.

• Let bij het kiezen van een uniforme instelling op mogelijke beveiligingsproblemen zoals cross-site scripting (XSS).
• Als je veld in Drupal 7 was ingesteld op «Platte tekst» en niet-vertrouwde gebruikers konden dit veld invullen, kan dit veld kwaadaardige invoer bevatten. Dit leidde niet tot XSS op je Drupal 7 site omdat het veld Platte tekst was, maar als je het veld nu wijzigt naar Gefilterde tekst, zorg er dan voor dat het invoerformaat niet Full HTML of vergelijkbaar is, waardoor kwaadaardige invoer mogelijk wordt uitgevoerd.

2. Als je twee verschillende instellingen voor tekstverwerking in Drupal 8 nodig hebt, moet je een aangepaste migratie ontwikkelen die de Drupal 7 velden splitst in twee aparte Drupal 8 velden. Meer informatie over het aanpassen van migraties bij het upgraden naar Drupal 8 vind je hier: Pas migraties aan bij het upgraden naar Drupal 8.

Tekst met samenvatting + platte tekstinstelling in Drupal 7
Drupal 7 heeft een veldtype Long text en summary. Het overeenkomstige veldtype in Drupal 8 is Text (formatted, long, with summary). In Drupal 7 kan je instellen dat de tekstverwerking plain text is. Text (formatted, long, with summary) is altijd formatted in Drupal 8.

Het migratiesysteem maakt geen aannames. Als het migratiesysteem een Long text and summary veld met plain text-instellingen detecteert, wordt dit veld overgeslagen met een logbericht. De sitebouwer heeft dezelfde twee opties als hierboven:

1. Wijzig de veldinstelling van plain text naar filtered text in Drupal 7.

• De bovenstaande opmerking over XSS geldt ook hier.

2. Maak een aangepast migratiepad en ontwikkel je eigen logica voor hoe je deze velden naar Drupal 8 wilt migreren. Zie: Pas migraties aan bij het upgraden naar Drupal 8.

Statistieken

Instellingen van toegangslogboek en statistische gegevens zijn niet i18n gemigreerd. Consolidatie van i18n statistieken is gemigreerd vanaf Drupal 8.5.2. Zie #2930101: i18n/statistieken – node teller wordt niet bijgewerkt voor vertalingen.

Views

Views worden nog niet gemigreerd, je moet de weergaven in Drupal 8 handmatig aanmaken. Voor meer informatie, zie #2500547: Upgrade pad voor Views van Drupal 6 en 7 en de module Views Migration.

Mogelijke ID-conflicten (van D6 of D7 naar Drupal 8)

Probleem

Zoals beschreven op de pagina voorbereiden op een upgrade, moet een Drupal 8 site volledig leeg zijn voordat het upgradeproces wordt uitgevoerd. Het migratieproces behoudt de ID’s van de bronsite bij het importeren naar de Drupal 8 site. Als er inhoud is aangemaakt op de Drupal 8 site vóór de upgrade (bijvoorbeeld een node met nid 1), zullen de ID’s waarschijnlijk conflicteren.

Er wordt momenteel gewerkt aan het automatisch detecteren van mogelijke ID-conflicten en het waarschuwen van de gebruiker, zie #2876085: Controleer op mogelijke ID-conflicten vóór upgrade. Tot die tijd moeten sitebeheerders zelf mogelijke conflicten zorgvuldig nakijken. Als ID-conflicten niet voorzichtig worden afgehandeld, kan inhoud of andere entiteitselementen zoals taxonomietermen en bestanden worden overschreven, wat leidt tot dataverlies. Ook kan het zijn dat referenties beschadigd raken, bijvoorbeeld inhoud die naar een verkeerde taxonomieterm verwijst.

Scenario’s die kunnen leiden tot ID-conflicten

• De Drupal 8 doelsite was al in gebruik op het moment van de upgrade en er was al inhoud aangemaakt.
• De initiële migratie was voltooid. Daarna is inhoud of zijn entiteiten aangemaakt op zowel de bronsite als de doelsite. Wanneer de nieuwe of bijgewerkte inhoud vervolgens van de bronsite wordt gemigreerd, kunnen de ID’s conflicteren met inhoud op de D8 site.
• De Drupal 8 doelsite was leeg, maar extra of aangepaste modules hebben data aangemaakt bij het inschakelen in D8. Bijvoorbeeld, de core Forum module in D8 maakt een taxonomieterm aan voor de algemene discussie-categorie en dit krijgt meestal ID #1 in een nieuwe installatie. Als de bronsite een taxonomieterm met ID 1 heeft, zal deze de algemene discussiecategorie overschrijven.
• De bron kan gegevens hebben zonder ID, maar de bestemming vereist dat ze een ID hebben. Bijvoorbeeld, Drupal 6 behandelt gebruikersafbeeldingen als unmanaged bestanden zonder ID, maar in D8 moeten ze een ID krijgen. Tijdens de migratie worden managed file entities aangemaakt met ID’s die kunnen conflicteren met bestanden die nog moeten worden gemigreerd.
• Mogelijke ID-conflicten bij vertalingen worden niet automatisch gedetecteerd.

- Als je een volledige upgrade uitvoert in één keer naar een lege Drupal 8 site, zou alles in orde moeten zijn.
- Als je een gedeeltelijke migratie uitvoert na de initiële upgrade en je hebt vertalingen toegevoegd op je Drupal 8 site voordat de nieuw aangemaakte/bijgewerkte inhoud wordt gemigreerd, kan de tweede migratie de vertaling overschrijven die al op de Drupal 8 site aanwezig was.

Oplossingen

Aangepaste migratie voor conflicterende items
Het is mogelijk om de migratie voor problematische inhoud aan te passen, zodat nieuwe ID’s worden aangemaakt. Let op dat dit invloed heeft op interne paden en mogelijk ook publieke URL’s. Besteed extra aandacht aan het corrigeren van alle verwijzingen naar de gewijzigde objecten.

Manipuleer auto_increment waarden
Wanneer de Drupal 8 bestemming geen conflicterende data heeft, maar de migratie wel conflicten kan veroorzaken, kun je de AUTO_INCREMENT waarde in de database-tabellen aanpassen zodat nieuwe entiteiten ID’s krijgen buiten het bereik van de gemigreerde entiteiten. De migratie van gebruikersafbeeldingen hierboven is hier een voorbeeld van.

Accepteer dat data kan worden overschreven
Je kunt de migratie ook gewoon uitvoeren. Dit is in veel gevallen geen gewenste oplossing, omdat het tot dataverlies kan leiden.

Upgrade van meertalige sites (van D6 of D7 naar Drupal 8)

Voor alle meertalige migraties vanuit de internationalisatie modules in Drupal 6 en 7 (i18n) en de Entity Translation module in Drupal 7, is het vereist dat de Drupal 8 Migrate Drupal Multilingual Module (migrate_drupal_multilingual) core module is ingeschakeld.

Overzicht van het upgraden van meertalig Drupal 6 naar Drupal 8.