Swobodnie przełączaj się między kartami Visual i HTML

Pytanie to było podnoszone wiele razy pod różnymi flagami, jednak chciałbym przedstawić zunifikowany wątek, aby uzyskać najlepsze rozwiązanie tego problemu.

W WordPress domyślnie podczas przełączania między edytorami HTML i Visual w TinyMCE niektóre tagi są usuwane z treści i występują inne dziwne funkcje. Dwa znane obejścia dotyczące pisania bardziej wydajnego kodu HTML polegają na usunięciu funkcji wp_auto_p za pomocą filtrów oraz zainstalowaniu TinyMCE Advanced i włączeniu opcji „przestań usuwać tagi p & br”.

Niestety działa to tak dobrze.

Weźmy na przykład następujący przykład:

<h2>How does it work?</h2>
<p>In order to use jQuery Easy Columns, you must install it as you would any other jQuery plugin.  First, download the zip file using the button above.  After downloading the file, extract it to a location of your choice, and move the extracted folder to your server using your favorite FTP client.  After moving the plugin to your server (and of course calling the jQuery source into your document), call it in on your site using the following snippet of code:</p>
<pre>
&lt;script type=&quot;text/javascript&quot; src=&quot;/path/to/jquery.easycolumns.js&quot;&gt;&lt;/script&gt;
</pre>

Jeśli wpiszę ten kod do edytora HTML, a obie opcje wymienione powyżej są już włączone, to po przełączeniu się między dwoma różnymi edytorami nic się nie dzieje, czego można się spodziewać. Niestety podczas zapisywania kod automatycznie konwertuje się na:

<h2>How does it work?</h2>
<p>In order to use jQuery Easy Columns, you must install it as you would any other jQuery plugin.  First, download the zip file using the button above.  After downloading the file, extract it to a location of your choice, and move the extracted folder to your server using your favorite FTP client.  After moving the plugin to your server (and of course calling the jQuery source into your document), call it in on your site using the following snippet of code:</p>
<pre>
<script type="text/javascript" src="/path/to/jquery.easycolumns.js"></script>
</pre>

Jak widać, wszystkie elementy wewnątrz tagu wstępnego są konwertowane z powrotem na rzeczywiste znaki HTML. Następnie, jeśli ponownie zapiszę ten sam post, otrzymuję coś takiego:

<h2>How does it work?</h2>
<p>In order to use jQuery Easy Columns, you must install it as you would any other jQuery plugin.  First, download the zip file using the button above.  After downloading the file, extract it to a location of your choice, and move the extracted folder to your server using your favorite FTP client.  After moving the plugin to your server (and of course calling the jQuery source into your document), call it in on your site using the following snippet of code:</p>
<pre><br />
<script type="text/javascript" src="/path/to/jquery.easycolumns.js"></script><br />
</pre>

Zauważ, że Wordpress faktycznie wstrzykuje tagi br do postu. Nie trzeba dodawać, że po kilkakrotnym zaktualizowaniu tego postu podczas wyświetlania go na interfejsie wyświetlacz nie jest w pobliżu zamierzonego wyświetlacza.

Jedynym sposobem, w jaki pozbyłem się wszystkich dodanych „funkcji formatowania”, było wyłączenie edytora Visual w moim profilu.

To dla mnie dobre rozwiązanie, biorąc pod uwagę, że jestem profesjonalnym programistą. Dla moich klientów to rozwiązanie nie jest eleganckie. Moi klienci będą w przeważającej części korzystać z edytora wizualnego. Wielu moich klientów nie jest zbyt obeznana z technologią i czasami potrzebuje mnie, aby naprawić swoje posty, gdy układ się psuje. Ogranicza mnie to do korzystania z edytora wizualnego, ponieważ nie mogę przejść do edytora HTML bez obawy o uszkodzenie układu.

Głównie (i myślę, że istnieje duża społeczność, która mogłaby skorzystać z tej odpowiedzi), jakie wyraźne kroki mogę wykonać, aby zapewnić:

