Recent Posts

Pages: [1] 2 3 ... 10
1
back to the real problem....

meines Erachtens ist solch Modifikation einer addon-Installation VOR dem eigentlichem Install mit diesem aktuell verwendetem Verfahren und diesem Core nicht möglich. Als Beispiel mal: Ich wähle VOR der eigentlichen Installation aus, welche Plugins mit auf den Server kopiert und auch aktiviert werden sollen

Dazu müßte man das aktuell verwendete ZIP entpacken, umschreiben, neu packen, installieren

Es würde wohl gehen, wenn ich mir das Paket online zusammen stelle, wie das eben der aktuelle CKeditor macht.
Über solche Pläne mußt du die Entwickler befragen
2
>>man muß es eben auch richtig lesen
Auch mir passiert das?  Wie komm ich da wieder raus  :-D :-D :-D
Schönen Resttag noch.
MfG. Evaki
3
Nachtrag: was auf den von dir verlinkten Seiten steht, z.b. die deprecated list, ist schon verläßlich. Aber man muß es eben auch richtig lesen

wenn durchgestrichen, dann nicht mehr gültig. Diese Informationen wurden allesamt mal so verbreitet, zu früheren Zeiten und ggf auf eine andere WB_Version bezogen. Diesen Punkt nun einfach zu löschen, hieße: es ist unbeantwortet, keine gegensätzlichen Informationen.

Durchgestrichen heißt, die Plan existierte, wurde aber korrigiert / verworfen
4
Nun gut.
Da werd ich halt eben das ein oder andere Mal nachfragen, wie eben zum Betreff.
 
MfG. Evaki
5
doch, doch, was Genaues weiß man schon, der zugriffsberechtigte n Person fehlt die Zeit, den anderen der Zugriff  ;-)

Nach Einstellung des 2.8.4-er Entwicklungsstrange s im Juni/Juli 2015 wurden viele Sachen in die nächste Version übernommen, sollte einleuchtend sein, z.b. der Cache für die Sprachvariablen. Dieser reduziert die Anzahl der zu ladenen Variablen, die in früheren Versionen auch mehrfach durch diverse Addons geladen wurden, auf ~ 10% der früheren Menge.

Keine Ahnung, ob es eine Liste in Schriftform gibt. Falls JA, braucht es schon fast eine Vollzeitkraft, um sie zu verwalten und ständig Up-to-Date zu halten. Die Personen, die damit zu arbeiten hatten (Modul-Autoren, Supporter etc), wissen aber schon Bescheid und das meiste davon wurde auch hier und da öffentlich kommuniziert
6
nur informatorisch für den Fall, das jemand irgendwo Sprachvariablen korrigiert / ersetzt / für sich anpasst: es ist zwingend erforderlich, nach jeder Änderung an Sprachdateien des Cores und auch aller Addons, den Sprach-Cache zu löschen
Entweder in Info-fenster über den Link Clear Translate Cache oder manuell über den Datei-Explorer im Ordner temp / cache alle Dateien löschen
7
Salopp gefragt: Irgendwie auf dem Niveau "Nix genaues weiß man nix"?
Im aktuellen Code-Module scheint ein Teil dessen umgesetzt worden zu sein.

Werden/wurden irgendwo verläßliche Informationen hinterlassen, und als solche auch gekennzeichnet?
MfG. Evaki

Edit: Aus dem Sandkasten ruft gerade jemand. Da stellt sich jemand vor, die (erweiterte) Installation übern Adminbereich zu machen, statt über "Erweiterungen".
8
Diese Informationen stammen aus der WB 2.8.4, da war das in der Tat geplant. Es gab auch ein paar Addons damit und die WB.2.10.x kann das auch abarbeiten. Ob das der neue Trend für Addons wird, kann ich dir nicht sagen. Hab so lang nach Informationen darüber gebettelt, das es mir überdrüssig wurde.
Das Wiki ist ein Single-User-Projekt, niemand weiter hat da Schreibberechtigung en. Von daher war es auch nicht möglich, Inhalte anzupassen. Du kannst davon ausgehen, das so gut wie überall, wo jetzt WB. 2.10 dran steht, vorher WB 2.8.4 stand. Also nicht so ernst nehmen. ;-)

P.S.: wenn durchgestrichen, dann nicht mehr gültig. Diese Informationen wurden allesamt mal so verbreitet, zu früheren Zeiten und ggf auf eine andere WB_Version bezogen. Diesen Punkt nun einfach zu löschen, hieße: es ist unbeantwortet, keine gegensätzlichen Informationen.

Durchgestrichen heißt, die Plan existierte, wurde aber korrigiert / verworfen
9
definiert wird der Wert in der Datei framework/class.wbmailer.php // Zeilen an 130 in diesem Code

Code: [Select]
// set default charset
        if(defined('DEFAULT_CHARSET')) {
            $this->set('CharSet', DEFAULT_CHARSET);
        } else {
            $this->set('CharSet', 'utf-8');
        }

Das Ganze wird dann an den PHPMailer gesendet und nicht vorhandene Werte ersetzt bzw anders herum - alle überlieferten Werte ersetzen die Standardwerte des PHPMailers. Meiner Meinung nach ist es technisch möglich, das die Konstante DEFAULT_CHARSET wohl definiert wurde, also TRUE ist, aber keinen Wert hat. Das könnte der Fall nach einem Upgrade sein, wenn der Wert in der Datenbank ggf geändert wurde

Variante 1: im Info-Fenster (i-Button) das Upgrade-Script noch einmal starten, danach erneut testen

Variante 2: in der Datei framework/class.wbmailer.php im oben gezeigten Code mal diese Zeile hier abändern auf

original
Code: [Select]
$this->set('CharSet', DEFAULT_CHARSET);
testweise
Code: [Select]
$this->set('CharSet', 'utf-8');
damit möchte ich umgehen, das die Konstante leer ist
10
Dieda:
https://wiki.WebsiteBaker.org/doku.php/dev/284/deprecated
https://wiki.WebsiteBaker.org/doku.php/dev/284/helloworld#infophp_bis_zum_01062015_noch_erforderlich

MfG. Evaki
p.s. Vielleicht bastelt irgendwann jemand 'ne Dockingstation für's CMS  :-D  :-D  :-D   -  wohl aber erst, wenn 'ne Registry zur Verfügung steht.
Pages: [1] 2 3 ... 10
postern-length