Old problem back again: Can't delete pages 2.13.8

[CodeALot]

Pressing the bin does nothing. Console shows:

Code: [Select]

index.php:946 Uncaught SyntaxError: missing ) after argument list (at index.php:946:309)
PHP-Version: 8.3.24
WebsiteBaker-Version: 2.13.8 -r20

[sternchen8875]

cannot confirm this on the first look

but maybe with some more informations

its possible for you, to take a look to this Code-line 946 in the inspector-tab, the line number depends on the content, on the number of your pages in the list

if you dont have line-numbers, make a screenshot

[CodeALot]

Found it. It's a problem in the Dutch language file.
In /admin/pages/languages/NL.php it says on lines 58 and 59:

Code: [Select]

$MESSAGE['PAGES_DELETE_CONFIRM'] = 'Weet u zeker dat u de geselecteerde pagina en de subpagina\'s definitief wilt verwijderen?';
$MESSAGE['PAGES_MARKED_CONFIRM'] = 'Weet u zeker dat u de geselecteerde pagina en de subpagina\'s wilt markeren voor verwijdering? ';

The problem is subpagina\'s which is not correctly escaped in the website, causing the line in index.php to break.
I changed it to "subpaginas" (not correct in Dutch but it works), reloaded language files and cleared the translation cache (important!) and now it works.

[dbs]

subpagina\'s can't be the reason. if yes there seems to be a problem in another place.

[sternchen8875]

Found it. It's a problem in the Dutch language file.
In /admin/pages/languages/NL.php it says on lines 58 and 59:

Thanks, i'll check this
i remember, that there was the same problem in french, but solved with a fix, before we go public. But now, i know, what it is

[sternchen8875]

Hab das ZIP zurückgezogen, noch was entdeckt, sorry

I've pulled the ZIP, discovered something else, sorry

[CodeALot]

subpagina\'s can't be the reason. if yes there seems to be a problem in another place.

