Hilfe - Suche - Mitglieder - Kalender
Vollansicht: Plugin: Extended Header v00.02.01
Forum Sefrengo.org > Downloads > Alpha, Beta ... Vorabversionen
Tiggr
Hallo!

Hier eine neue Version meines Plugins, das es Modulen ermöglicht den Seitenheader zu beeinflussen, oder genauer gesagt eigenen einträge zuzufügen. Damit können dynamische Webformuler erstellt werden, die JS brauchen, Module können eigene CSS-Dateien laden, oder Meta-Tags können gesetzt werden.

Und ich mußte dazu nicht einmal sehr den Core von Sefrengo verbiegen. Nur in der index.php des Projekts muß ich zwei Events abfeuern. Wäre toll, wenn die Events in die Standardversion von Sefrengo einfließen könnten.

Hier ist noch mal ein Link zum FR, den ich damit umsetze: Header als letztes abarbeiten, Module fügen JS und CSS hinzu (Web2.0-Fähigkeit)

QUELLTEXT
Changelog legend:
# -> Bug Fix
+ -> Addition
^ -> Change
- -> Removed
! -> Note

00.02.01 - released 17.08.2007
------------------------------------------------------------------------------------------------
# bug with file path containing backend/projekt-dir twice

00.02.00 - released 17.08.2007
------------------------------------------------------------------------------------------------
# missing space in script tag
+ only unique header additions
+ check for existence of files

00.01.00 - released 16.08.2007
------------------------------------------------------------------------------------------------
! first release



CODE
Pluginname:
---------------------------------------------------------------------------
exteneded header


Status:
---------------------------------------------------------------------------
alpha



Bechreibung:
---------------------------------------------------------------------------
Das Plugin stellt ein globales Objekt zur Verfügung, über das Module eigene
Angaben in den HTML-Header einfügen können, zum Beispiel Scripte oder CSS
laden.

Funktioniert zur Zeit nur mit einer angepaßten Version der index.php im
Projektverzeichnis


Features:
---------------------------------------------------------------------------
- Fügt Headerangaben aus Modulen herraus zu.
- Vor dem Eintragen wird bei Scripten und CSS geprüft ob die Dateien
existieren.
- Jeder Eintrag wird nur einmal vorgenommen, auch wenn er mehrmals zugefügt
wird.

Autor(en):
---------------------------------------------------------------------------
Marcus J. Ertl (tiggr)

Lizenz:
---------------------------------------------------------------------------
GPL2


Benötigte Sefrengo Version:
---------------------------------------------------------------------------
>= 01.04.00


Installation:
---------------------------------------------------------------------------
Wechseln Sie in Ihrer Sefrengo Version in den Bereich "Administration -> Plugins".
Klicken Sie oben rechts auf "Plugin importieren". Am unteren Ende des Bereichs
befindet sich ein Uploadfeld. Wählen Sie hier die gewünschte "*.cmsplug"- Datei
aus. Mit einem Klick auf das Diskettensymbol wird das Plugin in das CMS importiert.
Das Plugin ist nun innerhalb des CMS nutzbar. Installieren Sie das Plugin mit einem
klick auf das Plugin-Importieren-Symbol in der Pluginzeile.

Kopieren sie die Datei hack/index.php über die entsprechende Datei im
Projektverzeichnis. Änderungeng gegenüber der Orginalversion sind mit
'// extended_header' gekennzeichnet. Im wesentlichen werden zwei Events
abgefeuert.


Update/ Migration:
---------------------------------------------------------------------------
Ein Update können Sie einfach über den Sefrengo- Pluginmanager einspielen. Das
Plugin führt dann automatisch das Update durch.


Dokumentation:
---------------------------------------------------------------------------
Das Objekt $cms_header ist nahezu selbsterklärend und trivial. Die Parameter
der Methoden können im Quelltext der Datei inc/class.extended_header.php
gefunden werden.

Für mehr Infos kann das Beispielmodul angesehen werden.


Im Beispielmodul sieht das dann wie folgt aus:

CODE
<CMSPHP>
// Plaintext, wird so übernommen, wie hier angegeben...
$cms_header->addPlain('<!-- Plain-Text, der im Header eingefügt wird, hier als Kommentar -->');

// fiktives css, erscheint nicht, da File nicht existiert
$cms_header->addStyle('/path/to/my/style.css');

// fiktives js, erscheint nicht, da File nicht existiert
$cms_header->addScript('/path/to/my/script.js');

// css, das es wirklich gibt, wird deswegen auch im Header eingebaut
$cms_header->addStyle('/tpl/standard/css/tabs.css');

