Content_Typ erweitern um "CMS_Input"
Content_Typ erweitern um "CMS_Input"
Hallo,
ich habe bei vielen Seiten diverse Module in Artikeln die sich nur um ein oder zwei Werte zu den Template-Konfigs unterscheiden.
Zum Verständnis:
Ich bin dabei meine Module so zuschreiben das fast alles über den Editor eingestellt werden kann. Natürlich nicht alles.
Beispiel: Article-List-A.
Hier teile ich es auf in:
- System bedingte-Einstellungen (nur für Admins & SysA.)
> Beispiel-Artikel, Elemente,
- Konfigurationen
> Sortierung, Artikel pro Seite, Template
- Dynamischer Inhalt
> Hauptkategorie
Bei diesem Beispiel würde ich gerne die Auswahl der Hauptkategorie in den Editor verlagern. Leider kann ich (soweit ich weiss) nur CMS-Typen verwenden die mit Div-contenteditable = true ist.
Das bedeutet für mich momentan den Inhalt aus dem div (CMS_HTML) mit Regex extrahieren muss und dann verwenden kann. Und beim Speichern über JS den inhalt des Div austauschen muss. Dabei geht aber immer ein HTML-Feld drauf und die Einstellung kann auch über die Suche gefunden werden. Wo bei dieser Inhalt nix mit dem Artikel-Content zutun hat.
Kennt jemand einen anderen Lösungsansatz?
(der nicht direkt auf die DB greift sondern mit Core-Funktionen funktioniert)
mfg Oliver
ich habe bei vielen Seiten diverse Module in Artikeln die sich nur um ein oder zwei Werte zu den Template-Konfigs unterscheiden.
Zum Verständnis:
Ich bin dabei meine Module so zuschreiben das fast alles über den Editor eingestellt werden kann. Natürlich nicht alles.
Beispiel: Article-List-A.
Hier teile ich es auf in:
- System bedingte-Einstellungen (nur für Admins & SysA.)
> Beispiel-Artikel, Elemente,
- Konfigurationen
> Sortierung, Artikel pro Seite, Template
- Dynamischer Inhalt
> Hauptkategorie
Bei diesem Beispiel würde ich gerne die Auswahl der Hauptkategorie in den Editor verlagern. Leider kann ich (soweit ich weiss) nur CMS-Typen verwenden die mit Div-contenteditable = true ist.
Das bedeutet für mich momentan den Inhalt aus dem div (CMS_HTML) mit Regex extrahieren muss und dann verwenden kann. Und beim Speichern über JS den inhalt des Div austauschen muss. Dabei geht aber immer ein HTML-Feld drauf und die Einstellung kann auch über die Suche gefunden werden. Wo bei dieser Inhalt nix mit dem Artikel-Content zutun hat.
Kennt jemand einen anderen Lösungsansatz?
(der nicht direkt auf die DB greift sondern mit Core-Funktionen funktioniert)
mfg Oliver
der wohl beste ansatz ist das schreiben eines eigenen CMS_XYZ. am besten nimmst du das CMS_TEXT als ansatz.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
Habe als Vorlage CMS_HTML aus con 4.6.23 genommen. CMS_HTML erschin mir einleuchtender denn dort wird schon per $edit auf den Edit-Modus eingegangen.kummer hat geschrieben:... am besten nimmst du das CMS_TEXT als ansatz.
So hab das mal eben schnell gemacht. Leider kommt man nicht drum rum etwass im Core zuändern (Was mir immer ein Dorn im Auge ist, da nicht Updatefähig).
Im Edit-Modus wird der Text durch ein Input-Feld ersetzt und ähnelt dem "CMS_HTML"-Feld.
Der Platzhalter für Module lautet: CMS_HTMLINPUT[ID]
Der Save-Button kann per CSS ausgeblendet werden wenn man folgenden style setzt:
a.CLASS_19_ID_s { display: none; }
Hier mal die entsprechenden Felder in der "con_type" inkl. Kommentar.
CMS_HTMLINPUT
idtype
19
-> nächst höhere ID (ist freiwählbar)
type
CMS_HTMLINPUT
(vergleichbar mit CMS_IMG_DESC)
-> Ich hätte gerne CMS_INPUT gemacht aber funktioniert mit den JS-Funktionen nicht. Das Feld muss mit "CMS_HTML"... anfangen
code
-> s. unten SQL-Query
Da zum speichern der Variablen alle HTML- und HTMLHead-Felder kopiert und in eine Post-Variable gesteckt werden (mit "innerHTML" die nicht bei Input funktioniert) ergibt sich leider folgende Änderung im Code.
Im File: include.con_editcontent.php
JS-Funktion: setcontent()
Zeile: ca. 145
ersetzt: var aContent = prepareString(a.innerHTML);
Code: Alles auswählen
// read out the content
if( a[i].tagName == 'INPUT' ) {
var aContent = prepareString(a[i].value);
}
else {
var aContent = prepareString(a[i].innerHTML);
}
CMS_VALUEINPUT
idtype
20
-> nächst höhere ID (ist freiwählbar)
type
CMS_VALUEINPUT
(vergleichbar mit CMS_IMG)
code
-> s. unten SQL-Query
mfg OliverL
Nicht vergessen die Tabelle "con_sequence" anzupassen auf +2.
Code: Alles auswählen
-- phpMyAdmin SQL Dump
-- version 2.8.2
-- http://www.phpmyadmin.net
-- Erstellungszeit: 11. Juli 2008 um 10:19
-- Server Version: 4.1.20
-- PHP-Version: 4.4.7
-- Daten für Tabelle `con_type`
INSERT INTO `con_type` (`idtype`, `type`, `code`, `description`, `status`, `author`, `created`, `lastmodified`) VALUES (19, 'CMS_HTMLINPUT', '/**\r\n * CMS_HTMLINPUT\r\n */\r\n\r\n$tmp = $a_content[''CMS_HTMLINPUT''][$val]; \r\n$tmp = urldecode($tmp); \r\n\r\n$tmp = AddSlashes(AddSlashes($tmp)); \r\n$tmp = str_replace("\\\\\\''","''",$tmp); \r\n$tmp = str_replace("\\$",''\\\\\\$'',$tmp); \r\n\r\ncInclude("includes", "functions.lang.php"); \r\ncInclude("classes", "class.htmlelements.php"); \r\n\r\nif ($edit) { \r\n\r\n $insiteEditingInput = new cHTMLTextbox("HTMLINPUT_".$db->f("idtype")."_".$val, "_REPLACEMENT_", '''', '''', "HTMLINPUT_".$db->f("idtype")."_".$val);\r\n $insiteEditingInput->setClass("CLASS_".$db->f("idtype")."_".$val);\r\n $insiteEditingInput->setStyleDefinition("border", "1px dashed #bfbfbf"); \r\n $insiteEditingInput->setStyleDefinition("direction", langGetTextDirection($lang));\r\n $insiteEditingInput->updateAttributes(array("contentEditable" => "true")); \r\n\r\n /* Save anchor and image */ \r\n $saveAnchor = new cHTMLLink; \r\n $saveAnchor->setClass("CLASS_".$db->f("idtype")."_".$val."_s");\r\n $saveAnchor->setLink("javascript:setcontent(''$idartlang'',''0'')"); \r\n \r\n $saveButton = new cHTMLImage; \r\n $saveButton->setSrc($cfg["path"]["contenido_fullhtml"].$cfg["path"]["images"]."but_speichern.gif"); \r\n $saveButton->setBorder(0); \r\n \r\n $saveAnchor->setContent($saveButton); \r\n\r\n /* Process for output with echo */ \r\n $insiteEditingInput = $insiteEditingInput->render(); \r\n $insiteEditingInput = AddSlashes(AddSlashes($insiteEditingInput)); \r\n $insiteEditingInput = str_replace("\\\\\\''","''",$insiteEditingInput); \r\n $insiteEditingInput = str_replace("_REPLACEMENT_", $tmp, $insiteEditingInput); \r\n \r\n $finalSaveButton = $saveAnchor->render(); \r\n $finalSaveButton = AddSlashes(AddSlashes($finalSaveButton)); \r\n $finalSaveButton = str_replace("\\\\\\''","''",$finalSaveButton); \r\n \r\n $tmp = $insiteEditingInput . $finalSaveButton;\r\n}', 'Input / Form', 0, 'OliverL', '2008-07-04 09:17:00', '2008-07-04 09:17:00'),
(20, 'CMS_VALUEINPUT', '/**\r\n * CMS_HTMLINPUT\r\n */\r\n\r\n$tmp = $a_content[''CMS_HTMLINPUT''][$val]; \r\n$tmp = urldecode($tmp); \r\n\r\n$tmp = AddSlashes(AddSlashes($tmp)); \r\n$tmp = str_replace("\\\\\\''","''",$tmp); \r\n$tmp = str_replace("\\$",''\\\\\\$'',$tmp);', 'Value / Form', 0, 'OliverL', '2008-07-04 09:17:00', '2008-07-04 09:17:00');
Zuletzt geändert von OliverL am Fr 11. Jul 2008, 10:21, insgesamt 1-mal geändert.
Fast vergessen!
Nicht vergessen die Tabelle "con_sequence" anzupassen auf +2.
Nicht vergessen die Tabelle "con_sequence" anzupassen auf +2.
Code: Alles auswählen
UPDATE con_sequence SET nextid = '20' WHERE seq_name = con_type LIMIT 1 ;
Zuletzt geändert von OliverL am Fr 11. Jul 2008, 10:23, insgesamt 1-mal geändert.
Ähm, die idtype ist nicht ganz frei wählbar. Denk daran was passiert wenn contenido in einer zukünftigen Version standardmäßig einen Type mit der id 19 mitliefert.
Besser wäre eine hohe id. Es gab mal irgendwo eine Empfehlung, find ich aber nicht mehr. Ich benutze immer im 3000er Bereich.
Besser wäre eine hohe id. Es gab mal irgendwo eine Empfehlung, find ich aber nicht mehr. Ich benutze immer im 3000er Bereich.
Bis dann
Tono
Tono
Moin tono
Ich kenne die Empfehlung die ID mit +10000 zu ergänzen.
Aber ich bin immer noch voller Hoffnung das sollten Daten beim Update ergänzt werden die Funktion ->nextid() genutzt wird besonders bei Datenfeldern bei der die ID keine Relevanz/Verknüpfung mit anderen Daten hat.
+ Da sollte man Änderungen machen (besonders die im Core) diese auch mit geloggt werden (in einem eigenem File).
mfg Oliver
Ich kenne die Empfehlung die ID mit +10000 zu ergänzen.
Aber ich bin immer noch voller Hoffnung das sollten Daten beim Update ergänzt werden die Funktion ->nextid() genutzt wird besonders bei Datenfeldern bei der die ID keine Relevanz/Verknüpfung mit anderen Daten hat.
+ Da sollte man Änderungen machen (besonders die im Core) diese auch mit geloggt werden (in einem eigenem File).
mfg Oliver
Da schließe ich mich natürlich an. Hoff, hoff, hoff.OliverL hat geschrieben:Aber ich bin immer noch voller Hoffnung das sollten Daten beim Update ergänzt werden die Funktion ->nextid() genutzt wird besonders bei Datenfeldern bei der die ID keine Relevanz/Verknüpfung mit anderen Daten hat.
Bis dann
Tono
Tono
Leider kenne ich das Setup nicht.
Aber es wird ja dann erst interessant wenn die Abhängigkeit zwischen "_file" und "_frame_file" ins spiel kommt
+ eigen entwickelte und dritte Anbieter (Forum-User) Plugin-In's.
Wobei hier noch am leichtesten mit der "_plugins" gearbeitet werden kann
(bei 4.8.6 wird sie leider immer noch nicht genutzt).
bla bla usw.
mfg OliverL
Aber es wird ja dann erst interessant wenn die Abhängigkeit zwischen "_file" und "_frame_file" ins spiel kommt
+ eigen entwickelte und dritte Anbieter (Forum-User) Plugin-In's.
Wobei hier noch am leichtesten mit der "_plugins" gearbeitet werden kann
(bei 4.8.6 wird sie leider immer noch nicht genutzt).
bla bla usw.
mfg OliverL
-
- Beiträge: 967
- Registriert: Do 15. Apr 2004, 17:12
- Wohnort: Eschborn-Niederhöchstadt
- Kontaktdaten: