Oprește Wordpress să elimine tag-urile <script> când comutați de la HTML la Visual (TinyMCE)
Ok, am văzut soluții care rezolvă parțial această problemă, dar nimic definitiv și nimic care să rezolve 100% problema mea.
Scenariu:
- În modul HTML, adaug JavaScript într-o postare pe care o editez.
- Comut la Visual, apoi înapoi la HTML, iar tag-ul script și tot conținutul său dispar.
Cum pot opri acest comportament? Am încercat să adaug cod personalizat în functions.php încercând să accesez extended_valid_elements pentru TinyMCE, dar nimic nu funcționează.
Vă rog să mă ajutați!
Acest lucru poate fi realizat destul de ușor prin acordarea capacității unfiltered_html
rolului pe care doriți să îi permiteți utilizarea tag-urilor SCRIPT și IFRAME. Evident, așa cum au menționat și alții, există riscuri de securitate inerente, așa că fiți precaut în această privință.
Pentru a afla mai multe despre acordarea capacităților, consultați intrarea din WordPress Codex despre add_cap().

Adăugarea de JS în conținut este o practică foarte, foarte proastă și practic inviți hackerii să atace.
Adaugă-l folosind un shortcode, sau dacă chiar trebuie, folosește un câmp personalizat (post meta/custom field) pentru a stoca JS-ul și afișează-l după conținut în template folosind echo get_post_meta($post->ID,'post_javascript',true );

Hei Tom, cred că ar fi foarte util dacă ai putea oferi niște dovezi cu privire la de ce aceasta este o practică proastă și de ce solicită să fie hack-uit!

deoarece oricine poate introduce orice în conținutul tău, fie că e ceva care face ca hyperlink-urile tale să clipească, fie ceva care realizează un drive by download. Oricine are acces la baza ta de date sau drepturi de editare a postărilor poate folosi site-ul tău pentru a răspândi javascript malitios

De asemenea, amestecă conținutul/datelor cu funcționalitatea/controlerele și face ca conținutul tău să nu fie portabil între teme, deoarece schimbarea temelor ar strica conținutul.

ex. "Salut, acesta este primul meu articol pe blog! <script>window.location="www.hackme.com/installtrojan";</script>"

Aș argumenta că "oricine are acces la baza ta de date sau drepturi de editare a postărilor" poate să-ți strice ziua oricum, iar implementarea acestui lucru prin shortcode sau post meta nu ar face nicio diferență în ceea ce privește securitatea. De asemenea, nu văd cum shortcode-urile sau post meta ar separa conținutul/datelile de funcționalități/controlori mai mult decât ceea ce întreabă @Buckers. Cred că acesta este un comportament implicit bun pentru WordPress, nu mă înțelege greșit, dar personal nu văd niciun rău în a suprascrie acest comportament cu consimțământ informat, nici nu văd vreun avantaj de securitate sau ortogonalitate în ceea ce propui. Dar, hei, poate greșesc?

Cu un shortcode nu pot introduce orice cod JS, ci doar codul JS pe care intenționezi să-l permiți, deoarece pentru a adăuga cod JS nou aș avea nevoie de acces la fișierele PHP care implementează acel shortcode. Din același motiv, introducerea de PHP în conținutul postărilor este o practică de securitate execrabilă, dar asta nu înseamnă că nu poți folosi PHP pentru a implementa shortcode-uri (nu susțin implementarea de shortcode-uri de genul [js][/js]
deloc, acelea sunt la fel de rele).

Ah, scuze, am interpretat greșit sugestia ta. Te înțeleg acum; vorbești despre folosirea shortcode-urilor sau a meta datelor articolului pentru a colecta parametri, nu a JS în sine, de exemplu specificând un ID, URL-ul unei imagini, orice. Ai dreptate, răspunsul se schimbă radical în funcție de ceea ce @Buckers încearcă să realizeze!

Am răspuns la postarea mea inițială de mai sus cu cerința mea principală pentru asta. În prezent, sunt singurul cu acces de administrator la site. Indiferent de preocupările legate de securitate, aș dori doar să știu dacă este posibil să fac asta - iar privind acest răspuns, se pare că ar putea fi posibil.

Este posibil, în același mod în care ai putea să-ți conduci mașina prin explozii direcționate din spate care să o împingă înainte, sau să lași pachete mai mari să intre prin cutia poștală dacă înlături ușa de la intrare. Dacă cauți o metodă simplă de a introduce coduri arbitrare AdSense în conținut, există modalități mult mai bune de a face asta. Caută o soluție pentru problema ta, nu o remediere pentru soluția ta defectuoasă.

Fără a modifica codul PHP al șabloanelor, puteți rezolva problema menționată de OP - precum și problema în care pe un site multisite nimeni altcineva în afară de super-administrator nu primește capabilitatea unfiltered_html
menționată de @Tom Auger - prin instalarea plugin-ului "Shortcoder". Acesta vă permite să creați "scurtcoduri personalizate" care pur și simplu afișează un text. Acesta poate fi orice - inclusiv Javascript.
Eu creez un "scurtcod personalizat" pentru fiecare fragment de cod de care am nevoie (de obicei unul pentru fiecare cod personalizat distinct al unei pagini) și apoi editorul vizual vede scurtcodul și nu îl elimină.
De asemenea, este excelent pentru reutilizarea codului Javascript, dacă aveți mai multe pagini care necesită același (sau un cod similar).

pare foarte nesigur pe multisite (orice permite introducerea de HTML nefiltrat este) și, în orice caz, nu pare să mai fie susținut de autor

@MarkKaplun - Nu sunt sigur de ce spui că plugin-ul nu este susținut. Nu a fost actualizat recent, dar probabil asta se întâmplă pentru că autorul este ocupat cu alte lucruri (vezi postările sale pe alte forumuri). Oricum, funcționează bine pe versiunea 4.7.

Referitor la problema de securitate - tot văd răspunsuri pe acest site care spun "nu este sigur să faci asta sau aia, așa că nu o face". Cred că cei care răspund ar trebui să înceteze să își impună modelul de securitate altor utilizatori. Dacă administratorul a decis să instaleze un plugin și să îl facă disponibil, aș presupune că a luat în considerare implicațiile de securitate. Pe configurația mea WPMS, toți utilizatorii sunt de încredere (îi creez manual), așa că dacă aleg să fac plugin-ul Shortcoder disponibil, este pentru că am analizat considerațiile de securitate și acestea sunt acceptabile. Mă aștept ca majoritatea instalărilor WPMS să fie în aceeași categorie.

99,9% dintre utilizatorii WordPress nu au nici o înțelegere a implicațiilor de securitate ale acțiunilor lor. Utilizatorii nu sunt niciodată de încredere, problema este că o vei descoperi doar după fapt, când va fi extrem de greu să te recuperezi.

În ceea ce privește plugin-ul, dacă autorul nu se obosește să actualizeze fișierul readme pentru a indica că ar trebui să funcționeze pe o versiune lansată acum 3 luni, acesta este un bun indiciu că și-a pierdut interesul pentru plugin.

Deoarece WPMS este atât de greu de instalat (trebuie să editezi fișiere de configurare non-triviale), aș fi tentat să susțin că nivelul administratorilor WPMS este oarecum mai ridicat decât al editorului WordPress obișnuit. Cel mult poți explica implicațiile de securitate (care, apropo, nu ai explicat de ce consideri că Shortcoder este o problemă pe multisites). În ceea ce privește problema suportului - cred că a lua ceea ce ai spus ca un indiciu este puțin exagerat - eu personal susțin câteva plugin-uri WordPress, de obicei nu am timp să le testez pe ultima versiune WordPress pentru fiecare lansare, sau uneori nici măcar o dată pe an.

și doar pentru a înțelege de ce utilizatorii nu sunt de încredere, chiar dacă îi cunoști personal... Ești sigur că nu folosesc "123456" ca parolă? Îți permiți să lași nepotul lor să folosească computerul, etc.? Nu limitezi utilizatorii pentru că ar putea fi oameni răi, îi limitezi pentru a reduce vectorii unei breșe de securitate care va avea un impact mai mare decât doar contul lor

Să continuăm această discuție în chat.

Începând cu 2024, puteți permite HTML nefiltrat în wp-config.php setând DISALLOW_UNFILTERED_HTML la false astfel:
define( 'DISALLOW_UNFILTERED_HTML', false );
Referitor la aspectele de securitate: Activarea HTML-ului nefiltrat prin setarea DISALLOW_UNFILTERED_HTML la false necesită încredere în administratorii dvs. și conștientizarea securității, deoarece le permite să insereze cod potențial dăunător. Cu toate acestea, dacă un hacker obține acces la WordPress-ul dvs., implicațiile de securitate sunt grave indiferent de această setare.

Există și o soluție pentru cei care folosesc pluginul Elementor și nu doresc să instaleze pluginuri suplimentare:
- Din meniul de administrare, accesați Templates > Add New
- Alegeți "Container" ca tip de șablon și denumiți-l în mod convenabil pentru a-l recunoaște ulterior în cazul editărilor (dacă este necesar).
- Pe ecranul editorului Elementor, faceți clic pe semnul + pentru a adăuga un container și introduceți un widget de tip HTML code în interiorul acestuia.
- Lipiți scriptul în caseta HTML. (Rețineți că acesta trebuie să fie înconjurat de tag-urile
<script></script>
) - Salvați și ieșiți înapoi la lista de containere. (Templates > Saved Templates > Containers)
- Localizați șablonul nou creat și copiați shortcode-ul din caseta din fața acestuia.
- Lipiți acest shortcode în orice editor de text și bucurați-vă de rezultat.
