2.8 RC1 Abwärtskompatibilität - Modulentwickler

[JayKay89]

Bereits probiert, gleiches Prob 

[aldus]

Unter "Optionen" -> "erweiterte Optionen" den PHP Error Level mal auf "E_ALL & Strict" gestellt und
dann Fehlermeldungen bekommen? Wenn ja - bitte hier posten oder pm.

Habe hier die "MPForm" (0.2.2 - von AMASP) unter einer svn #1086 (E_ALL & E_STRICT) installiert
ohne Probleme und es scheint zu laufen ... hm ... Evtl. einen Link zum ansehen posten?

Bei welchen Eingabefeldern hapert es denn? Bei allen? Hast Du evtl. von 2.6.7 direkt auf 2.8. RC1 upgegraded?

Gruß
Aldus

[Luisehahne]

Hm,

sehe da im Moment auch keine Probleme. Kompliment, gute Arbeit, Kann man nur empfehlen

Wie Aldus bereits geschrieben, ein paar mehr Infos.

Dietmar

[JayKay89]

Das Upgrade lief von 2.7 auf 2.8 RC1. Das genauere Problem hatte ich schon auf Englisch im entsprechenden Thread gepostet, die Kurzform hier:

Wenn ich die Optionen öffne, dann ist die Einstellung für "Feld Schleife" (ohne sie jemals angerührt zu haben!):

<tr><td class="mpform_title">:</td><td class="mpform_td_help"></td><td class="mpform_field"></td></tr>

Dort fehlen also alle dynamischen Felder, die erst im Frontend durch ihren wirklichen Inhalt ersetzt werden sollten. Sobald ich die Optionen also speichere, sind die Platzhalter weg und das Formular wird ohne Labels und Inputfelder ausgegeben.

Edith sagt: Sorry, hätte erwähnen sollen, dass es keine Fehlermeldung gibt, sondern lediglich die Funktion beeinträchtigt ist...

[FrankH]

@JayKay89

Welche Version von mpform hast du denn im Einsatz?
Wie gesagt, die letzte auf AMASP ist die 0.2.2


Noch was (damit ich versuchen kann, das zu reproduzieren):
Hast du mpform vor oder nach dem Update auf 2.8 installiert?

[Luisehahne]

Ich habe gerade nochmal getestet. Habe mit MpForm ein Formular angelegt und die Daten des Form in WB  sind weg. Umgekehrt genauso. Oder darf nur das Ein oder Andere nehmen und nie beide zusammen einsetzen?

Dürfte ja eigentlich nicht sein, das das mpform andere Tabellen hat.

Dietmar

[FrankH]

OK, ich probiere das mal aus. Wird aber wohl erst am Wochenende, habe bis dahin lauter Termine.

[Luisehahne]

MAg auch sein, dass es hier dran liegt. Hatte nämlich den selben validen Fehler in der normalen Form. Schau mal in die view.php und lösche folgende Zeilen.

// obtain the settings of the output filter module
if(file_exists(WB_PATH.'/modules/output_filter/filter-routines.php')) {
    include_once(WB_PATH.'/modules/output_filter/filter-routines.php');
    $filter_settings = get_output_filter_s ettings();
} else {
    // no output filter used, define default settings
    $filter_settings['email_filter'] = 0;
}

Diese Funktion ist ebenfalls in der index.php im rootverzeihnis enthalten. Es wird einmal dir Droplets durchlaufen und dann der Outputfilter. Ob jetzt der beschriebene Fehler damit zusammenhängt muss ic hnoch testen. Auf jedenfall sind jetzt beide Form Module vailde.

Dietmar

[FrankH]

Ich hab mich noch nicht mit output filter module beschäftigt (schäm).
Was macht das eigentlich und was hat sich da von 2.7 auf 2.8 geändert?

[Luisehahne]

