Copy Templatevorlage bringt Fehler

[kukki]

Zur Sicherung einzelnen Elemente lege ich auch von einer Vorlage vor einer Änderung eine Kopie an, dafür war bisher der Copy-Button hilfreich.
In der Version 1.8.5 (2017/01/03, r544) gibt es einen Fehler, egal in welchem Browser, die Version wurde im Januar 2017 auf den Server gebracht.:

Method Not Implemented

POST to /phpwcms.php not supported.

Kann mir das jemand bestätigen? Fragt sich, ob dieser Fehler bei einem Update auf 2017/01/05-Version weg sein soll. In 1.8.4 funktioniert es:
Als Erklärung wir mir das im Netz angezeigt:

POST: Daten an den Webserver senden, wie 1) Eine Nachricht an ein Bulletin Board, eine Newsgroup oder Mailingliste posten, 2) Eingabedaten - üblicherweise aus einem CGI-Formular - an einen Datenverarbeitungsprozess übergeben, 3) einen Eintrag direkt zu einer Datenbank hinzufügen.

[kukki]

Nach den Update auf 1.8.7 kommt dieser Fehler:

Parse error: syntax error, unexpected T_STATIC, expecting T_STRING or T_VARIABLE or '$' in /.../include/inc_lib/classes/class.convertibletimestamp.php on line 176

Habe erst einmal alles wieder in die Ausgangssituation gebracht.

Ich habe den Fehler eingegrenzt:

Erstelle ich eine neue Vorlage, kann man step by step jeden Abschnitt copy&paste erstellen und am Ende sichern. Aber eine Änderung an dieser neuen Vorlage funktioniert dann auch nicht und endet mit dem oben beschriebenen Fehler.
UND: die costumer-Blöcke sind nicht mehr in der neuen Vorlage enthalten, die sind einfach weg!

[Oliver Georgi]

Lässt sich nicht nachvollziehen, die angesprochene Class kommt nicht mal zum Einsatz, also ist dir sicher etwas grundsätzlich durcheinander geraten und nicht alle Dateien wurden korrekt aktualisiert.

Sicher eine ressourcenlimitierte PHP-Version, musst du dort suchen.

[kukki]

nach einigen tiefergehenden Suchereien habe ich folgendes herausgefunden:
Die PHP Version ist 5.6.
das hier könnte ein Problem sein, was sich nach einem Umzug einstellte, eventuell durch verkehrte DB-Kollationen?
Die Datenbank wurde neu initialisiert und wie mir der Betreuer mitteilte, hat man die Daten da dann importiert. (keine Angaben weiter ) Dann wurde noch eine neuere Version aufgespielt (1.8.2), die ich nach einigen Problemen auf der Website mit 1.8.5 im Januar 2017 noch einmal aktualiserte - und da lief alles. Ich habe mir keinerlei Gedanken gemacht, was man mit der Datenbank angestellt habe, lief ja auch alles. Nur eben jetzt gibt es das Problem mit der Vorlage, die zu ändern war.

In Myphpadmin steht UTF-8, in der Config steht aber ISO-8859-1 Wenn man dann die config auf UTF-8 umstellt, verschwinden wegen der Sonderzeichen einige Arikel - spricht die Sonderzeichen blenden die Überschriften etc. aus. Aber die Vorlage ließ sich dann ändern. Scheint also ein "Post to"in die DB die ganze Sache zu behindern

Dann habe ich mal versucht - ich habe ja eine Datensicherung - das mit 'nem Script zu reparieren und die DB auf UTF-8 zu konvertieren....

Code: Select all

Habe ich wieder entfernt

Leider fehlt mir die tiefergehende Sachkenntnis weil nach Eintragen der connect-Daten kommt die meldung:

Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in /home/www/webXXX/html/DB/DBkonvert.php on line 6 Finished!

Was muss hier zu ändern sein, damit die Konvertierung richtig läuft?

[kukki]

Ich bin nun am Ende von meinem Latein. Ich habe kurzer Hand alles von heute früh zurückgespeichert und der Zustand ist der von Version phpwcms 1.8.5 (2017/01/05, r544). Bei Speichern der Vorlage (egal ob man geändert hat oder nicht) kommt die Fehlermeldung:

501 Method Not Implemented
POST to /phpwcms.php not supported.

Die costumer-Blöcke sind beim Kopieren vorhanden.
Bei Neuanlage sind diese nicht in der Vorlage als leere Blöcke.

Die DB/ config-Einstellungen sind wie folgt:

Zeichensatz / Kollation der MySQL-Verbindung Dokumentation: latin1_germany_ci
In der Datenbank tauchen aneinigen Stellen auch MyISAM latin1_swedish_ci auf

In der config findet man:

Code: Select all

$phpwcms['charset']  = 'iso-8859-1';

Es gibt keine Umlautprobleme, weder im Backend noch im Frontend.

Ich konnte nicht rausfinden nach Befragung des ehemaligen Betreuers, was dort gelaufen ist oder nicht

[Oliver Georgi]

Wie ich schon heute morgen schrieb, grundsätzliches Konfigurationsproblem. Dein Provider hat sicherlich irgendeine neue Direktive eingeführt, oder Du selbst in der .htaccess.

[kukki]

.htassec habe ich nichts dran gändert.
Habe eben mit dem Support wieder telefoniert, der entspr. Mitarbeiter war nicht am Platz, - aber es scheint Änderungen am php-System gegeben zu haben. Ich bleibe mal dran und poste dann was hier passiert sein kann.

PS.: Der Verdacht scheint sich zu bestätigen, Providerproblem PHP, weil ich habe jetzt bei mindestens 3 weiteren Websites diesen 501 Fehler oder Forbidden gefunden und das kann nicht sein.

Ausgelöst wird das duch einen Eintrag wie folgt:

<!-- ---touchfriendly menülayout-------------- -->
<!-- JS:
;(function( $, window, document, undefined )
{
$.fn.doubleTapToGo = function( params )
{
if( !( 'ontouchstart' in window ) &&
!navigator.msMaxTouchPoints &&
!navigator.userAgent.toLowerCase().match( /windows phone os 7/i ) ) return false;
this.each( function()
{
var curItem = false;
$( this ).on( 'click', function( e )
{
var item = $( this );
if( item[ 0 ] != curItem[ 0 ] )
{
e.preventDefault();
curItem = item;
}
});
$( document ).on( 'click touchstart MSPointerDown', function( e )
{
var resetItem = true,
parents = $( e.target ).parents();
for( var i = 0; i < parents.length; i++ )
if( parents[ i ] == curItem[ 0 ] )
resetItem = false;
if( resetItem )
curItem = false;
});
});
return this;
};
})( jQuery, window, document );
-->

Wenn diese Codezeilen nicht enthalten sind (ich habe diese im Footer untergebracht) gibt es keine Fehler
PS.: Bestätigung vom Provider liegt vor, die Systemadmins stellen seit twei Tagen gerade alles wieder zurück - sorry wenn ich die Pferde scheu gemacht habe, aber an irgend einer Stelle fängt man an an sich selber zu zweifeln