richtlinien für plugins ?

[kummer]

ich blick da noch nicht durch. ich habe mal das hallo_world plugin downgeloaded und installiert.

ich sehe den menupunkt unter extras. wenn ich allerdings auf diesen punkt klicke erhalte ich kein 'hallo welt'. im quellcode des menubereiches finde ich den hinweis: <!-- plugin not found - db access deactivated //-->

und das, obwohl im config.plugin.php $cfg['plugins']['hello_world'] gesetzt worden ist.

scheint gar nicht so einfach zu sein, etwas ins backend einzubinden, oder sehe ich da etwas falsch?

nehme jede hilfe dankbar an.

gruss,
andreas

[emergence]

es kann sein das ich bei der beschreibung noch etwas vergessen habe.
welche contenido version verwendest du ?

ich tippe aber darauf das du die änderung in includes/cfg_language_de.inc.php nicht eingebaut hast.

[kummer]

die version 4.4.4.

ich habe am core-code nichts verändert. ich habe lediglich die datei entzipped, auf den server kopiert (in das verzeichnis hello_word im plugin-verzeichnis) und habe die sql-datei über phpmyadmin ausgeführt.

[emergence]

du musst am core-code noch was ändern... !
sonst wird die config.plugin.php nicht eingelesen...

siehe posting vom Fr Apr 30, 2004 8:49 am
und
posting vom Fr Apr 30, 2004 12:22 pm

[kummer]

hallo emergence

ich habe also den core auch geändert. allerdings ging dann nichts mehr. ich habe versucht den fehler einzugrenzen. mit folgendem code gings dann:

Code: Alles auswählen

$handle = opendir($cfg['path']['contenido'] . $cfg["path"]['plugins'] );

while ($plugin = readdir($handle)) {
   $configfile = $cfg['path']['contenido'] . $cfg["path"]['plugins'] . $plugin . "/includes/config.plugin.php";
   $localedir = $cfg['path']['contenido'] . $cfg["path"]['plugins'] . $plugin . "/locale/";

   if (@file_exists($localedir) && $plugin != "..")
   {
      // i18nRegisterDomain($plugin, $localedir);
   }
   if (@file_exists($configfile))
   {
      include($configfile);
   }
}

wie du sehen kannst, musste ich

Code: Alles auswählen

i18nRegisterDomain($plugin, $localedir);

auskommentieren.

interessanterweise funktioniert es dann aber. wenn ich die auskommentierung entferne, erhalte ich nach dem login in das backend bloss einen white-screen (keine fehlermeldung, auch nicht im quelltext).

ist die registrierung mit i18nRegisterDomain erforderlich? und was macht die eigentlich?

thanks for your reply!

gruss,
andreas

[emergence]

siehe posting Fr Apr 30, 2004 12:22 pm
die i18nRegisterDomain funktion wird erst mit der 4.5.x serie eingeführt.
es dient dazu das mein seine eigene locale datei verwenden kann, die nur für dieses plugin gelten.

sonst müsste man jedesmal die contenido.po verändern und neu kompilieren. und das wäre ähm sehr aufwendig.
Beispiel:
i18n("My Translation");
würde den string in der contenido.po bzw contenido.mo(wenn gettext included ist) suchen.
mittels
i18n("Defined in config_plugin.php", "hello_world")
wird die translation des plugins verwendet ! also hello_world.po und hello_world.mo
im hello_world plugin hab ich einfach versucht die verschieden möglichkeiten aufzuzeigen...

wenn man dies in der 4.4.x serie einbaut, hat man eigentlich eine voll funktionstüchtige schnittstelle die zur 4.5.x und 4.6.x serie kombatibel ist.

deine änderung mit dem auskommentieren tuts nur bis zu einen gewissen grad. die i18n funktion wird die strings einfach unübersetzt lassen. wenn nicht sogar einen fehler auswerfen da der zweite parameter in der 4.4.x serie für domain nicht verwendet werden kann. (wird nicht übernommen)

im obrig erwähnten posting (dieser thread) sind die betroffen funktionen die ersetzt werden müssen aufgeführt.

die anderen änderungen innerhalb dieses threads sind zum teil bereits in der 4.5.x serie enthalten.

wohlgemerkt es ist nicht gesagt, das meine anmerkungen und diese zusammenfassung dann genau so in der 4.6.x serie hineinkommen werden. aber ich sehe bezüglich der anpassungen der plugins die man jetzt schreibt keinerlei problem.

intressant wird es ja erst wenn der plugin installer kommt. ich hab mir zwar mal vorgenommen selbst einen zu schreiben, aber momentan tuts die install.sql für mich auch.

[kummer]

danke für die ausführliche antwort.

ich bin daran, das ticketsystem zu planen und möchte einen teil im backend unterbringen. wenn ich das ganze vernünftig (sprich oop) plane, sollten auch in zukunft wenig probleme bei einem allfälligen transfer auftreten. hoffe ich mindestens...

gruss und danke,
andreas

[kummer]

hallo emergence

voila, ich glaube fast, ich habe es geschafft.

nun ergeben sich ein paar neue fragen:

ich habe ja in der db nur die drei includefiles meines plugins angegeben. das ticketsystem wird aber aus wesentlich mehr files bestehen. gehe ich recht in der annahme, dass ich dazu in einem dieser include-files wiederum - situationsabhängig - inkludierungen weiterer dateien vornehme, welche die eigentliche funktionalität beeinhalten?

und gehe ich recht in der annahme, dass ich den pfad zu diesen dateien über...

Code: Alles auswählen

$cfg['path']['plugins'].$plugin_name."/includes/";

...erhalte?

oder gibt es ein grundsätzlich besseres verfahren? ich denke vor allem im hinblick auf updates in der zukunft.

gruss,
andreas

[emergence]

voila, ich glaube fast, ich habe es geschafft.

freut mich

nun ergeben sich ein paar neue fragen:

ich habe ja in der db nur die drei includefiles meines plugins angegeben. das ticketsystem wird aber aus wesentlich mehr files bestehen. gehe ich recht in der annahme, dass ich dazu in einem dieser include-files wiederum - situationsabhängig - inkludierungen weiterer dateien vornehme, welche die eigentliche funktionalität beeinhalten?

ähm die eintragungen dienen nur für den erstmaligen aufruf des menüpunkts ! wie du dann weiters die dateien innerhalb des plugins in den einzelnen frames nachlädst bleibt dir überlassen.

und gehe ich recht in der annahme, dass ich den pfad zu diesen dateien über...

Code: Alles auswählen

$cfg['path']['plugins'].$plugin_name."/includes/";

...erhalte?

nicht ganz -> $cfg['plugins']['hello_world']."includes/"
siehe config.plugin.php
im frontend in einem modul -> siehe posting Fr Apr 30, 2004 8:49 am
zuerst das config.plugin.php laden dann hat man innerhalb eines moduls auch die selben definitionen.

oder gibt es ein grundsätzlich besseres verfahren? ich denke vor allem im hinblick auf updates in der zukunft.

ähm also mir fällt momentan keines ein... wenn du einen besseren vorschlag hast nur her damit.

[emergence]

ich hab für die 4.4.4 serie ein file zusammengestellt, das an sich alle änderungen beinhaltet + ein paar zusätzliche features...

http://dayside.net/plugin-interface-contenido-4.4.4.zip

es beinhaltet alle änderungen aus diesem thread +
http://www.contenido.de/forum/viewtopic ... highlight=
+
http://www.contenido.de/forum/viewtopic ... 0450#30450

in einem zipfile zusammen gefasst... vielleicht kanns ja einer bei einer 4.4.4 version testen -> backup nicht vergessen...

[emergence]

die selben änderungen für die 4.5.2alpha version findet ihr hier...

http://dayside.net/plugin-interface-contenido-4.5.2.zip

somit zeigen die 4.4.4 und die 4.5.2alpha version das selbe verhalten bei den plugins...

die dateien
functions.i18n.php
und
cfg_language_de.inc.php
ebenso include.frontend.group.subnav.php - da ist mir nicht ganz klar was damit gemacht wird...
sind im zipfile nicht enthalten...

ansonsten sind einige subnav dateien hinzugekommen
ebenso hinzugekommen
config.path.php
da die definitionen von $cfgPath['xml'], $cfgPath['xmlroot'] in der alpha version nicht mehr enthalten sind....

[emergence]

ich hab beide dateien nochmals auf den server geladen, da eine änderung multilang bei den rechten gefehlt hat...
solltet ihr es vorher runtergeladen haben, die aktuellsten version sind seit 11:15 verfügbar...

[Snoopy]

@emergence

Super Super Super, das wäre eigentlich das nächste auf meiner ToDo-Liste gewesen. Klasse sache,getestet und für gut befunden.

Ich muß dich Loben, saubere Arbeit. Jetzt werde ich anfangen eine Setuproutine für Module zu schreiben. Das Setup für
das JAX-Calendar-Plugin ja nicht eimal den Status einer Alpha version hat. Hier kommt dann der Modul Im- /Exporter von UBO mit ins Spiel.
Weil z.b das Jax-Calendar-Plugin auch Module für das Frontend benötigt.

In diesem Sinne....

[emergence]

danke...
es war die einzig vernünftige sache, das ich das zusammenstelle...

schön... ich hab mir eigentlich mehr sorgen bezüglich inkombatibiltät zwischen den php versionen gemacht...

sobald der snapshot am freitag rauskommt werd ich den patch für den aktuellen snapshot nochmals bauen... ist glaube ich dann leichter um die files in den aktuellen snapshot aufzunehmen...

das mit der include.frontend.group.subnav.php muss ich mir erst ansehen, warum es dort anders gemacht wurde...

[emergence]

ach ja den menuless patch hab ich momentan mit absicht nicht reingebaut, da dies nur mit einem upgrade machbar wäre...

siehe http://www.contenido.de/forum/viewtopic ... 8497#28497

es würden sich ebenso die einträge beim plugin install für con_area ändern !
d.h. alle bisher existierenden plugins müssten dieses feld in der install.sql mit reinziehen...
für diesen fall zahlt es sich nur aus wenn 4fb dies wirklich in den snapshot übernehmen möchte...
ich persönlich verwende es bereits intern, bei meinen plugins...

ich muss in nächster zeit die richtlinien mal neu verfassen bzw neu zusammen schreiben damit die neuen features auch beschrieben sind...