Drupal WYSIWYG Editors

Es neesmu tik detalizēti pētījis, bet domāju, ka problēma ar tagu filtrēšanu ir drīzāk nevis WYSIWYG editorā, bet gan Drupal. Vai mēģināji uzlikt FullHTML teksta formātu un tad rakstīt tagus?

Es WYSIWYG izmantoju kopā ar WYSIWYG moduli (http://drupal.org/project/wysiwyg), kur vari integrēt vai nu TinyMCE, vai CKEditor, kā arī citus. Taču tas, kā apvienojošais, nedod tik lielas iespējas konfigurēt pašu editoru, kā tiešie/speciālie moduļi. Tomēr izmantojot API, tu vari panākt tieši to funkcionalitāti un izskatu, kas tev ir nepieciešams.

Šajā kontekstā mūsu pašu "gincha" ir šajā lapā izvietojis palīgmoduli, kuru vari izmantot kā piemēru atsperes punktam.

Lai cik WYSIWYG terminoloģija liecinātu par vienu, tomēr šis ir rīks, kas dara tikai noteiktas lietas. Par to var palasīties vairāk netā, piemēram:

• http://wiredcraft.com/blog/avoid-wysiwyg-editors/index.html
• http://webdesign.about.com/od/htmleditors/a/aa031407.htm
• http://webdesign.about.com/od/htmleditors/a/aa080806.htm

Šeit es iezīmētu divas būtiskas problēmas:

1. Specifisko HTML un iframe tagu drošības jautājumi (http://theinsider.deep-ice.com/texts/xss_exposed.txt)
2. Problēmas, ko pārāk vaļīgs WYSIWYG pielietojums var radīt ar lapas dizainu un izkārtojumu

To visu pieminot, protams, katrs var rīkoties pēc saviem ieskatiem, taču specifiskās lietas es labāk liktu kodā vai modulī, nevis vienkārši atļautu visiem lietot FullHTML formātu, un ar WYSIWYG palīdzību radīt lapas izklājumus. Īpašu vērību jāpievērš ir iframe tagiem, kas tomēr ir specifiski jāapstrādā, lai būtu kaut cik kontrolējama situācija visā Drupal lapā. Ja vēlies ievietot video no youtube vai citiem pakalpojuma sniedzējiem, prātīgāk būtu tam izmantot attiecīgu moduli, nevis to izpildīt iekš WYSIWYG, kas dotu iespēju kontrolēt tieši no kuriem saitiem šādi linki vai snipeti var būt ievietoti, kā arī dotu labākas iespējas piemērot šādiem risinājumiem CSS, kas nemainīsies katru reizi, kā tiks ievietots kas jauns vai lieks.

Taču ja esi pārliecināts ko dari, un ja šis FullHTML ir labi kontrolēts (jeb to dari tikai tu pats), tad ir risinājumi, kurus vari saprātīgā veidā izmantot.

Pēc noklusējuma, Drupal pieļauj tikai sekojošus HTML tagus (saistīts ar XSS): http://api.drupal.org/api/drupal/modules!field!field.module/function/_f… (papildus info var palasīt šeit: http://drupal.stackexchange.com/questions/20467/changing-allowed-html-t…).

Tātad, ņemot vērā to, problēma ir cieši saistīta ar to, ko un kā Drupal pieļauj izmantot, un vis ticamāk, tā nav CK.../Tiny... problēma, lai gan fakts, ka šie rīki šobrīd netiek orientēti 100% HTML5 atbalstam.

Lai moduļa veidā risinātu šo filtrēšanas mehānismu, var izmantot sekojošu moduli: http://drupal.org/project/wysiwyg_filter kur attiecīgi web saskarnē definē kas tad tieši un kādiem HTML/CSS elementiem ir atļaujams, un kādā kombinācijā. Visa tā kopējā doma ir saistīta ar to, lai varētu savaldīt un vajadzības gadījumā arī ierobežot kopējo lapas CSS kodu. Citādi sāksies bardaks. Un pirmais, kas sākas, ir ar to, ka lietotāji Body tipa lauciņos ar WYSIWYG sāk kopēt tekstu no MS Word. iFrame arī ne vienmēr dod kontroli no CSS puses.

Katrā gadījumā domāju, ka HTML5 100% atbalsts vēl nebūs visur, jo arī pārlūkos vēl ir nianses, un daudz informācijas tomēr tiek izvietots klasiskajā risinājumā. Bet nu var piesaukt Raini :).

Es domāju, ka būtu jāsāk tev ar HTML filtru, un ja tas nelīdz, tad vienkārši izveido noteiktu nodes templeitu (pie nosacījuma, ka visa ādiņa ir ar HTML5 atbalstu un korekta), un veido pēc vajadzības savā modulī, nevis izmanto WYSIWYG kā iespēju radīt pašas lapas vai raksta kopēju izkārtojumu.

Kā būtu, ja izmantotu parastos tagus ar noteiktu klasi (lai var atrast ar js), un ar JS nomainītu HTML pie lapas ielādes? (kā ideja...)

Pie kura risinājuma attiecībā uz editora iebūvi tu paliki? Tiešie moduļi, vai caur WYSIWYG? Šeit vienu linku netīšām uzgāju (saistībā ar tiešajiem moduļiem), var būt noder pētījumos:

• http://docs.cksource.com/CKEditor_for_Drupal/Open_Source/Drupal_7/Filte…

Man kaut kā liekas, ka tas, kas ir ieslēgts, to noteikti var atslēgt. Jautājums ir tikai, vai to darīt Drupal pieņemamā veidā un formā, vai tomēr ķimerēt redaktora tekstu un config failus.

Var būt kā alternatīva ir izmantot Whitelist plaginu. Jāskatās tikai, vai jaunajā versijā tas darbojas:

• http://alfonsoml.blogspot.com/2012/05/white-list-of-elements-and-attrib…

Paldies j2b par izsmeļošām atbildēm! Man nav daudz ko piebilst. illusio, kāds ir FB standarta kods, ko mēģini ielikt?

Pamēģināju CKEditor-4+wysiwyg, nu vēl jāpagaida, kamēr wysiwyg moduli pielabos, jo 4ajā versijā editoram ir lielas izmaiņas (inline editing arī tur ir). Var jau uzlikt un salāpīt versijas atpazīšanu un pogas vairākās rindās, bet nu tas vēl nav dzīvotājs. Šodien padzirdēju, ka Drupal8 nebūs Aloha, bet CKEditor 4.

CKEditor-3.x atbalsta HTML5 tagus.  Cita lieta, vai tas atverot kodu māk to apstrādāt tā, lai editorā to attēlotu. Piemērs tam, kas tur īsti notiek, ir teaser brake plugin.  Izmēģināju to pašu fb kodu, editors neko nepazaudē. Ja tā var teikt, pazūd vizuālais kontakts :)

Es arī nenoturējos :) Jāsaka, ka CKEditors ir palicis pēc būtības daudz patīkamāks. Versijas jautājumu tiešām var salāpīt, taču teksta līdzināšanas pogas pazūd. Tālāk neķēpājos. Patika arī ideja par Bilderi, kur var salasīt to, kas vajadzīgs, no nepumpēt lieku (http://ckeditor.com/builder)

Aloha puišiem gan sanāca aplauziens. Tā jau domāja, ka būs ok, ja kāds no plašajiem CMS tos varētu ielikt korē, bet nu - neko darīt. Katrā gadījumā Inline edit funkcija šķiet vilinoša pamatā jau lietotāju ērtības dēļ un arī dēļ tam, lai patiešām WYSIWYG padarītu pēc būtības tuvāku. Taču piekritīšu arī viedoklim, ka no izstrādes puses skatoties, tas uzliks papildus slogu un formu validāciju, izklājumiem, un pārējiem pričendāļiem. Dzīvosim - redzēsim.