sagt mal, hat es schon jemand geschafft, den “templates”-Bereich in der metadata.php zu nutzen? Ich glaube nämlich, da ist ein Bug drin. Zuerst einmal ist es unschön, dass man gezwungen wird, in seinen Modulen die Template-Angaben immer OHNE Pfade einzugeben, d.h. um beim Wiki-Beispiel zu bleiben:
Das bedeutet aber leider, dass man dasselbe Modul schlecht für aktuelle und ältere OXID-Versionen gleichzeitig anbieten kann, bzw. man muss halt mit 2 verschiedenen Pfaden arbeiten!
Aber viel wichtiger ist halt der Umstand, dass es einfach nicht funktioniert, auch wenn die Angaben korrekt vornimmt. Ich habe diesmal vor dem Posten den Quellcode ausgiebig durchwühlt, aber einfach keine Lösung finden können. Irgendwo in smarty (glaube ich) geht irgendwas verloren oder springt auf isAdmin o.ä., keine Ahnung. Das Beste, was ich hinbekam, war eine völlig leere Seite, aber wenigstens ohne Fehlermeldungen. Nur half das auch nicht wirklich weiter…
Also, falls irgendwer einen Tipp hat, immer her damit, ansonsten bitte das Problem bestätigen, danke!
[QUOTE=Mitmacher;97067]
Das bedeutet aber leider, dass man dasselbe Modul schlecht für aktuelle und ältere OXID-Versionen gleichzeitig anbieten kann, bzw. man muss halt mit 2 verschiedenen Pfaden arbeiten!
[/QUOTE]
da musst du aber näher erläutern, was dich daran hindert.
Hey, ich danke dir für die Demo!
Zusammen mit dem Wiki bringt mich das aber auf die (evtl. blöde) Frage: Kann es sein, dass dies nur mit admin-Templates funzt, bzw. nur dafür gedacht ist? Ich wollte es nämlich FE-seitig nutzen und dort haut es einfach nicht hin bisher.
Hm, und der “out/admin/de”-Ordner wird automatisch berücksichtigt, ohne Definition per metadata? Das muss ich gleich mal testen und wär ja klasse…
Und nochmal hierzu:
da musst du aber näher erläutern, was dich daran hindert.
Wenn man es so nutzen möchte, geht das nur ohne Pfade wie auch in deiner Demo:
$_sThisTemplate = ‘hello_oxid.tpl’;
Aber einige FE-Templates werden in OXID ja auf Unterverzeichnisse verteilt, wie z.b. /page/checkout/, und ich dachte mir halt, es wäre das Beste, wenn man dies so beibehält für OXID < 4.6, d.h. die Modul-Templates in diese Pfade kopiert, und ab 4.6 dieselbe Struktur innerhalb des Modul-Dirs anlegt. Das geht aber eben nicht, bzw. nur für admin-Templates (würde ja passen, die sind ja alle “flat”).
die Ordner
out/admin/de bzw out/admin/en
out/de bzw out/en
und auch für alle anderen Sprachen sind für language Dateien. Ich gehe davon aus, dass die language Datei die exakte id des Moduls und den Suffix"_lang" als Namen haben soll, z.B: “hello-oxid_lang.php” wobei “hello-oxid” meine Modul-Id ist. Diese Dateien werden dann automatisch geladen sobald das Modul aktiv ist.
ändere mal in der Datei hello-oxid/admin/hello_oxid.php “oxAdminView” zu “oxView”, dann deaktiviere und aktiviere die Erweiterung wieder. Jetzt kannst du die Klasse im FE benutzen (über den Link www.dein-shop.de/index.php?cl=hello_oxid", in den Klassen werden die Templates aber nur per basename genutzt.
Die Templatestruktur im Modulordner ist völlig egal, nur Blocks müssen in out/blocks.
So, habe eben mal kurz dein Modul installiert (ohne FE-Modifikation) und festgestellt, dass es genau dasselbe Problem aufweist: Wenn ich im BE-Menü “Hello Oxid!” wähle, erscheint nur eine absolut leere Seite! Und das in 2 verschiedenen Shops mit Version 4.6.2, und auch, nachdem Cache und Tmp geleert worden sind.
Ist das jetzt nur bei mir so und bei dir wird das Template geparst? Das wäre höchst merkwürdig, aber wenigstens auch ein kleiner Anhaltspunkt.
Ansonsten natürlich danke für die anderen Infos, obwohl die größtenteils schon klar waren. Es klappt halt nur trotzdem leider nicht…
Noch bin ich nur lokal unter Windows am Testen, also fallen Transfer-/Rechte-Fehler auch flach. Ich habe es gerade eben nochmals in einem völlig frischen OXID 4.6.2 getestet, und auch dort gibt es nur eine blank-Page als Resultat. Die Logs (Server + Exception) bleiben auch leer. Hm, blöd, also liegt es nicht am Admin-Mode wie vermutet, und ich ich weiß jetzt überhaupt nicht weiter…
Aber du wirst mir doch kein völlig ungetestetes Modul schicken, d.h. ich gehe davon aus, dass es bei dir funktioniert, oder? Dann bleibt ja fast nur noch Windows, bzw. wieder meine (evtl. etwas zu aktuelle) PHP-Version 5.4. Dazu hatte ich ja bereits einen anderen Bug gemeldet, da OXID noch nicht ganz aufwärtskompatibel ist.
Ha, that’s it! Unter Linux läuft es, aber das wird wohl dann echt an PHP liegen, auf dem Server ist nämlich noch 5.3. Verdammich, das ist jetzt trotzdem suboptimal, da man mit so etwas kaum rechnen kann. Vor allem sehr mühsam, den konkreten Fehler zu finden, ist also doch ein Bug. Ich tippe zwar auch auf ein Referenzen-Problem wie hier schon erläutert, aber wo mag das versteckt sein? :eek:
Hm, wenn mir jetzt einer verlässlich sagen kann, dass ich Zukunft noch über zig weitere solcher Fehler stoßen werden, dann muss ich wohl PHP downgraden, aber eigentlich würde ich es gerne vermeiden. Alle sonstigen mir bekannten Systeme laufen ja eher problemfrei mit PHP 5.4 und ich habe gerade meine ganze Entwicklungsumgebung aktualisiert und rund bekommen. Bisher habe ich keine Warnungen bezügl. OXID gelesen, also dachte ich, es wäre kein Problem.
[QUOTE=Mitmacher;97067]
Das bedeutet aber leider, dass man dasselbe Modul schlecht für aktuelle und ältere OXID-Versionen gleichzeitig anbieten kann, bzw. man muss halt mit 2 verschiedenen Pfaden arbeiten! :([/QUOTE]
Grad das selbe Thema auf der OXID-ML. Du kannst bereits seit einigen OXID-Version Deine Templates auch relativ zum Modul-Ordner ausgehend vom template-Ordner angeben. Auf der Uncoference 2012 gab es das selbe Thema und die Core-Entwickler stimmten mir bei diesem Tipp zu. Anderersseits könntest Du auch ein “Smarty-Modul” schreiben und einen Modulordner für Templates angeben.
Wow, allmählich dämmerts! Es liegt tatsächlich auch in diesem Fall einfach “nur” an dem bereits erwähnten Bug in der Funktion _smartyDefaultTemplateHandler (in oxutilsview). Sobald man dem 3. und 4. Parameter ein & voranstellt, haut es hin:
public function _smartyDefaultTemplateHandler($sResourceType, $sResourceName, &$sResourceContent, &$sResourceTimestamp, $oSmarty)
Und dies läuft auch mit älterem PHP, könnte/sollte also am besten umgehend gefixt werden. Ich ergänze die Bugmeldung noch um einen Comment, confirmed ist sie ja schon.
Also haben wir eine Lösung, und man kann ruhig PHP 5.4 nutzen, feine Sache!
Ja, und das mit den Pfaden klappt nun plötzlich auch, ist ja ein Ding. Da kam ich wohl irgendwo durcheinander beim Testen. Aber ungelogen kam da mehrfach eine Fehlermeldung, als ich es versuchte. Evtl. hing das aber auch mit dem PHP zusammen, wer weiß. Ich danke euch jedenfalls für die Hilfen und Ideen!
So, ich würde meine neuen Erkenntnisse nun gerne z.b. in mein DelTmp-Modul einfließen lassen, habe aber doch noch ein Verständnisproblem. Und zwar ergänzt das Modul ja die “out/admin/tpl/header.tpl”. Darin sind ja keine Blocks definiert, also kann ich es auf dem Wege auch nicht erweitern, richtig?
und lege meine Datei dorthin (innerhalb modules). Allerdings wird dies nun gar nicht berücksichtigt, und es ist wahrscheinlich auch gar nicht zum overriden gedacht, oder? Trotzdem wundert es mich ein wenig, wo ist denn der Unterschied zu einem eigenen Template?
Danke + Grüße!
PS: die lang-files einzubinden ist echt Null Problem, der Name auch fast egal, hauptsache er endet mit “_lang.php”, coole Sache!
Edit:
Vergesst es, hat sich eigentlich erledigt. Im Code steht ja recht eindeutig (getTemplatePath), dass ZUERST nach Standard-Templates gesucht wird. Und nur wenn nichts gefunden wird, kommt evtl. das modules-Dir ins Spiel, also kann man so definitiv keine existierenden Templates overriden. Schade eigentlich, aber ich habe das Gefühl, wir nähern uns dem (alten) Thema. Man müsste ja nur die Logik vertauschen, also erst in modules suchen, aber dafür reicht es leider nicht getTemplatePath zu ändern, die eigentliche Zuordnung findet wohl erst später statt.
ich distanziere mich von möglichen psychischen Nachwirkungen und freue mich über die Rückmeldung
(für die Wiki werde ich das ding natürlich noch etwas ausbauen und die Settings einbauen)
Autsch, da bin ich erstmal sprachlos, aber letztlich auch schon wieder genial! :eek:
Ist schon schräg, wo man überall dran schrauben kann… lach
Aber sag mal: es ist nicht möglich, auch die FE-lang-files (basic) mit in den Modulordner zupacken, nur admin, richtig? Wäre ja auch blöd zu händeln, da ja fast jeder ein eigenes Theme nutzen dürfte, und man kennt den Namen ja nicht, aber evtl. gibt es einen Trick, den ich noch übersehe?
Danke + Gruß
Sascha
Edit: dummerweise geht es auch nicht direkt in out/de, wie du eingangs meintest.
Okay danke, aber ich habe es gerade hinbekommen. Steht ja in der Funktion _getLangFilesPathArray (oxlang) ganz am Ende. Statt nur “out/de” (innerhalb des Modul-Dirs) muss es heißen “out/lang/de”, dann funzt es prima. Das wäre ein weiterer Punkt, den man in dein Demo-Modul aufnehmen könnte/müsste…
Hach, nun wird es noch etwas schräger:
Ich hatte ja bereits diesen vermeintlichen Patch für PHP 4.5 integriert und trotzdem noch Probleme bei der Nutzung von Modul-Templates, allerdings nur, wenn OXID im Demo-Mode lief! Nach weiterer Analyse kam ich nun darauf, dass smarty einfach das korrekte template_dir fehlt. Und wenn man dies ergänzt, kann man sich sogar den PHP-Patch sparen, also ist das Ganze evtl. gar kein PHP-Problem! :eek:
Leider ist es nicht trivial statisch zu fixen, von daher habe ich mir (wieder) mit einem kleinen Modul geholfen, aber eigentlich ist das zu kompliziert und der falsche Weg. Ich habe die Bug-Meldung um eine weitere Notiz ergänzt, siehe hier. Keine Ahnung, wie man da nun am besten rangeht. Ich weiß mir ja jetzt zu helfen, aber besser wäre natürlich eine klare offizielle Lösung für alle…
und die article_pictures_ext tut nichts anderes, als nach dem Rendern einfach nur mein Template anstatt dem default article_pictures.tpl zurückzuliefern:
<?php
class article_pictures_ext extends article_pictures_ext_parent
{
public function render()
{
parent::render();
return "article_picturestitles.tpl";
}
}
vielleicht kann ja jemand gebrauchen und kommt dadurch auf neue Ideen
Ich habe ein Modul geschrieben, das das Template widget/product/selectbox.tpl erweitert. Allerdings funkt das Ganz nur, wenn ich dieses Template in den Theme-Ordner lege und das ist natürlich Käse. Hat jemand von Euch eine Idee, wie man das sauber lösen kann? Das Template wird per Smarty-Funktion include eingebunden. Mir fällt nur ein, in der metadata.php einen Symlink setzen zu lassen, oder Smarty zu überschreiben. Aber das ist alles irgendwie nichts…
@vanilla thunder:
Hey, danke! Keine schlechte Idee das Ganze, muss man nur drauf kommen!
@toxid:
Hm, ich glaube, ich kann nicht ganz folgen, aber per include sollte es eigentlich kein Problem sein, wenn es mit korrektem Pfad in der metadata steht. Aber was genau wird von wo eingebunden? Ich fürchte, du müsstest ein wenig konkreter werden.
Das selectbox-Template habe ich erweitert. Wenn ich dieses im Theme-Ordner belasse, also /out/mytheme/tpl/widget/product/selectbox.tpl, dann wird dieses erweiterete Template auch vom Shop verwendet. Wenn ich es aber, was ja sinnig wäre, in den Modul-Ordner verschiebe und in der metadata.php den Pfad für dieses Template angebe, so wird dieses erweiterte Template nicht eingebunden, auch nicht, nachdem ich tmp/ geleert habe.
Nach dem, was hier geschrieben wurde habe ich es so verstanden, dass bestehende Templates auf diese Weise nicht überschrieben werden können. Liege ich da richtig? Und falls ja, hat jemand von Euch einen sinnvollen Workaround?
