WordPress

edytor bloków – serialize_blocks łamie znaczniki HTML w treści

  • 13 sierpnia, 2020
  • 4 min read
edytor bloków – serialize_blocks łamie znaczniki HTML w treści


TLDR: To nie jest zniekształcone, to surowe wartości JSON, które nie zostały zdekodowane i nie są przeznaczone dla nas, ludzi. Najpierw dekoduj JSON przed użyciem.


Dzieje się to w serialize_block_attributesdokument wyjaśnia dlaczego:

/**
...
 * The serialized result is a JSON-encoded string, with unicode escape sequence
 * substitution for characters which might otherwise interfere with embedding
 * the result in an HTML comment.
...
 */

Odbywa się to więc jako środek kodowania, aby uniknąć przypadkowego zamknięcia komentarza HTML przez atrybuty i złamania formatu dokumentu.

Bez tego komentarz HTML wewnątrz atrybutu bloku przerwałby blok, a następnie resztę treści.

Ale jak zatrzymać manipulację?!!!

Nie, to nie jest zniekształcone, to jest zakodowane! Nie należy tego czytać dosłownie, tak trzeba rozszyfrowanie Pierwszy. Koduje określone znaki, zastępując je wersjami ze zmianą znaczenia Unicode, aby zapobiec uszkodzeniu.

To tak, jakby otworzyć kabel światłowodowy i spojrzeć na to, co jest wysyłane, nie zobaczysz stron internetowych, zobaczysz impulsy światła, komputer musi to zdekodować, przetworzyć i przekształcić w informacje przyjazne dla człowieka. Tutaj jest tak samo.

Warto przeczytać!  zapytanie wp — niestandardowa taksonomia w niestandardowym wyszukiwaniu interfejsu API REST

Dowód 1

Weźmy oryginalny blok kodu z pytania i dodajmy następujące poprawki:

  • Zawiń całość <pre> tagi
  • Używać esc_html abyśmy mogli prawidłowo zobaczyć tagi
  • Naprawić printf przez usunięcie var_dump i używanie var_export z drugim parametrem, więc zwraca, a nie wyprowadza
  • Dodaj ostateczny przypadek testowy, w którym ponownie analizujemy i ponownie serializujemy 10 razy, aby porównać wynik końcowy z oryginałem
function reparse_reserialize( string $content, int $loops = 10 ) : string {
    $final_content = $content;
    for ($x = 0; $x <= $loops; $x++) {
        $blocks = parse_blocks( $final_content );
        $final_content = serialize_blocks( $blocks );
    }
    return $final_content;
}

add_action(
    'wp',
    function() {
        $p = get_post( 1 );

        echo '<p>Original content:</p>';
        echo '<pre>' . esc_html( var_export( $p->post_content, true ) ) . '</pre>';

        $final = reparse_reserialize( $p->post_content );

        echo '<p>10 parse and serialize loops later:</p>';
        echo '<pre>' . esc_html( var_export( $final, true ) ) . '</pre>';
        echo '<hr/>';
    },
    PHP_INT_MAX
);

Uruchamiając to, widzimy, że treść przetrwała proces analizy i ponownej serializacji 10 razy. Gdyby występowało zniekształcenie, obserwowalibyśmy coraz większe zniekształcenie

Dowód 2

Jeśli weźmiemy zniekształcony znacznik:

\u003ch3\u003eWhat types of accommodation are available in xxxx?\u003c\/h3\u003e

Zamień go na ciąg JSON, a następnie zdekoduj:

$json = '"\u003ch3\u003eWhat types of accommodation are available in xxxx?\u003c\/h3\u003e"';
echo '<pre>' . esc_html( json_decode( $json ) ) . '</pre>';

Otrzymujemy oryginalny kod HTML:

<h3>What types of accommodation are available in xxxx?</h3>

Zatem nie doszło do żadnego zniekształcenia.

Warto przeczytać!  Niestandardowy typ postu z niestandardową taksonomią w akordeonie Bootstrap 4

Streszczenie

Nie ma manipulacji i korupcji. To po prostu kodowanie < I > aby zapobiec pęknięciu. Procesory JSON dobrze radzą sobie ze znakami ucieczki Unicode.

Jeśli widzisz te zakodowane znaki w edytorze bloków, oznacza to błąd albo w bloku, albo we wtyczce ACF. Powinieneś to zgłosić jako takie.

Jeśli widzisz te zakodowane znaki w swojej pracy, uruchom dekodowanie JSON przed użyciem wartości. Możesz kodować JSON, jeśli chcesz serializować go z powrotem do bazy danych. Pamiętaj, że atrybuty bloków są zwykle przechowywane w formacie JSON w komentarzu HTML, o ile jest to prawidłowy JSON, po jego zdekodowaniu wszystko powinno być w porządku.


Źródło