Archiv verlassen und diese Seite im Standarddesign anzeigen : hook global_start eignet sich nicht! Suche andere Lösung.
Folgendes:
Ich habe diesen Code welcher mir aus der datastore Tabelle etwas ausliest und dann einen dieser Einträge wiederum in eine andere Tabelle schreibt.
Das funktioniert, rufe ich das testscript.php direkt auf, auch tadellos.
Ausgelesen soll der Wert, welchen ich mal test genannt habe.
Hier mal das script.
<?php
// ####################### SET PHP ENVIRONMENT ###########################
error_reporting(E_ALL & ~E_NOTICE);
// #################### DEFINE IMPORTANT CONSTANTS #######################
define('NO_REGISTER_GLOBALS', 1);
define('THIS_SCRIPT', 'testscript');
$specialtemplates= array(
'test_data'
);
require_once('./global.php');
// Die Daten aus dem Datastore lesen
$vbulletin->test_data = unserialize($vbulletin->test_data);
$setting =& $vbulletin->test_data;
$check = $setting['test']; // Test Eintrag im datastore
$db->query_write("
INSERT INTO " . TABLE_PREFIX . "test_tabelle
(
test_feld
)
VALUES
(
'" . $db->escape_string($check) . "'
)
");
?>
Nun möchte ich die Datei allerdings nicht direkt sondern über den Hook global_start aufrufen.
Das Spezial Tempate habe ich im Hook cache_templates untergebracht. (auch dann funktioniert der Datenbankeintrag noch, wenn ich das testscript direkt aufrufe.)
Nun will ich es aber global aufrufen, es soll also bei jedem Seitenrefresh ausgeführt werden.
Im Hook global_start habe ich nun folgenden Eintrag
include ('./testscript.php');
Im Hook cache_templates diesen:
$specialtemplates= array(
'test_data'
);
Der code des testscript ist nun dieser:
<?php
// ####################### SET PHP ENVIRONMENT ###########################
error_reporting(E_ALL & ~E_NOTICE);
// #################### DEFINE IMPORTANT CONSTANTS #######################
define('NO_REGISTER_GLOBALS', 1);
define('THIS_SCRIPT', 'testscript');
// Die Daten aus dem Datastore lesen
$vbulletin->test_data = unserialize($vbulletin->test_data);
$setting =& $vbulletin->test_data;
$check = $setting['test']; // Test Eintrag im datastore
$db->query_write("
INSERT INTO " . TABLE_PREFIX . "test_tabelle
(
test_feld
)
VALUES
(
'" . $db->escape_string($check) . "'
)
");
?>
Nun das Problem.
Liest mir das erste Script problemlos meine Daten aus dem Datastore und schreibt die Einträge absolut richtig in die neue Datenbanktabelle, so werden über dem global_start Aufruf, nur leere Einträge geschrieben.
Wie gesagt es wird eine neue Zeile in der test_tabelle angelegt nur ist der Inhalt des test_feld leer.
Keine Ahnung wo mein Denkfehler dabei ist.
Hat da jemand einen Tipp warum beim ersten Script das 'test_data' richtig ausgelesen wird und richtige Einträge gemacht werden und bei dem Scriptaufruf über global_start (oder auch gobale_complete) nur leere?.
Liebe Grüße
PcFreak
1). NO_REGISTER_GLOBALS ist bei 3.5 unnötig
2). Datastore sollte per build_datastore() aktualisiert werden, sonst kriegst du ggf. Inkonsistenzen wenn andere Klassen außer der Standardklasse vB_Datastore verwendet werden
3.) Du kannst per Plugin keine Datastore-Einträge lesen, da Plugins selbst Datastore Objekte sind.
Möglichkeiten: Query, File-Edit, oder Datastore Support for Plugins (http://www.vbulletin.org/forum/showthread.php?t=97054)
Dieser Beitrag ist privat und stellt keine offizielle Stellungnahme von Jelsoft dar
Hallo Andreas,
Mit deiner Datastore Support for Plugins Erweiterung klappt das alles ohne Probleme.
Allerdings erschliesst sich für mich dann nicht mehr der Sinn warum ich überhaupt einen Datastore anlegen soll.
In meinem Beispiel wollte ich (bzw. habe ich) in dem Datastore einige Settings geschrieben.
Das andere Script sollte dann die Settings einfach auslesen, damit ich in diesem Script damit weiterarbeiten kann.
Bisher habe ich die Sachen ja aus dem Datastore ja so ausgelesen:
$specialtemplates= array(
'test_data'
);
require_once('./global.php');
// Die Daten aus dem Datastore lesen
$test_data = unserialize($vbulletin->test_data);
Brauche ich ja mit deinem Datastore Support for Plugins nicht mehr machen, nur was bringt mir das tasächlich?
Theoretisch könnte ich dann aber auch die Settings in einer Tabelle schreiben anstatt in einem Datastore. Anschliessend dann mit einem query diese Tabelle im neuen Scrippt auslesen, um meine Settings zu erhalten.
Gerade das aber wollte ich mir ersparen (dieses query) denn ich habe bisher gedacht, dass diese datastore Methode wesentlich schneller ist.
Benutze ich aber nun dein Script, wird auch ein query ausgeführt. Im Endeffekt tut sich da doch nichts, oder?
Ach ja, danke für die anderen Tipps.
Viele liebe Grüße und auch von mir herzliche Glückwunsch zum offiziellen Namen Andreas den du wohl nun tragen musst ;)
Vielleicht solltest du deine Sig ändern in The Artist Formerly Known As KirbyDE :D .
PcFreak
Brauche ich ja mit deinem Datastore Support for Plugins nicht mehr machen, nur was bringt mir das tasächlich?
Der Sinn der Sache ist:
In Standard-Files kommst du an $specialtemplates wie schon erwähnt nicht ran.
Was aber wenn du in einer Standarddatei ein Plugin hast welches einen Datastore-Eintrag benötigt (z.B. die Spiderliste, oder einen eignene cache für Foren-Statsitiken, odteer whatever)?
Dann hast du ein Problem: Entweder Query - oder Datei ändern.
Benutze ich aber nun dein Script, wird auch ein query ausgeführt. Im Endeffekt tut sich da doch nichts, oder?
Nein. Wenn du das gemäßg Anweisung installiert hast und die benötigten Objekte im Datastore Item Manager eingetragen hast, dann werden die zusammen mit den Einträgen in $specialtemplates von init.php geladen. Das ist ja der Sinn der ganzen Übung.
Der Code macht zwar ein Query als Fallback wenn irgnedwas nicht funktioniert, aber wie gesagt - das sollte nie eintreten.
deine Sig ändern in The Artist Formerly Known As KirbyDE
Dann muss ich ja jedes mal wenn ich meine Sig sehe an Cat Steven denken ;)
Dieser Beitrag ist privat und stellt keine offizielle Stellungnahme von Jelsoft dar
Das sehe ich ein.
Hmm...
Mir gefällt deine Modifikation, weil es mir bei meinem aktuellen Problem hilft dieses zu umgehen.
Der Nachteil ist, schreibt man nun eine eigene Modifikation und möchte diese weitergeben, so braucht man einen Hack für den Hack :rolleyes:.
Benötigt man nur selbst sein eigenes PlugIn oder Produkt dann wäre das die ideale Lösung.
Hoffe ich mal auf ein vBulletin Patch :D (Die sollen ja nun ein ganz neues Entwicklungstalent mit in ihremTeam aufgenommen haben ;) ), wo dein Mod dann mit in der Soft integriert ist.
Liebe Grüße
PcFreak
Der Nachteil ist, schreibt man nun eine eigene Modifikation und möchte diese weitergeben, so braucht man einen Hack für den Hack.
Wohl wahr. Wobei sich der Aufwand in Grenzen hält; man kann das XML und Class File ja einfach mitdazupacken und halt in die Anleitung schreiben dass das zuerst installiert werden muss (wenn noch nicht vorhanden).
Dieser Beitrag ist privat und stellt keine offizielle Stellungnahme von Jelsoft dar
In der Hoffnung das hier Andreas noch einmal liest und mir eventuell einen entscheidenden Tipp geben kann. (Natürlich nehme ich Tipps auch gerne von anderen an ;))
Ich habe mir überlegt, dass ich um Settings auszulesen ja eigentlich keine eigene Tabelle oder einen Datastore erstellen brauche.
Ich könnte ja eine z.B. eine eigene Settinggroup erstellen und dort dann meine Settings eintragen welche ich später dann wiederum mit z.B. if ($vbulletin->options['test']) in meinen Scripten nutzen kann.
Das geht ziemlich einfach und lässt sich ja schnell realisieren.
Was mich allerdings zum einen stört ist, dass diese Einstellungsgruppe dann immer den anderen vBulletin Einstellungen angehangen wird. Zwar kann man diese auch einzeln anzeigen lassen, lässt man aber alle anzeigen, dann fängt natürlich die Rolltaste der Maus an zu glühen.
Nun zwei Fragen.
Kann man diese Anzeige unterdrücken? Sie soll also nur über einen extra Link in einem eigenen Menüpunkt aufgerufen werden in etwa so:
test.php?do=options&dogroup=meine_eigenen_einstellungen
aber nicht in den allgemeinen Einstellungen angezeigt werden.
Die zweite Frage wäre dann: Kann vBulletin beliebig viele Einstellungen verwalten?
Wenn ich nun meine eigenen Einstellungsgruppen mit duzenden von Einstellungen erstelle, wirkt sich das dann irgendwie auf die Geschwindigkeit oder Leistung von vB aus, weil diese mir dann ja in jedem Scrippt als vBulletin Option zur Verfügung stehen? Die werden doch gecached, oder? Bremse ich da vielleicht etwas aus?
Wenn das nichts ausmachen würde, dann wäre diese Methode die ideale Lösung für mich. Schnell zu scripten, macht wenig Aufwand und die Optionen bzw. Settings wären global nuztbar und man kann nicht viel mit Syntax etc. verkehrt machen.
Liebe Grüße
PcFreak
1) Verstecken geht, allerdings wird die dann auch bei dogoup=x nicht amehr angezeigt. Du müsstest dann eigenen Code (=> print_setting_group()) schreiben
2) Die Anzahl der Gruppen ist "unbegrenzt" (d.h. Grenzen setzt halt z.B. das Speicherlimit von PHP, aber bis das erreicht ist dürfte viiiiel Wasser den Main hinuntergeflossen sein).
Solange du nicht hunderte von Einstellungen hast dürfte das keinen Einfluss auf die Geschwindigkeit haben; braucht hat unr etwas mehr RAM.
Ich würde sagen: Einstellungen die du in Plugins brauchst als vBulletin Settings; den Rest abhängig davon wie umfangreich auch als Setting oder selbst verwalten.
Danke für die Antwort.
Ich werde dann mal mit dieser (=> print_setting_group()) experimentieren.
Ram spielt bei mir, da ich ja immer local code, erst sekundär eine Rolle
Was mein Hoster da für Hardware für mich übrig hat, weiß ich gar nicht. :confused: Da mache ich mich mal schlau. Wichtig war für mich halt zu wissen ob so ein Code mit vielen Settings ja dann nicht nur bei mir local oder auf meinem Forum, sondern auch auf Foren welche wo anders gehostet werden anständig läuft und nicht den Seitenaufbau verzögert oder andere Ressourcen frisst.
Dann werde ich mir mal nicht weiter den Kopf zerbrechen und meine Settings für Produkte oder PlugIns im debug Modus schreiben und dann exportieren und weiterbearbeiten. Das ist wirklich am elegantesten und spart jede Menge Arbeit.
Allerdings werde ich da wohl tatsächlich so einige, für das was mir vorschwebt, brauchen.
Allerdings gefällt mir auch diese datastore Methode, weil man tatsächlich nur eine Zeile mit zwei Feldern in der DB dafür braucht. Dabei es zudem keine Rolle spielt ob nun ein oder hundert Settings in diesem datastore String untergebracht werden.
Aber ich gehe mal lieber den einfacheren Weg.
Liebe Grüße
PcFreak
Wenn du du das Dingen sowieso per global_start laden würdest, ist es Jacke wie Hose - Array is Array; du brauchst also genausoviel oder wenig Speicher wie wenn du vboptions verwendest.
Letzteres in dem Fall sogar geringfügig weniger.
Nochmal: Solange du keine etliche Tausend Einstellungen verwendest ist der Overhead +- zu vernachlässigen.
Das sind sehr wichtige Informationen.
Man kämpft ja immer um jedes query und um den am geringst verbrauchten Ressourcen fressenden code.
------------
Liegt wahrscheinlich daran, dass man im geheimen hofft, mal ein Forum zu haben, auf welchen 10,000 User gleichzeitig unterwegs sind. Da muss man vorbereitet sein :p
Gruß
PcFreak
LocutusofBorg
26.10.2005, 04:34
Das sind sehr wichtige Informationen.
Man kämpft ja immer um jedes query und um den am geringst verbrauchten Ressourcen fressenden code.
------------
Liegt wahrscheinlich daran, dass man im geheimen hofft, mal ein Forum zu haben, auf welchen 10,000 User gleichzeitig unterwegs sind. Da muss man vorbereitet sein :p
Gruß
PcFreak
Dem kann ich nur zustimmen - ich kämpfe um jedes bißchen resource. Und das
schon bei 1700 usern gleichzeitig (weil wir jetzt ne Beschränkung drin haben)
Kennt denn jemand ein vBulletin mit hohen gleichzeitigen Zugriffen?
(>5000)?
Für 5000 Zugriffe pro Sekunde benötigt man sicher die doppelte Anzahl an Benutzern.
Hier findest du einige große Foren, aber außer dem Corvette Forum hatte wohl noch keins mehr als 5000 Benutzer online.
http://rankings.big-boards.com/?filter=vBulletin,all
vBulletin® v3.7.2, Copyright ©2000-2008, Jelsoft Enterprises Ltd.