// nochmal das selbe, wird trotzdem nur einmal eingebaut!
$cms_header->addStyle('/backup/tpl/standard/css/tabs.css');

// prüfen der Existens von Dateien deaktivieren
$cms_header->setFilecheck('');

// das fiktive CSS erscheint deswegen
$cms_header->addStyle('/path/to/my/unchecked/style.css');

// wir wollen wieder prüfen ob die Datei im Frontend oder
// Backend existiert
$cms_header->setFilecheck('frontend,backend');

// urls gehen ungeprüft durch
$cms_header->addStyle('http://www.somewhere.demo/path/to/my/remote/style.css');

// und ein Script, das direkt angegeben wird!
$cms_header->addScript('alert("Test !!!")', 'src');
</CMSPHP>


Was dann zu folgenden Headerzeilen führt:

CODE
<link rel="stylesheet" type="text/css" href="/backup/tpl/standard/css/tabs.css" />
<link rel="stylesheet" type="text/css" href="/path/to/my/unchecked/style.css" />
<link rel="stylesheet" type="text/css" href="http://www.somewhere.demo/path/to/my/remote/style.css" />

<script type="text/javascript">
alert("Test !!!")
</script>
<!-- using extended_header-plugin v00.02.00 -->
<!-- Plain-Text, der im Header eingefügt wird, hier als Kommentar -->


Ein Dankeschön an 'bkm', dessen Idee es war, zu prüfen, ob die Dateien wirklich existieren!

Und wie üblich der Code im SVN: http://code.google.com/p/extendedheader/

