404 Fout op winkelfront zodra de update van de catalogusprijsregelschema's is uitgevoerd
Dit artikel bevat een patch en de vereiste stappen voor het verhelpen van het bekende Adobe Commerce 2.2.1-probleem met betrekking tot het ophalen van een fout van 404 op alle voorpagina's van de winkel, nadat een update van de catalogusprijsregel is gemaakt en de begintijd later is bewerkt. U moet de patch toepassen om het probleem op te lossen.
Probleem
Storefront-pagina's zijn niet meer beschikbaar, er is een fout van 404 geretourneerd. De uitgave wordt weergegeven nadat de actieve update van de catalogusprijsregel moet worden uitgevoerd, op voorwaarde dat de begindatum van deze update is bewerkt na de eerste aanmaak.
Stappen om te reproduceren:
- In Commerce Admin, creeer een nieuwe Regel van de Prijs van de Catalogus onder Marketing > Bevorderingen > Regel van de Prijs van de Catalogus.
- In het net van de Regel van de Prijs van de Catalogus, klik uitgeven, programma een nieuwe Update en plaats Status aan Actief.
- Navigeer aan Inhoud > Inhoud die opneemt > Dashboard.
- Selecteer de onlangs gemaakte update en wijzig de begintijd.
- Sla de wijzigingen op.
Verwacht resultaat :
Wanneer de begindatum van de update van kracht wordt, wordt de regel voor catalogusprijzen met succes toegepast.
Werkelijk resultaat :
Wanneer de begindatum van de update van kracht wordt, worden alle catalogus en producten in de winkel niet meer beschikbaar en wordt de fout 404 geretourneerd.
Oplossing
Als u cataloguspagina's wilt herstellen en de functionaliteit voor updates van catalogusprijsregels volledig wilt kunnen gebruiken, moet u de patch installeren, de regel zowel handmatig als in de beheerder verwijderen en de ongeldige koppelingen in de database herstellen. U moet ook de regel voor catalogusprijzen opnieuw maken.
Hieronder volgt een gedetailleerde beschrijving van de vereiste stappen:
- pas het flardtoe.
- Verwijder in Commerce Admin de regel voor catalogusprijzen met betrekking tot de uitgave (waar de begintijd is bijgewerkt). Om dit te doen, open de regelpagina onder Marketing > Bevorderingen > Regel van de Prijs van de Catalogus, en klik Regel van de Schrapping.
- Als u de database opent, verwijdert u de verwante record handmatig uit de tabel
catalogrule. - Corrigeer de ongeldige koppelingen in de database. Zie de verwante paragraafvoor details.
- In Commerce Admin onder Marketing, ga Bevorderingen > Regel van de Prijs van de Catalogus, en creeer de nieuwe regel met de vereiste configuratie.
- Wis het browser geheime voorgeheugen onder Systeem > het Beheer van het Geheime voorgeheugen.
- Zorg ervoor dat de uitsnijdtaken correct zijn geconfigureerd en met succes kunnen worden uitgevoerd.
Reparatie patch
De patch is aan dit artikel gekoppeld. Als u het bestand wilt downloaden, schuift u omlaag naar het einde van het artikel en klikt u op de bestandsnaam of op de volgende koppeling:
Compatibele Adobe Commerce-versies:
De patch is gemaakt voor:
- Adobe Commerce 2.2.1
De patch is ook compatibel (maar lost het probleem mogelijk niet op) met de volgende Adobe Commerce-versies en -versies:
- Adobe Commerce over cloudinfrastructuur 2.2.0 - 2.2.4
- Adobe Commerce op locatie 2.2.0 en 2.2.2 - 2.2.4
Hoe de pleister aanbrengen
Voor instructie, zie hoe te om een componentenflard toe te passen die door Adobein onze steunkennisbasis wordt verstrekt.
Ongeldige koppelingen naar testbestanden in database herstellen fix_links
Voer de volgende stappen uit om de rijen te corrigeren met ongeldige koppelingen naar de tabel staging_update .
-
Controleer of de ongeldige koppelingen naar de tabel
staging_updatevoorkomen in de tabelflag. Dit zijn records waarinflag_code=stagingvoorkomt. -
Identificeer de ongeldige versie van de
flaglijst gebruikend de volgende vraag:code language-sql SELECT flag_data FROM flag WHERE flag_code = 'staging'; -
Selecteer in de tabel
staging_updatede bestaande versie die lager is dan de huidige (ongeldige) versie en stel de versiewaarde van twee getallen in. U neemt het, niet de vorige versie, om de situatie te vermijden dat de vorige versie de maximumversie in de tabelstaging_updateis die kan worden toegepast en dat we deze nog steeds opnieuw moeten toepassen.code language-sql SELECT id FROM staging_update WHERE id < %current_id% ORDER BY id DESC LIMIT 1, 1De versie die u als reactie krijgt, is uw geldige versie
id. -
Voor de rijen met ongeldige koppelingen in de
flag-tabel stelt u deflag_data-waarden in op gegevens die een geldige versie-id bevatten. Dit helpt de prestaties te besparen bij het opnieuw indexeren en maakt het mogelijk opnieuw indexeren van alle entiteiten te voorkomen.code language-sql UPDATE flag SET flag_data=REPLACE(flag_data, '%invalid_id%', '%new_valid_id%') WHERE flag_code='staging';
Voorbeeld:
SELECT flag_data FROM flag WHERE flag_code = 'staging'; <code class="language-bash">Response < 2.2 version</code>
+-------------------------------------------------+
| flag_data |
+-------------------------------------------------+
| a:1:{s:15:"current_version";s:10:"1490005140";} |
+-------------------------------------------------+
Response from 2.2 version
+-------------------------------------------------+
| flag_data |
+-------------------------------------------------+
| {"current_version":"1490005140"} |
+-------------------------------------------------+
SELECT id FROM staging_update WHERE id < 1490005140 <code class="language-sql">ORDER BY id DESC LIMIT 1, 1</code>;
Response:
1490005138
UPDATE flag SET flag_data=REPLACE(flag_data, '1490005140', '1490005138') WHERE flag_code='staging';