Das mag sein - das ändert aber nichts daran das wir, so wie ich das interpretiere die Seiten- und Formularstruktur nicht "verändern" dürfen damit dieses Tool weiterhin funktioniert oder?
Verändern kann man alles. Wenn es eine Stelle betrifft, die auch von Ocprop genutzt wird - das betrifft ein paar Promille des OC-Programmcodes - muss man ggf. einen Ocprop-Workaround einbauen.
- Templates / Seitenlayout / CSS: Hier gibt es nur wenige Ocprop-Abhängigkeiten (ca. 15 HTML-Codezeilen). Dort schreibt man notfalls den von Ocprop erwarteten Content in einen HTML-Kommentar.
- search.php: Muss bei den Parametern ohnehin 100% abwärtskompatibel bleiben, also Ocprop stört nicht weiter.
- log.php / editlog.php: Hier gibt es keinen Bedarf für eine Umstrukturierung der Formularparameter; log.php wurde auch schonmal komplett neugeschrieben, ohne dass Konflikte mit Ocprop entstanden.
Bleiben noch die übergebenen Parameter für newcache / editcache / newdesc / editdesc. Da müsste man Arbeit in Ocprop-Workarounds investieren bzw. alten Code mitschleppen, falls man die die
Logik dieser Seiten überarbeiten möchte.
Kannst Du mir den Suchstring verraten? Piwik schweigt sich dazu aus. Wir wollten das im Vorfeld nämlich auch schon mal nachvollziehen.
Ocprop/2.22 (MSWin32)
Ocprop/2.21 (MSWin32)
Ocprop/2.21 (linux)
Ocprop/2.21 (darwin)
Ocprop/2.20 (MSWin32)
Ocprop/2.18 (linux)
@SammysHP
Da hatte ich was falsch in Erinnerung. Ocprop arbeitet tatsächlich sehr ähnlich wie cmanager. Trotzdem dürfte cmanager in der aktuellen Version eine höhere Zuordnungsquote haben, weil er
zusätzlich zur eigenen Heuristik die gewartete Wegpunktdatenbank des OC-Teams nutzt. Die Logbilder könnte man beim cmanager noch nachrüsten.
Bleibt also der Abgleich von Listings - hier gibt es keine Alternative zu Ocprop. Wenn man den alten Ocprop-Zopf abschneidet, geht diese Möglichkeit verloren.