1. Wpis można edytować za pomocą edytora Visual lub HTML.
2. Treść postu nie jest w żaden sposób modyfikowana podczas przełączania między dwiema zakładkami.
3. Podczas zapisywania posta z edytora HTML nie jest dodawana żadna dodatkowa treść.
4. Podczas zapisywania posta z edytora HTML żadne podmioty nie są konwertowane.
5. BONUS: Podczas zapisywania posta z edytora HTML każdy kod (na przykład HTML) zawinięty w tagu wstępnym i jeszcze nie przekonwertowany na encje zostanie automatycznie przekonwertowany na encje.

Zasadniczo, jeśli możemy stworzyć powyższe zachowanie w TinyMCE za pomocą wtyczki innej firmy, możemy stłumić wszystkie inne pytania dotyczące fałszywego formatowania za pomocą TinyMCE. Czuję, że wiele osób mogłoby z tego skorzystać.

Po prostu wydaje się logiczne, że istnieje pewna funkcjonalność, jakiej można oczekiwać od edytora WYSIWIG, i to wbrew temu. Zgodnie z całą logiką i rozumem wbudowane funkcje formatowania Wordpress są dość bezużyteczne w ich obecnej konfiguracji. Wydaje mi się, że jeśli chcą skorzystać z tych opcji formatowania, najlepiej postawić jeden lub drugi edytor, a nie oba.

I PROSZĘ: Nie odpowiadaj na ten wątek, stosując obejścia i pliki do pobrania dla innych edytorów WYSIWIG, które „naprawiają” problem. Jest to podstawowy problem (choć nie tak naprawdę błąd) związany z rdzeniem Wordpress, który należy naprawić.