Das ist das E-mail Filter (at) (dot) und crypted E-Mail. Die läuft ja jetzt auch über Droplets. Um nach unten kompatible zu bleiben, ist die outputfilter noch drin. Ich halte dich auf dem laufenden, da das ja in dem alten Form auch drin ist. Will das kurz im DEV-Team ansprechen, damit wir keine Fehler machen. Kann dir ja dann eine PM schicken, damit du fixen kannst.

Dietmar

[Luisehahne]

Hallo FrankH,

zur Info, Einfach die Zeilen löschen geht auch nicht so ohne weiteres, da vor dem Senden die $filter_settings['email_filter'] abgefragt wird, die jetzt nicht mehr da ist. Sobald eine Lösung da ist, informiere ich dich. Es muss ja auch gesichert sein , dass die Filterroutine in der index.php im Root Verzeichnis ( da wo auch die config.php liegt) die E-Mail Adressen sauber umsetzt.

Dietmar

[JayKay89]

Habe das MPForm erst hinterher installiert, also nach dem Update. Die Felder sind ja soweit auch da, ich kann sie also weiterhin bearbeiten etc., im Backend also alles wie gehabt. Lediglich führt das Ausführen der Optionen-Seite und dem Speichern der Einstellungen dazu, dass im Frontend nur noch die Doppelpunkte zu sehen sind...

Ich hab mir mal ein Backend-Theme angesehen und gehe schwer davon aus, dass die Template-Engine zum generieren der Ausgaben im Backend die {} stehenden Teile der Vorlagen für das Formular löscht. Wenn man auf der Optionen-Seite mal den Code ansieht, so sieht man auch, dass da die variablen Platzhalter fehlen...

Kleines edit: Version von MPForm ist die neuste, also 2.2
Edit 2: Daran kann es nicht liegen, da bereits im Backend die Platzhalter entfernt werden, woher auch das Problem rührt...

[Luisehahne]

Danke dir,

Ich denke FrankH und ich werden das alles mal durchchecken und sind natürlich für jeden Hinweis dankbar. Bis zur Final soll ja alles laufen wie gehabt.

Dietmar

[FrankH]

Also meine Forschung hat ergeben, daß es was mit dem Template-Objekt zu tun haben muss.
Wenn ich im mpform in modify_settings.php die Zeile 47 ändere in

Code:

$tpl->set_unknowns('keep');

dann funktioniert alles wie gehabt.

Das Template-Objekt scheint also neuerdings nicht nur wie gehabt die htt-Datei zu manipulieren, sondern in einer Art von Übereifer auch gleich noch die Austauschvariablen selbst? Sieht so aus, als ob das fertig geparste Template versehentlich ein zweites mal geparst wird, wobei die Felder dann rausfliegen, wenn man "remove" eingestellt hat.

[Luisehahne]

Hallo FrankH,

danke fürs testen. Werde das in der Form auch mal testen. Wie sieht das bei dir mit der Fehlermeldung aus. mpform hat genau dieselben 10 errors wenn du vailidierst wie das form. Und das liegt definitiv an Outputfilter Abfrage (wegen der E-Mails), da der buffer nach ob_start(); geleert wird.

Dietmar

[Luisehahne]

Hallo FrankH,

Das ist das Problem in beiden Forms

It is a known issue that the form module tried to stop the outputfilter to function.
This is because the email addresses submitted in the form should not be translated.

If you do not use the old emailfilter this error (notice) should not happen.

Das war es was ich meinte

Dietmar

[FrankH]

Hallo Dietmar,

wir reden wohl wieder mal über verschiedene Sachen?

Ich rede über den Fehler, den JayKay89 gemeldet hat:
Im Backend in den Optionen für ein Formular verschwindet bei der Anzeige "{...}"
Für die Anzeige ist modify_settings.php zuständig, und in dieser Datei wird gar kein output_filter aufgerufen.
Die view.php ist für das Frontend zuständig, hat mit der Fehlfunktion im Backend also nix zu tun.

Die Ursache liegt in einer fehlerhaften /include/phplib/template.inc
Wenn ich die Version aus 2.8RC1 (vom 6.11.2008) nämlich durch die 2.7er Version (vom 6.4.2008) ersetze, ist der Fehler weg.

