Beiträge von Arno Simon

  • Statt Seite nur noch /wp-admin/install.php

    der unterschiedliche präfix ist die grundvoraussetzung um in einer db zwei wp-installationen fahren zu können. ist von daher also in ordnung.

    welche ursache es hat, das bei dir nur noch der install kommt, anstatt der seite, müßte ich bei dem erscheinungsbild auch raten....
    - mal die kennwörter geprüft, ob die in der wp-config.php mit denen der datenbank identisch sind?
    - ist als db-server localhost eingetragen?
    - wenn nicht, ist der richtige db-server eingetragen?

    sind so die fragen die ich stellen würde und teilweise oben schon gestellt habe.....

    irgendeinen grund muss es haben, das die install hochkommt.....

    aber gib du doch erstmal einen aktuellen status ab, dann kann man da weiter sehen.

    vG

    Arno

  • Neuerungsvorschlag für Wordpress

    Zitat von 2 Bit-Gehirn

    ..... wenngleich ich mir vorstellen könnte, dass es z.B. mit den plugin-eigenen Variablen umsetzbar wäre oder die Abschnitte der Plugin-Funktionen zu kennzeichnen um ein Plugin zu aktivieren und deaktiven.....

    entsprechende zeitpunkte welche die aktivierung oder den ladezeitpunkt eines plugins markieren, existeren bereits und könnten dafür genutzt werden. allerdings muss an dieser stelle ein nicht unwesentlicher aufwand über eine gekapselte wp-standardfunktionalität geschaffen und geleistet werden, die gewährleistet, das z.b. in die jscript-dateien kein schadcode eingeschleusst werden kann. wehe der entwickler der für diesen standardbereich verantwortlich ist, übersieht an einer stelle irgendetwas, dann ist in dem sinne wieder die braune masse am dampfen....

    ausserdem bedingt diese vorgehensweise, das alle plugin-entwickler sich an diese neue standardfunktionalität halten und somit gewährleistet wird, das nicht doch das eine oder andere script wieder sein "eigenes ding dreht". dies kannst du jedoch nur gewährleisten, wenn du die plugindateien bei jedem load-vorgang überprüfst und abcheckst ob dort nicht irgendwo in einem add_action-eintrag (zum header z.b.) entsprechend jscript-files hochgeschleudert werden. gleiches im body, etc. etc. etc. "bei jedem load", weil sich die dateien auf dem server ja jederzeit ändern können, ohne das es einer neuen aktivierung des plugins bedarf.

    der dadurch zu betreibende aufwand währe mE so immens, dass die prüf- und generierungsarbeiten auf dem server den zeitgewinn, den du durch den schmaleren loadchannel der eigentlichen seitendaten (inkl. js-files) erzielst, entweder vollständig oder noch stärker auffrisst.

    ganz ehrlich gesagt, würde ich die verantwortung für solche prüfroutinen im sinne des wp-standard ablehnen wollen und selbige bei dem belassen, der sie im moment inne hat - dem entwickler des plugins....

    ich weiss zwar nicht was da gerade eingebaut wird, bin ich doch keiner der core-entwickler von wp, allerdings habe ich letztens etwas gelesen, das in die pluginschnittstelle von wp ohnehin zusätzliche sicherheitsmechanismen eingebaut werden. bin mal gespannt was das ist....

    vG

    Arno

  • Statt Seite nur noch /wp-admin/install.php

    Zitat von Mopptodel

    Und dich, Meister der klaren Antworten

    na, dann kann ich mich ja nur noch in orakelhaften antworten ergehen :mrgreen:

    die db solltest du über die verwaltungsoberfläche deines webspaces erreichen. die zugangsdaten zur db müssen mit den gleichen konfigurationsdaten in der wp-config.php stehen, wie diese im webspace hinterlegt sind. ansonsten kann wp nicht auf die db zugreifen.

    wie du in die verwaltungsoberfläche deines webspace kommst, sollte dir der hoster deines vertrauens mitgeteilt haben - da kann ich nicht mit dienen..... wenn du damit auch nicht dienen kannst, wende dich vertrauensvoll an deinen hoster.... sofern der dir nicht helfen kann, bist du wohl beim falschen hoster :mrgreen:

    vG

    arno

  • Neuerungsvorschlag für Wordpress

    sorry, aber beides ist irreal und würde darauf hinauslaufen, die dateien zur laufzeit jedesmal aufs neue generieren zu lassen respektive bei aktivierung des einen plugins erweitern und bei deaktivierung des anderen plugins wieder schrumpfen zu müssen.

    beides läuft darauf hinaus, das die entsprechenden dateien so gut wie mit öffentlichen schreibrechten auf dem server liegen - im falle der css wohl noch weniger das problem (obwohl ich fürchte, dass es auch hier ggf. entsprechende ansatzpunkte für xss-fallen o.ä. geben könnte, die mir im moment nicht bekannt sind). bei den js-dateien schon wesentlich eher - was vor allem gefährlich für die anwender wäre.

    da plugins ohnehin sicherheitsrisiken darstellen - je nach entwickler und dessen erfahrungspotential können recht große sicherheitslücken geöffnet werden -, ist es m.E. unverantwortlich die dateien entsprechend offen auf dem server liegen zu lassen.

    irgendein plugin-entwickler hat dann mal wieder vergessen seine eingabevariablen entsprechend zu evaluieren und hinterlässt mit seinem script eine entsprechende sicherheitslücke, die dazu führt, das code von einer anderen seite ausgeführt und dateien auf dem server manipuliert werden - z.b. die js-dateien.

    ergebnis? eine menge unzufriedene benutzer des blogs, weil über den blog und das hinterlegte javascript plötzlich ein phisher oder ähnliches auf seinen rechner übertragen wurde....

    ganz ehrlich, glaube ich das sowohl du als auch alle anderen darauf verzichten können.

    das z.b. jquery in mehreren versionen geladen und ausgeführt wird, ist mir auch schon aufgefallen - und das es dadurch zu störungen kommen kann (vor allem auch im BE) ist mir schon mehr als einmal untergekommen. aber dann sollte man eher hingehen und versuchen entsprechende prüfroutinen zu entwickeln ob das benötigte jquery (oder anderes javascript) bereits geladen ist und dann darauf zurückzugreifen. wenn das nicht geht, muss man manuell in die scripts eingreifen....

    um sowohl die größe der html-daten als auch die menge der zu übertragenden scripts zu begrenzen gibt es mehr als genügend techniken um die daten nur dann übertragen zu lassen, wenn sie benötigt werden. die plugin-entwickler müssen sich nur daran halten und/oder entsprechende einstellungsmöglichkeiten schaffen.

    vG

    Arno

  • Wordpress zeigt eingefügtes Video nur gekürzt?!

    ich hoffe du hast dich in der mail einer etwas anderen ausdrucksweise bedient, wie hier im forum ;)

    ausserdem: hast du mal überprüft, ob die datei sauber auf videocommunity hochgeladen wurde? warst du während des uploads vor dem rechner und dieser ist nicht unerwartet abgebrochen? wird per web-formular oder per ftp hochgeladen?

  • Wordpress zeigt eingefügtes Video nur gekürzt?!

    ich weiss ja nicht, ob das was zu bedeuten hat, aber das video ist auf videocommunity nicht zur veröffentlichung freigegeben! vielleicht liegt die kürzung ja daher seitens videocommunity und du fragst besser dort mal nach? vielleicht wollen die aber auch nicht so ohne weiteres den traffic für 18 minuten video leisten und geben von daher max. 5 minuten raus.....

    vG

    arno

  • Fehler in runphp

    sorry, habe den rest des beitrags erst nachträglich gelesen - ändert aber grundsätzlich nichts an meiner obigen aussage!

    im nachhinein betrachtet, gehe ich davon aus, das du versuchst die letzten beiträge deines phpbb-boards in der sidebar als widget anzeigen zu lassen, hast jedoch nichts passendes dafür. korrekt?

    nimm aus der widget-api des codex das foo-widget und und stelle den auszuführenden code in die widget-funktion des rahmenprogramms. jetzt änderst du noch das "foo" überall in "wpphpbb" und solltest (fast) dein erstes eigenes widget geschrieben haben. dieses coding kopierst du in die code-datei deines plugins und solltest nun das neue widget (sofern fehlerfrei umgesetzt) in deine sidebar ziehen können.

    runphp sollte man nach möglichkeit vermeiden....

    vG

    Arno

  • den Adminbereich im Themen Design gestallten!?

    nun.. auch das admin-interface ist theme-basiert und es gibt mehrere alternativen zum standard, in wie weit es allerdings sinnvoll ist das backend-design dem des front-ends anzupassen, ist für mich an der stelle fraglich....

    selbst andere cms-systeme, wie zum beispiel modxcms, die eine bearbeitung der beiträge im frontend ermöglichen, haben ihr backend mit einem ganz anderen layout strukturiert. und meines erachtens sollte es auch so sein, denn front- und backend haben unterschiedliche aufgaben und dies sollte dem benutzer eben durch unterschiedliche designs auch bewußt gemacht werden.

    bei bestimmten (kritischeren) systemen mit denen ich hauptberuflich umgehe, nutze ich als externer berater meist die möglichkeit zwischen entwicklungs-, konsolidierungs- und produktivsystemen durch unterschiedliche farbgebung der userinterfaces (für mich) kenntlich zu machen. es währe fatal, wenn ich als externer berater plötzlich auf dem produktivsystem änderungen machte und dies entsprechend lahmlege.

    da sich die "benutzer" deines projekts in dem sinne aber eigentlich immer auf dem produktivsystem bewegen, sollte ihnen durch unterschiedliches design auch bewußt gemacht werden, das sie sich aktuell im backend und nicht im frontend bewegen. eben weil sie darauf achten müssen ihre änderungen bewußt so durchzuführen, das diese nicht unbedingt, je nach internen vorgaben, auf das frontend durchschlagen, sondern erst ggf. nach entsprechenden tests weitergereicht werden.

    vG

    Arno