Tschüss
Tiggr (aka Marcus)
Tiggr
Mist, da ist noch ein Bug drin, wenn ich prüfe, ob es das File im Backend/Frontend gibt, das klappt beim Frontend nur, wenn das Frontend nicht in einem Projektverzeichnis liegt, beim Backend nie... :-(

Das Problem ist das jeweilige Unterverzeichnis, das kommt zum einen aus dem $cms_cfg['path'] bzw. $cms_cfg['cms_path'].

Irgendwie muß ich den Pfand normalisieren, ohne zu wissen wie das Projektverzeichnis heißt, oder ob es eines gibt!

Beim Backend kann ich ja noch annehmen, dass das letzte Verzeichnis in $cms_cfg['cms_path'] das Backendverzeichnis ist.

Jemand eine Idee?

Tschüss
Tiggr (aka Marcus)
Tiggr
So, hab's, hab die Download-Datei gewechselt, alles OK, hoffe ich!

Hab es nur auf einem Linux-Server getestet, keine Ahnung, ob es auch unter Windoof tut!
STam
Hi,

ich finde die Idee nicht schlecht, auch die Umsetzung ist im Rahmen der vorhandenen SF-Möglichkeiten
minimal invasiv. Doch möchte ich anmerken das mir der Mißbrauch dieser Schnittstelle nicht gefällt.
Wie gesagt trotzdem zur Zeit die beste Lösung!

Das Event-System ist dafür zwar nicht gedacht dennoch könnte es das mal werden was andere Systeme
als Call-Back kennen; register_tick('event', function()), register_callback('event', function())...

Man könnte so eine schöne Schnittstelle schaffen, die Arbeit alle sinnvollen Events im System zu registrieren
und im gegenzug auch Sicherheitsrelevente Bereiche davon auszuschließen müsste natürlich angegangen werden.
Auch Überlegt werden muss dabei wie sinnvoll es sein kann einen Call-Back aufzurufen bevor eine
bestimmte Funktionalität ausgeführt wird, nicht erst danach (was ja die eigentliche Event-Idee war)!
Das müsste sicherlich in einem andere Thread behandelt werden.... (irgendwann in ...)

Gruss
Tiggr
Hiho!

ZITAT(STam @ Sun. 19. August 2007, 13:38) *
Doch möchte ich anmerken das mir der mißbrauch dieser Schnittstelle nicht gefällt.


ZITAT
Das Event-System ist dafür zwar nicht gedacht dennoch könnte es das mal werden was andere Systeme
als Call-Back kennen; register_tick('event', function()), register_callback('event', function())...


Wieso Mißbrauch? Ich dachte genau für sowas sei das Eventsystem gedacht?

Call-Backs, Events, Delegates, ich dachte die Idee sei Code auszuführen, wenn ein Ereignis eintritt...

Falls das Eventsystem nicht dafür gedacht ist, dann ist das schade, weil sowas fehlt dann dringend in SF. Wo diskutieren wir das weiter? Weil sowas würde SF sehr helfen, man könnte den Core schlank halten, die Coreentwickler entlasten, und versuchen Funktionalitäten als Plugins zu realiseren.

Tschüss
Tiggr (aka Marcus)
smail
ZITAT(Tiggr)
man könnte den Core schlank halten, die Coreentwickler entlasten, und versuchen Funktionalitäten als Plugins zu realiseren.


Vorweg erstmal: Ich find das Plugin bzw. die dahinterliegende Idee einfach Spitze. Danke an Tiggr.

Stellt sich nun eine wichtige Frage:
Wie geht es weiter mit diesem Plugin? Sollten andere Module / Plugins darauf aufbauen? Oder fliegt das in der nächsten Version von SF wieder raus?

Falls es rausfliegt: Die Möglichkeit, direkt in den Header zu schreiben ist sehr praktisch. Welche Alternativ-Ansätze werden in kommenden SF-Versionen favorisiert?

@Tiggr: Was fehlt, um das Plugin als stable ansehen zu können?

Viele Grüße
Jan

Tiggr
Hiho!

ZITAT(smail @ Fri. 28. September 2007, 16:34) *
Wie geht es weiter mit diesem Plugin? Sollten andere Module / Plugins darauf aufbauen? Oder fliegt das in der nächsten Version von SF wieder raus?


Ich werde es erstmal bei mir für eigene Module verwenden, was andere damit machen, keine Ahnung! Die Idee finde ich wichtig, dass man aus dem Käfig "body" ausbrechen kann. Ich werde es vor allem benutzen um JS für Formulare zu bauen!

ZITAT
@Tiggr: Was fehlt, um das Plugin als stable ansehen zu können?


Erfahrungen und Testergebnisse! Und da es im Moment eine Core-Datei hackt, ist es für mich nicht stable!

Tschüss
Tiggr (aka Marcus)
smail
ZITAT(Tiggr)
Und da es im Moment eine Core-Datei hackt, ist es für mich nicht stable!


leuchtet ein - aber damit wäre z.B. TinyMCE auch nie stable smile.gif


Damit geht die Frage an einen anderen Adressaten:
Liebe Core-Entwickler, wie sieht es mit diesem Plugin aus? Bisher gab es zu diesem wertvollen Plugin keine Offizielle Stellungnahme.
  • Können wir bei der Modulentwicklung auf dieses Plugin aufbauen?
  • Welche Alternativ-Ansätze werden in kommenden SF-Versionen favorisiert?
Meiner Meinung nach wäre es eine strategisch ungünstige Entscheidung und ein gewaltiger Rückschritt für SF, wenn Module bzw. Plugins keine "offizielle" Möglichkeit haben, auf den Header zuzugreifen. Damit verbaut man für SF die Nutzung von js-Frameworks bei einer gleichzeitigen sauberen Kapselung in Plugins.
smail
ZITAT(Tiggr)
Umpf, im Archiv hat ne Datei gefehlt: index.php. Hier da Komplette Archiv, oben kann ich das nicht mehr ändern.


Hi Marcus,
die index.php ist nun 2x im Archiv... unsure.gif
  • /hack/index.php
  • und als Bestandteil des gepackten Plugins, wenn Du die *.cmsplug 2x entpackst, so als woltest Du das Plugin manuell installieren. Dann gibts da ebenfalls den Ordner extended_header/hack/index.php)

Da beide Dateien absolut identisch sind, bin ich grad etwas verwirrt.. ohmy.gif

Viele Grüße
Jan

Tiggr
Uhm, kein Grund verwirrt zu sein, dann hab ich das übersehen! Vergiss einfach das Posting von oben!

Tschüss
Tiggr (aka Marcus)
duffy
Hallo,

ich war grad auf der Suche nach einer Möglichkeit den title-Tag aus einem Modul heraus zu ändern, da ist mir dies hier unter gekommen und ich habe es fix erweitert um den title ändern zu können.
Hier die Änderungen:

in inc/class_extended_header.php neu einfügen:
CODE
var $title;
function setTitle($title)
{
$this->title = $title;
}

function getTitle()
{
return $this->title;
}


in process.php ab zeile 7 einfügen:
CODE
if(strlen($cms_header->getTitle()) > 0)
{
$output = preg_replace('/<title>.*<\/title>/', "<title>".$cms_header->getTitle()."</title>", $output);
}


Oder gibt es eine andere Möglichkeit, fernab von diesem Plugin, die sich mir noch nicht erschlossen hat?

Gruß,

Oliver
smail
ZITAT
Oder gibt es eine andere Möglichkeit, fernab von diesem Plugin, die sich mir noch nicht erschlossen hat?


Hallo Oliver,