EDYCJA : W porządku, pracowałem nad tym i myślę, że inżynieria odwrotna będzie najlepszym sposobem rozwiązania tego problemu. Na razie więc wyłączyłem wpautop (która tylko dla przejrzystości jest funkcją, która łączy się z filtrem „the_content”, aby dodać tagi p i br przed wyświetleniem tekstu , a nie po zapisaniu tekstu. Myślę, że istnieje pewne zamieszanie jak działa ta funkcja. wpautop nie ponosi odpowiedzialności za zmiany, które widzisz, kiedy zmieniasz karty edytora. To coś zupełnie innego.

W każdym razie wyłączyłem wpautop, co jest dobrą praktyką podczas korzystania z edytora HTML. Od tego momentu wyłączyłem edytor wizualny, aby zacząć od błędów encji HTML, które występują podczas zapisywania postu. Dzięki pomocy jednego C. Bavota znalazłem fragment kodu do konwersji dowolnych tagów w edytorze HTML na odpowiadające im jednostki przed wyświetleniem ich w interfejsie strony (kredyt: http://bavotasan.com/2012/convert -pre-tag-content-to-html-podmiotów-w-wordpress / ).

#add_filter( 'the_content', 'pre_content_filter', 0 );
/**
 * Converts pre tag contents to HTML entities 
 *
 * This function is attached to the 'the_content' filter hook.
 *
 * @author c.bavota
 */

function pre_content_filter( $content ) {
        return preg_replace_callback( '|<pre.*>(.*)</pre|isU' , 'convert_pre_entities', $content );
}


function convert_pre_entities( $matches ) {
        return str_replace( $matches[1], htmlentities($matches[1] ), $matches[0] );
}

add_filter( 'the_content', 'pre_content_filter', 10, 2 ); 

To skutecznie eliminuje problemy z konwersją wszystkich elementów na znaczniki podczas zapisywania przez Wordpress. Teraz możesz używać edytora HTML i pisać standardowy kod między znacznikami „pre” bez samodzielnej konwersji encji. To zajmuje się wszystkimi problemami z konwersją encji w Wordpress i zapewnia, że ​​wszystko wyświetla się poprawnie w interfejsie. Teraz musimy dowiedzieć się, w co się podłączyć, aby zmodyfikować zachowanie występujące podczas klikania w obie strony między kartami. W tej chwili wydaje się, że po przejściu z HTML do karty wizualnej zawartość karty HTML jest interpretowana przez javascript lub coś, co ma na celu zapewnienie aktualizacji na żywo tego, jak powinna wyglądać treść. Powoduje to, że tagi (które są wyświetlane w formie nieistniejącej na karcie HTML) są przetwarzane zamiast wyświetlane. Następnie, przy ponownym przejściu do zakładki HTML wydaje się, że TinyMCE przekazuje bieżące dane. Oznacza to, że po przełączeniu utracisz strukturę HTML. Musimy wymyślić sposób, aby TinyMCE przekonwertować wszystko w tagach wstępnych na równoważne elementy przed załadowaniem go do okna (w zasadzie wersja backendowa tego, co zrobiliśmy na interfejsie użytkownika, ale z tinymce i javascript zamiast php i hooków), dzięki czemu jest wyświetlany zamiast przetwarzany. Propozycje? s równoważne byty przed załadowaniem go do okna (zasadniczo backendowa wersja tego, co zrobiliśmy na frontendie, ale z tinymce i javascript zamiast php i hookami), dzięki czemu jest wyświetlany zamiast przetwarzany. Propozycje? s równoważne byty przed załadowaniem go do okna (zasadniczo backendowa wersja tego, co zrobiliśmy na frontendie, ale z tinymce i javascript zamiast php i hookami), dzięki czemu jest wyświetlany zamiast przetwarzany. Propozycje?

EDYCJA 2 :

Po kilku dalszych badaniach konwersja encji w tagu wstępnym, gdy są wyświetlane, działa dobrze w przypadku treści w tagu wstępnym, ale powiedz, że mam wpis na blogu z linią taką jak ta:

„Następnie musimy dodać tę linię do naszego pliku HTML: <p> Witaj, świecie! </p>”

Patrząc na ten wiersz, możesz stwierdzić, że kod powinien być wyświetlany w witrynie, a nie analizowany, jednak po zapisaniu wpisu podmioty te są dekodowane przy następnym ładowaniu edycji wpisu i przy każdym kolejnym zapisie są zapisywane jako nieprzetworzone tagi HTML, co powoduje ich parsowanie na interfejsie. Jedynym rozwiązaniem, jakie do tej pory wymyśliłem, byłoby napisanie podobnego kodu dla znacznika „code”, którego używam w wersji wstępnej, a następnie po prostu owinięcie małych linijek w znacznik „code”, a dużych fragmentów w Tag „pre”. Czy masz jeszcze jakieś pomysły?

W porządku, więc już zaktualizowałem to pytanie tonę i zaczyna się przeciążać, więc pomyślałem, że napiszę to jako odpowiedź, nawet jeśli nie jest pełne.

Ekstrapolując z odpowiedzi @ bueltge, wróciłem i znalazłem jego poprzedni post. W tym poście wymieniono wtyczkę, której nigdy wcześniej nie widziałem: „Zachowane znaczniki edytora HTML”. Ta wtyczka nie była aktualizowana przez jakiś czas, ale właśnie przetestowałem ją z WP 3.6.1 i jest w pełni funkcjonalna. Ta wtyczka automatycznie zajmuje się wpautop, zapewnia ujednolicony format wstawiania znaczników br i p w edytorze wizualnym i zachowuje znaczniki podczas przełączania między kartami.

Na własne potrzeby rozwinąłem tę wtyczkę z własną funkcjonalnością: automatyczna konwersja dowolnych tagów HTML w tagach „<code>” na ich odpowiednie encje po zapisaniu. Oznacza to, że możesz napisać standardowy kod HTML w znacznikach kodu na karcie tekstowej, a następnie zapisać go, a wszystkie elementy w tagach wstępnych zostaną przekonwertowane na jednostki w celu poprawnego wyświetlenia na interfejsie witryny i edytorze wizualnym. To nie jest najbardziej eleganckie rozwiązanie, jakie do tej pory znalazłem, ale wydaje się, że działa. Dodaj ten wiersz do swojego functions.php po aktywacji wtyczki:

function code_content_conversion_filter( $content ) {
        return preg_replace_callback( '|<code.*>(.*)</code|isU' , 'convert_entities', $content );
}

function convert_entities( $matches ) {
        return str_replace( $matches[1], htmlspecialchars($matches[1], ENT_QUOTES | ENT_HTML5, 'UTF-8', FALSE ), $matches[0] );
}

add_filter( 'content_save_pre', 'code_content_conversion_filter', 0);

Teraz po prostu wpisz poprawny kod HTML pomiędzy znaczniki kodu, a kiedy zapiszesz, gdy edytor pojawi się ponownie, wszystkie zostaną przekonwertowane na jednostki. Pozwala to na szybsze pisanie kodu. Teraz jedyną kwestią, która nadal stanowi problem, jest to, że jeśli masz pole „wstępne” z zagnieżdżonym znacznikiem kodu i HTML, a następnie przejdziesz do karty wizualnej i spróbujesz wstawić nową linię do kodu, znacznik br zostaje wstrzyknięty do tagu kodu w kodzie HTML. Musi istnieć opcja wyłączenia tego w TinyMCE. Niezależnie od tego, dopóki edytujesz pola wstępne z karty tekstowej, możesz swobodnie przełączać się między kartami, dodawać dowolne treści pod dowolną kartą, zapisywać z dowolnej karty i nie martwić się o pomieszane formatowanie!

To faktycznie rozwiązuje wszystkie 5 punktów mojego początkowego pytania. Punkt 2 jest nadal nieco niestabilny, ale uważam, że dla większości ludzi rozwiązuje to problem. Planuję w pewnym momencie przejrzeć tę wtyczkę i wyodrębnić niezbędne części, połączyć je z moimi znaleziskami i ponownie zapakować do publicznego pobrania. Moim celem jest tutaj utworzenie prostej wtyczki instalacyjnej, która będzie działać zgodnie z oczekiwaniami.

Mam nadzieję, że to pomoże wszystkim!

Na początku myślę, że ten problem został rozwiązany od wersji WP 3.5; patrz bilet 19666 w trac . Ale tinyMCE ma tam haczyk, który daje nam szansę na zmianę treści w edytorze i nie możesz analizować danych wyjściowych na interfejsie.

Mały skrypt źródłowy. Nie testowałem tego z aktualną wersją WP, było to starsze rozwiązanie dla klienta.

Dodaj to źródło za pomocą wtyczki i popraw znaczniki. Kontrola działania znacznika html <prei jeśli istnieje, zostanie zastąpiona znacznikiem.

add_filter( 'tiny_mce_before_init', 'fb_correction_content_tiny_mce' );

function fb_correction_content_tiny_mce( $init ) {

    $init['setup'] = "function(ed) {
        ed.onBeforeSetContent.add( function(ed, o) {

            if ( o.content.indexOf('<pre') != -1 ) {
                o.content = o.content.replace(
                    /<pre[^>]*>[\\s\\S]+?<\\/pre>/g,
                    function(a) {
                        return a.replace(/(\\r\\n|\\n)/g, '<br />');
                    }
                );
            }
        } );
    }";

    return $init;
}

Miałem problem podobny do PO, ale dla mnie nie było problemu z utrzymaniem <h1>się <div>. Oto, co chciałem zachować podczas przełączania między kartami Tekst i Obraz:

Za każdym razem, gdy przełączałem, karta <h1>znikała. Dużo szukałem, a dla Wordpress 4.7.3 odkryłem, że jest wiele przestarzałych poprawek. Nastąpiła aktualizacja burmistrza TinyMCE z wersji 3 do 4. Rozwiązania dla v.3 nie działały dla v.4. Po kolejnych przeglądaniach i przeczytaniu oryginalnej dokumentacji TinyMCE w wersji 4 wymyśliłem rozwiązanie szczególnie dla mojej sprawy:

1. Zainstaluj wtyczkę Advanced TinyMCE Configuration
2. ustaw valid_childrenustawienie TinyMCE na+div[h1],h1[div]
3. I additonnaly skonfigurowane indent=true, forced_root_block=falsei schema=html5(kiedy odczytać forced_root_blockOpis I rozumieć jako wpautopsubstytut)

W rezultacie otrzymuję to (i jest odporny na przełączanie kart)