<td class="edittext">
<input type="text" class="editinput" size="32" maxlength="[B][{$edit->oxarticles__oxean->fldmax_length}][/B]" name="editval[oxarticles__oxean]" value="[{$edit->oxarticles__oxean->value}]">
[{ oxinputhelp ident="HELP_ARTICLE_MAIN_EAN" }]
</td>
Hat wer vielleicht zufällig parat wo OXID sich die Feldlänge für die EAN herholt? Das Tabellenfeld hab ich erweitert, aber ich finde nirgends wo OXID das Eingabefeld auf 13 Zeichen begrenzt.
Das [B]fldmax_length[/B] kommt immer aus der Datenbank. Dort sind die auf [B]128[/B] Zeichen begrenzt.
maxlength="128"
Grüße
Rafig
Welche Shop-Version ist das? Das Feld sollte seit der 5.2.0/4.9.0 eine Länge von 128 haben: http://wiki.oxidforge.org/Downloads/4.9.0_5.2.0#Fields_length_was_changed
Im Template wird auf ein Attribut des oxField-Objektes zugegriffen, das wiederum aus der MySQL-Tabelle stammt. Hast du schon das tmp-Verzeichnis geleert und die Views neu generiert? 
Danke für Eure Antworten.
Sorry, ist Version 4.8.7.
Das Tabellenfeld in der DB ist 13 Zeichen, die Maxlength des Input ebenfalls und in der config hab ich keinen Eintrag gefunden wo ich das ändern kann.
tmp und views hab ich upgedated, allerdings ohne Effekt.
Also du hast den Wert
oxarticles => oxean => varchar(128)
auf [B]varchar(13) [/B]geändert und es passiert nicht? Oder warst du aus versehen bei
oxarticles => oxdistean => varchar(128) ?
Grüße
Rafig
Du musst die Eigenschaften des Felds in der Datenbank ändern, alles andere ergibt sich automatisch daraus (außer vielleicht die DataProperties von GoodRelations, vgl. den Pull-Request).
Der SQL-Query würde ungefähr so aussehen:
ALTER TABLE `oxarticles` CHANGE `OXEAN` `OXEAN` VARCHAR( 128 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '';
nein @Rafig, umgekehrt. Das Feld ist varchar(13) und das ist zu kurz und ich will es erweitern. Hintergrund ist die EAN-Pflicht bei ebay. Der Alternativwert, sollte keine EAN vorhanden sein, ist “nicht zutreffend”, was sich nicht in 13 Zeichen unterbringen lässt.
@martin, Danke, das hab ich eigentlich gemacht, allerdings hab ich das Feld direkt in der DB erweitert. TMP gelöscht und Views generiert, es hat sich aber nichts geändert. Das Feld in der Artikelbearbeitung hat trotz allem noch eine maxlength von 13 Zeichen. Deshalb meine Vermutung, dass da noch irgendwo in einer Funktion oder in der config der Wert gesetzt wird. Ich werde das mal in einer frischen Installation ohne Module testen.
Habs mal in der Oxid 486 Azure Demo-Version getestet und es funktioniert nach Erhöhung von varchar(13) auf z.B. 30 wie gewünscht:
… sollte keine EAN vorhanden sein, ist “nicht zutreffend …” - im Admin und Frontend getestet.
In meiner Testumgebung hat es auch funktioniert nur auf dem Live-System nicht.
Habs aber hinbekommen, hab alle Module deaktiviert und die Views dann von Hand aus der DB gelöscht.
Hast Du die Views gelöscht oder meinst Du eigentlich geleert?
Es scheint jedenfalls kurios, dass es mit Views Update nicht geht.
Da stellt sich auch die Frage: Bringen die Views überhaupt noch einen merklichen Vorteil auf aktuellen “state of the art” Servern mit PCI-Express SSDs?
OK, dann also gelöscht und per SQL-Statement wieder neu hergestellt.