derzeit scheint mir das die einzige Möglichkeit zu sein. Schade ist, dass diese Plugin wohl auch in der 1.6 nicht übernommen wird. Björn verspricht aber für die 1.6 eine andere Möglichkeit, mit so etwas umzugehen.

Viele Grüße
Jan
bjoern
Wo hat Björn was versprochen?
smail
siehe Feature-Request zu diesem Thema: Extended Header als Standard für SF 1.6
ZITAT(bjoern @ Thu. 6. December 2007, 18:14) *
Der Vorschlag klingt vom Grunde her gut. Ich möchte das noch ein wenig globaler haben, sprich, dass ich ein Output Objekt habe, wo verschiedene Änderungen reingeworfen werden können. [...]

Mal schauen, was ich da in der 1.6 tun kann.


Klingt für mich zumindest so, als ob das mal mit ähnlicher Funktionalität übernommen werden könnte. smile.gif
bjoern
Tja, etwas versprechen und sich versprechen liegen halt nahe beieinander. Bei Zitierungen meinerseits bitte ein wenig Vorsicht walten lassen, den am Ende bin ich es, der die daraus entstandenen Synergien wieder geraderücken darf. smile.gif
smail
ZITAT
Tja, etwas versprechen und sich versprechen liegen halt nahe beieinander. Bei Zitierungen meinerseits bitte ein wenig Vorsicht walten lassen


Hallo Björn, so ganz verstehe ich Deinen Einwand nicht. Was genau meinst Du nun mit "Versprecher"?
  • Entweder wird dieses FR bei der zukünftigen Entwicklung berücksichtigt - wann und in welcher konkreten Form auch immer. So habe ich Dich verstanden und dementsprechend auch auf Deinen Post verwiesen,
  • oder es wird keine weiteren Überlegungen mehr in dieser Richtung geben, was aber aus Deinem damaligen Post nicht so ganz deutlich wurde.

Unabhängig davon: Mein Verweis zielt vielmehr darauf ab, dass dieses Thema an sich nicht begraben ist und es bei der zukünftigen Entwicklung zumindest im Auge behalten wird (und das ist eine wichtige Info für viele Nutzer).
Insofern denke ich auch nicht, dass Du da wieder etwas gerade rücken musst. Es sei denn, es ist schon jetzt klar, das Thema für SF generell gestorben ist.

Viele Grüße
Jan
smail
Hallo Tiggr,

vielleicht ist das jetzt eine ganz dumme Frage, aber Dein Plugin wird ja über 2 Events (page_start bzw. page_end) getriggert. Dazu muss ja die index.php des Projektes leicht erweitert werden.

Könnte man das Gleiche nicht über die bereits eingebauten Autostarts erreichen? Hier das Beispiel für das Snippet-Replacement:
QUELLTEXT
INSERT INTO {table_prefix}values VALUES ('', {client_id}, 0, 'cfg_client', 'autostart',
    'frontend', 'snippet_replacement', '', 'snippet_replacement/inc.replacer.php', 111, '',
    NULL, 'txt', NULL, NULL, '1');
INSERT INTO {table_prefix}values VALUES ('', {client_id}, 0, 'cfg_client', 'autostart',
    'backend', 'snippet_replacement', '', 'snippet_replacement/inc.replacer.php', 111, '',
    NULL, 'txt', NULL, NULL, '1');

In der inc.replacer.php wird dann analog zur process.php des Extended-Header Plugins ein str_replace ausgeführt um den $output zu manipulieren.

Viele Grüße
Jan
smail
Hab nochmal ein Bißchen tiefer gewühlt wink.gif

Meine Vermutung ist, dass die Autostarts zu spät "losschießen", also erst nach dem Aufruf von Frontend bzw. Backend. Das Objekt cms_header steht damit nicht früh genug zur Verfügung, um von Modulen "befüllt" zu werden, d.h. also:
  • page_start läuft vor dem Seitenaufbau zur Initialisierung des Objekts cms_header
  • page_end nimmt das str_replace mit den Inhalten von cms_header vor und könnte damit durch autostarts ersetzt werden (das bringt dann aber auch nix mehr).

Meine Hochachtung cool.gif , das Plugin ist schon ziemlich genial.
smail
Einen Vorschlag zur Implementierung der Funktionalität des Plugins Extended Header ohne Änderung des Core habe ich unter Plugin jQuery v00.03.00, Case Study - Module schreiben in den Header veröffentlicht.
Dieses ist eine vereinfachte Darstellung unseres Foreninhaltes. Um die detaillierte Vollansicht mit Formatierung und Bildern zu betrachten, bitte hier klicken.
Invision Power Board © 2001-2024 Invision Power Services, Inc.