zukünftige Updates von WordPress sollen einfacher werden, analog zu dem bereits jetzt schon existierenden Update-Mechanismus für WordPress-Plugins seit der Version 2.6. Selbstverständlich sind damit nicht etwaige Kompatibilitätsprobleme zu eingesetzten Plugins aus der Welt geschafft, wenn man eine Versionsnummer hochgeht. Aber ich rechne damit, dass die Macher von Automattic auch das eines Tages in Angriff nehmen werden (zB zertifizierte Plugins, die bis zu einem gewissen Grad upgrade-sicher sind). So wird also Schritt für Schritt die Software stetig massenkompatibler, denn die Update-Arien waren seit jeher nicht nur wegen Plugin-Inkompatibilitäten, sondern auch wegen dem gefühlten Zeitaufwand und den dazu relativ komplexen Schritten ein Dorn im Auge des Users.
Nein, WordPress 2.7 ist noch nicht offiziell verfügbar. Verfolgt einfach dazu das Blog von Perun, das regelmäßig über die Neuerungen berichtet, die mit 2.7 einhergehen.
ein traum! 🙂
wenn das allerdings so funktioniert wie bei den plugins (nämlich gar nicht, zumindest bei mir) dann können die sich die arbeit auch sparen. 🙁
tja, wie gesagt:)
@paulinepauline bist Du vlt. bei Strato? Frag mal bei Deinem Hoster nach, ob er (oder sie hehe) php curl unterstützt. Gleiches Problem hab ich nämlich bei Strato so ein mist. naja, frau kann halt nicht alles haben.
nee, bei hosteurope. kein plan, was die fehlermeldungen mir sagen wollen, irgendwelche unverständlichen warnings …
Ist halt immer eine Frage der Schnittstelle und wie stark sich die Pluginentwickler daran halten. So müsste es aussehen:
WordPress DB Tables – WordPress PHP – API – Plugin PHP – Plugin DB Tables
Sobald ein Plugin WordPress PHP verändert (bzw. dortige Funktionen ersetzt oder direkt auf die WP Tables zugreift) ist der große Knall vorprogrammiert. Auf der anderen Seite muss WP auch umsichtig mit der API umgehen. Soll eine Funktionalität geändert werden, darf nicht einfach die Definition oder die Ausgabe der Funktion alte_funktion() verändert werden. Eine Änderung der API müsste über die Versionsnr. ersichtlich sein. So könnte man vorgehen:
2.6.x -> Es gibt alte_funktion()
2.7.x -> Es gibt neue_funktion(), alte_funktion() bleibt erhalten – auch wenn die Ausgabe anders konstruiert werden muss.
2.8.x -> alte_funktion() wird gestrichen, es gibt nur noch neue_funktion()
Ich weiß nicht, wie genau bei WP darauf geachtet wird (zumindest in Teilen wird so vorgegangen), jetzt liegt es bei den Plugin-Entwicklern dies zu berücksichtigen… und schon werden die Probleme minimiert.
das geht nur im Sinne einer Kompatibilität, indem man Standards aufsetzt, an die sich ein Plugin-Developer zu halten hat, sonst wird sein Plugin nicht im Pool aufgenommen. Die gibt es aber so noch nicht, was die Aufnahme des Plugins ins Repository angeht.
Der Standard ist eigentlich durch die API bereits vorgegeben… nur hast du natürlich Recht: es gibt keinerlei Qualitätskontrolle bei eingestellten Plugins, womit man als Nutzer selbst überprüfen muss, ob das Plugin problematisch ist. Nur können dies viele Nutzer nicht (was ja auch in dem Sinne gewollt ist, da sich WordPress nicht nur an PHP-Bastler richtet).
Evtl. müsste man eine Community ins Leben rufen, die ehrenamtlich die eingestellten Plugins überprüft und quasi ein Community-Zertifikat vergibt. Dumm nur: Wenige „Prüfer“ werden das „Pluginaufkommen“ (inkl. Updates der einzelnen Plugins!) kaum bewältigen können, viele „Prüfer“ erschweren es, die Qualität der Zertifizierungen sicherzustellen.
kann man mit Sicherheit auch automatisieren, da es sich wohl nur um bestimmte, kompatibilitätskritische Funktionen handeln wird und die man wohl durchaus erkennen kann. Erleichtert ein wenig die Kontrollarbeit. Zumindest würde es für eine Ampel-Funktion reichen, die einem User anzeigt, dass bei einem Upgrade von WP ein Plugin Mucken machen könnte.
Sicher… was die Funktionen angeht ist es kein Problem die einzelnen Skripte nach der Verwendung bald nicht mehr verfügbarer Funktionen zu untersuchen. Direkte Zugriffe auf die WP-eigenen DB-Tabellen können aber schwerer zu entdecken sein, da die Datenbankqueries meist wieder aus verschiedenen Variablen zusammengebaut werden.
Per WP Plugin kann man dann tatsächlich eine Ampel anzeigen, z.B.
Grün: Plugin ist jetzt und in überschaubarer Zukunft kompatibel.
Gelb: Plugin wird in überschaubarer Zukunft inkompatibel.
Orange: Plugin ist beim nächsten Update inkompatibel.
Rot: Plugin ist jetzt inkompatibel oder Plugin führt nicht erlaubte Zugriffe durch.
Wenn dieses Plugin dann vielleicht sogar den Weg vom Plugin zum WP-Bestandteil schaffen würde, könnten rote Plugins automatisch deaktiviert werden (bzw. orange vor dem Autoupdate). Als Plugin darf es das natürlich nicht, da es sonst gegen die eigenen Kriterien verstößt 😉
Mal sehen… wenn die Seminararbeit auf meinem Schreibtisch fertig ist schaue ich mal, ob ich Langeweile habe.
richtig schön finde ich, dass es blogsysteme gibt, die solche update-mechanismen schon seit jahren bieten. und das funktioniert sogar mit plugins und bietet ein repository. 🙂 ich hab ja den wordpress-hype noch nie verstanden…
Die Update-Funktionalität und deren Probleme von Plugins liegt oft an den Autoren von Plugins, nicht an WordPress. Ob Peruns Blog der richtige ist, um über Neuerungen des System zu informieren, hmm – WPD ist da sicher eine bessere Adresse, zumindest gibt es in den letzten Wochen hinreichend Information dazu.
Perun informiert sicher gut über Funktionen aus Sicht des Anwenders, aus der Oberfläche etc. Aber gerade 2.7 ändert sich täglich und da kann schon der eine oder andere Post schnell überholt sein, wie auch schon andere im deutschen Bloggerkreis bemerken mussten.
Nochmals als Ergänzung zur der sehr oberflächlichen Info. Das automotische Update prüft eine Reihe von Daten. Ebenfalls ist es so, dass man aus dem Backend heraus direkt ein Plugin installieren kann und dabei prüft WordPress und gibt die Info, wenn es entweder nicht unter der jeweiligen Version getestet wurde oder wenn Inhalte drin sind, die nicht zum Codex passen.
aber dann geht auch ein wenig „weihanchten“ im sinne von wordpress verloren! die sapnnung fehlt und man kann sich gar nicht mehr so recht auf neue funktionen freuen, basteln und plugins testen 😉
meine oma soll nicht bloggen können^^zumindest kein eigenes theme designen können! 😉
@Robert
Offiziell noch nicht, aber ich weiß wie mans von WordPress.org downloaden kann 😉
du hacker, rrooooaaarrr :))
@Robert
😉 Hat nicht mit Hacken zu tun, wenn du dier dieses Video von WP-D anschaust, wer weiß vielleicht merkst du es auch 😉
http://blog.wordpress-deutschland.org/2008/10/06/wordpress-27-screencast-teil-1.html
vergiss es, hast meinen Joke nicht verstanden:)
@Robert
Doch 😉 Aber wenns dich interessiert schaus trotzdem mal an 😉
WordPress 2.7 Nightly-Builds…
Jeder der will, kann auch schonmal WordPress 2.7 bei seinem PC testen, natürlich aber nicht das laufende Blog damit upgraden, da es noch nicht ganz fertig ist.
Hier könnt ihr diesen Artikel auf WordPress-DE lesen [LINK], und wer auch die Nigh…
Google in der Copyright-Falle…
Nach einer Klage eines Künstlers urteilte das Hamburger Landesgericht, daß entsprechende Bilder (es handelt sich dabei wohl um Comiczeichnungen) nicht mehr auf Google’s Bildersuche angezeigt werden dürfen. Grundlage für das Urteil ist laut de…
oops.. das war der falsche *schäm*
Ich hoffe sehr, dass das ganze dann zuverlässig funktioniert. Bei WordPress gibt es desöfteren kleinere Bugfixes, dennoch muss man – wenn man es sauber machen möchte – nahezu jede Datei updaten. Solange das ganze nicht so automatisiert wird, dass der Blogbesitzer irgendwann gar nichts mehr von einem Update mitbekommt, würde ich diese Funktion sehr begrüssen!
Hi,
bei mir habe ich nun das automatische Updaten von Plugins hinbekommen, allerdings werden die Rechte an den Ordnern und Dateien verbogen und ich kann die Verzeichnisse nicht mehr löschen oder die Dateien darin ändern 🙁
„die Rechte an den Ordnern werden verbogen“ = schon nachgeschaut, ob es sich um einen Bug handelt?
Ich habe zumindest schon gegoogelt und nichts finden können, auch auf WordPress.org finde ich nichts hierzu!