[Luisehahne]

Hi,

ja wir reden über 2 verschiedene Probleme. Da wir beide aber auch Wert auf validen Code legen, wollte ich nur auf das Problem in der view.php hinweisen.

Also 2 Fehler die ausgemerzt werden sollten.

Dietmar

[ruebenwurzel]

Hallo,

Die Ursache liegt in einer fehlerhaften /include/phplib/template.inc

Gibt es da vielleicht inzwischen eine fehlerbereinigte Version von phplib? Kann sich da mal jemand schlau machen? Kann ja noch in 2.8 eingebaut werden.

Matthias

[Luisehahne]

Hallo,

soweit ich das verfolgen konnte leider nicht.

Dietmar

[ruebenwurzel]

@FrankH

Dann kann das ganze nur an dem Fix von thorn liegen, den dieser extra für WB eingefügt hat:

Original:

Code:

function pparse($target, $varname, $append = false) {
    if ($this->debug & 4) {
      echo "<p><b>pparse:</b> passing parameters to parse...</p>\n";
    }
    print $this->finish($this->parse($target, $varname, $append));
    return false;
  }

Geändert:

Code:

function pparse($target, $varname, $append = false, $clear = true) { // added $clear: whether to delete undefined vars or not (needed for wb-module code) - thorn
    if ($this->debug & 4) {
      echo "<p><b>pparse:</b> passing parameters to parse...</p>\n";
    }
        if(!$clear) {
            $unknowns = $this->unknowns;
            $this->set_unknowns('keep');
            print $this->finish($this->parse($target, $varname, $append));
            $this->set_unknowns($unknowns);
        } else {
            print $this->finish($this->parse($target, $varname, $append));
        }
        return false;
  }

Kann jemand mal checken, ob der veränderte code benötigt wird, oder ob man lieber die original phplib Dateien benutzen sollte.

Matthias

[FrankH]

Hi,

ja wir reden über 2 verschiedene Probleme. Da wir beide aber auch Wert auf validen Code legen, wollte ich nur auf das Problem in der view.php hinweisen.

Also 2 Fehler die ausgemerzt werden sollten.

Dietmar

Hallo Dietmar,

Also ich habe gerade mal eine Testseite mit mpform unter Wb 2.8 gebastelt, da gibt es keine Validierungsfehler im Frontend, wenn man den Fehler im Backend weggemacht hat. Scheint also doch nur der eine Fehler zu sein?

[FrankH]

@Matthias,

Dann kann das ganze nur an dem Fix von thorn liegen, den dieser extra für WB eingefügt hat:

Also hier muss eine Verwechslung vorliegen:

• Was du als Original bezeichnest, ist die nicht funktionierende Version vom 6.11.2008, die mit WB 2.8 geliefert wird.
• Was du als geändert bezeichnest, ist die funktionierende Version vom 24.4.2008, die mit WB 2.7 geliefert wird, die den Patch von Thorn enthält.

Ich schlage vor, die Version aus WB 2.7 in 2.8 zu übernehmen.

[Luisehahne]

Genau, wenn das dann damit funktioniert. In der 2.8 ist diese Änderung nicht nicht drin

Dietmar

[ruebenwurzel]

Hallo,

Also hier muss eine Verwechslung vorliegen:

    * Was du als Original bezeichnest, ist die nicht funktionierende Version vom 6.11.2008, die mit WB 2.8 geliefert wird.
    * Was du als geändert bezeichnest, ist die funktionierende Version vom 24.4.2008, die mit WB 2.7 geliefert wird, die den Patch von Thorn enthält.


Ich schlage vor, die Version aus WB 2.7 in 2.8 zu übernehmen.

ooops, da hab ich beim vergleichen wohl die Versionen vertauscht. Mysteriös, mysteriiös, mal nachforschen, warum das rausgeflogen ist. Vermute mal eher aus versehen. Werde die template.inc wieder hersetzen.

Matthias