Changing that line fixed it. So it was the reason. In the console the line showed it as subpagina's and the ' broke the line. So the escape in the language file was not processed (it says subpagina\'s in the language file)

[sternchen8875]

English Translation
Hi everyone,
Here is a brief explanation of the recent JavaScript errors some of you have been experiencing.
The core of the problem lies in how special characters are handled. A few years ago, the HTML entity for apostrophes (’) in our language files was replaced with the standard apostrophe character ('). For PHP, this isn't an issue as long as this character is correctly escaped with a backslash (\'). This escaping is therefore correct from a pure PHP perspective.
Unfortunately, it has become clear that this correct-for-PHP escaping causes errors when the text is used in JavaScript contexts (e.g., in confirmation dialogues).
The only clean and sustainable solution is to fix the language files. We will replace the problematic, escaped apostrophes (\') with their correct, typographical, and universally safe equivalent (’).
This affects, for example, 24 replacements in the 7 Dutch language files, but in total, it amounts to 1176 replacements across 99 different files, as Romance languages like Catalan, Spanish, or French use this character very frequently.
Since providing instructions for manually copying individual files would be too complicated, we will release a language pack patch. This can be easily uploaded via the admin panel and extracted using our unzip.php routine, which will automatically copy all files to their correct locations.
Sorry for the trouble. The effort to finally complete and unify all language files has unfortunately had this unexpected boomerang effect. We are working on providing the patch as soon as possible.

--------------------------------------------

Nederlandse Vertaling
Hallo allemaal,
Hier is een korte uitleg over de recente JavaScript-fouten die sommigen van jullie hebben ondervonden.
De kern van het probleem ligt in de verwerking van speciale tekens. Enkele jaren geleden werd in onze taalbestanden de HTML-entiteit voor apostrofs (’) vervangen door het directe apostrofteken ('). Voor PHP is dit op zich geen probleem, zolang dit teken correct wordt gemaskeerd met een backslash (\'). Deze "escaping" is vanuit een puur PHP-oogpunt dus correct.
Helaas is gebleken dat deze voor PHP correcte maskering fouten veroorzaakt wanneer de teksten in een JavaScript-context worden gebruikt (bijvoorbeeld in bevestigingsdialoge n).
De enige zuivere en duurzame oplossing is het herstellen van de taalbestanden. We zullen de problematische, gemaskeerde apostrofs (\') vervangen door hun correcte, typografische en voor alle systemen veilige variant (’).
Dit betreft bijvoorbeeld 24 vervangingen in de 7 Nederlandse taalbestanden, maar in totaal gaat het om 1176 vervangingen in 99 verschillende bestanden, aangezien Romaanse talen zoals Catalaans, Spaans of Frans dit teken zeer vaak gebruiken.
Omdat het te ingewikkeld zou zijn om instructies te geven voor het handmatig kopiëren van individuele bestanden, zullen we een taalpakket-patch uitbrengen. Deze kan eenvoudig via het admin-paneel worden geüpload en uitgepakt met onze unzip.php-routine, die alle bestanden automatisch naar de juiste locatie kopieert.
Sorry voor het ongemak. De inspanning om eindelijk alle taalbestanden te voltooien en te uniformeren, heeft helaas dit onverwachte boemerangeffect gehad. We werken eraan om de patch zo snel mogelijk beschikbaar te stellen.

--------------------------------------------

(german)

Hallo zusammen,
hier eine kurze Erklärung zu den jüngsten JavaScript-Fehlern, die bei einigen von euch aufgetreten sind.
Das Kernproblem liegt in der Verarbeitung von Sonderzeichen. Vor einigen Jahren wurde in unseren Sprachdateien die HTML-Kodierung für Apostrophe (’) durch das direkte Zeichen (') ersetzt. Für PHP ist das an sich kein Problem, solange dieses Zeichen korrekt mit einem Backslash maskiert wird (\'). Diese Maskierung ist auf der reinen PHP-Seite also korrekt.
Leider hat sich gezeigt, dass diese für PHP richtige Maskierung zu Fehlern führt, wenn die Texte in JavaScript-Kontexten (z.B. in Bestätigungs-Dialogen) verwendet werden.
Die einzig saubere und nachhaltige Lösung ist die Reparatur der Sprachdateien. Wir werden die problematischen, maskierten Apostrophe (\') durch ihre korrekte, typografische und für alle Systeme sichere Variante (’) ersetzen.
Das betrifft beispielsweise in den 7 niederländischen Sprachdateien 24 Ersetzungen, aber insgesamt sind es 1176 Ersetzungen in 99 verschiedenen Dateien, da romanische Sprachen wie Katalanisch, Spanisch oder Französisch dieses Zeichen sehr häufig verwenden.

[sternchen8875]

https://addon.WebsiteBaker.org/en/browse-add-ons/?id=08315346


Official Language Pack Patch for WebsiteBaker [WebsiteBaker 2.13.8]
This is a critical patch that updates all core language files for the 22 supported languages.
What problem does this solve?
This patch fixes a significant bug introduced in a recent version where special characters (specifically apostrophes) in language variables were escaped in a way that is correct for PHP but incompatible with JavaScript. This resulted in JavaScript errors on the frontend and in the backend, for example in confirmation dialogues ("missing ) after argument list").
This update corrects the issue at its source by replacing all problematic characters in the language files with their safe, typographically correct equivalents.
Who needs this patch?
This patch is highly recommended for all users of WebsiteBaker [WebsiteBaker 2.13.8], especially if you or your users operate the backend in any of the 22 core languages.
Installation Instructions
Installation is simple and is done using the unzip.php utility.

[crnogorac081]

Can we keep the ' and apply HTML to entities to langage variables when language file Are loaded ?

[CodeALot]

Thank you VERY much for the quick solution! 

[sternchen8875]

Can we keep the ' and apply HTML to entities to langage variables when language file Are loaded ?

That's a very good question, and at first glance, the idea of manipulating the output seems like it should work.

However, here are the arguments against it:

After doing some research into older versions, I realized this wasn't a legacy issue, but actually my mistake. The Straight Apostrophe (\') is the wrong character in this context; the correct one is the Typographic (or Curly) Apostrophe (’). Maybe I just need a bigger font size in my editor... (sorry).

My first attempts were indeed to manipulate Translate.php, which handles language variables in WB. This would have been an easy fix, but it still would have required a patch in the end. So, why not get to the root of the problem?

The main issue is that a central change in Translate.php only ever provided a good solution for one side of the coin: either it fixed the JavaScript, or it fixed the PHP/HTML output, but never both at the same time. Ultimately, you can never know in advance in which context a language variable will be used. What is right in one place can be wrong somewhere else. For example, an escaped string like 'Pagina\'s' would break an SQL statement like this:
... 'AND field = \'' . $MENU['PAGES'] . '\'';

Most importantly, any changes we make can only affect things within our control—the core package and our addons. This solution would have no effect on older modules or third-party addons. What happens if one of those addons uses the broken variables, which our code can't fix for them?

Therefore, fixing the data in the language files was the only solution that solves the problem universally and for everyone.