Beiträge von Tosebach

r23:
Hätte ich selbst keinen Plan von Servern, PHP und Datenbanken, wäre dein Post sicher berechtigt.
Dem, was ich bisher geschrieben habe, kannst du aber entnehmen, dass mein Wissen lediglich hinsichtlich der Mechanismen von WP Lücken aufweist. Und die versuche ich hier zu schließen.

Dass ich in einem Userforum (gerne auch Poweruser- oder Userexperten-Forum) meine Frage gestellt habe, hat den Grund, dass ich gehofft habe, dieses Verhalten sei jemandem bekannt. Das scheint nicht so zu sein, und damit ist, wie ich schon schrieb, die nächste Stufe der Fehlersuche erreicht.

Einige haben sich viel Mühe gegeben, mit ihrem Wissen zur Fehlersuche beizutragen, und ich hoffe, dass du der einzige bist, der die Ansicht vertritt, man müsse sofort erst einmal alle Eckdaten liefern, bevor Anspruch auf qualifizierte Hilbe besteht.

Meiner Erfahrung nach ist nämlich genau das oft ein Hindernis in Fachforen, da sich kaum jemand die Mühe macht, entsprechend umfangreiche Fehlerbeschreibungen zu lesen und dann gezielt zu antworten. Darüber hinaus, weiß man als Fragesteller (auch Insider) oft auch nicht, welche der Angaben, die zeitaufwändig gesammelt werden, dann tatsächlich ausschlaggebend für die zu erwartende Hilfe oder den Lösung bringenden Hinweis sind. Insbesondere, wenn der begründete Verdacht oder sogar die Gewissheit besteht, dass es mit bestimmten Betriebsparametern gar nichts zu tun hat.

Denn auf eben diesem (Web)Server laufen zwei MU-WP-Installationen und fünf WP-Einzelinstallationen teilweise seit mehreren Jahren störungsfrei. Mit identischen Einstellungen für PHP und MySQL. Einige davon sind auf dem gleichen Weg auf den Server gelangt, wie die Installation, um die es hier geht.

Da du aber gezielt nach Versionen gefragt hast:
Apache: 2
MySQL: 5.5.38
PHP: 5.5.30 mit MySQL-Client 5.0.11

Weitere Infos:
DB-Log ist leer
Rechte des DB-Users bleiben bis zum Ende oder Abbruch der Fehlersuche während meiner Aktivitäten auf dem Server bestehen

Ein guter Hinweis ist in deinem Posting dann aber doch enthalten. Ich werde mal das WP-Debugging anschmeißen.

Ich nehme an, dass die Profiuser an dieser Stelle nicht mehr weiter kommen. Das ist nur eine Feststellung und soll in keiner Weise werten.
Gibt es hier jemanden, der sich mit der Programmierung von WP auskennt und Hinweise liefern kann, an welchen Stellen des Codes oder der Datenbank ich jetzt noch suchen kann?

Natürlich gibt es immer noch die Option, die WP-Installation auf die aktuelle Version zu bringen, aber bevor ich das mache, will ich wissen, wo der Fehler liegt.
Außerdem ist natürlich auch nicht sicher, ob dann alles korrekt läuft, und falls doch, habe ich keine Chance mehr, mein Wissen durch Fehleranalyse zu erweitern ...

Mal eine kleine Zwishenbilanz:

1. Umzug der WP-Installation von Server A auf Server B durch Kopieren der Dateien und Export/Import aller Tabellen
2. Anpassen der Pfad- und Adressvorkommen in der DB (Berücksichtigung der per serialized() gespeicherten Daten)
3. DB-User hat alle Rechte
4. Dateirechte sind passend
5. Admin kommt ins Backend, kann aber nichts installieren / ändern
6. temporäre Änderung von current_user_can() in wp-includes/capabilities.php, damit Admin nicht mehr eingeschränkt ist
7. Erzeugung eines zweiten Admin-Accounts
8. Änderung in current_user_can() angepasst, damit nur für einen Admin-Account weiterhin pauschal true zurückgegeben wird (cheat)
9. Deinstallation aller unbenutzten Themes
10. Deinstallation aller Plugins

Rechte des Admin-Accounts ohne cheat weiterhin eingeschränkt

Natürlich habe ich die Plugins deinstalliert. Mit "Löschen" bezog ich mich auf die Formulierung in der Plugin-Verwaltung.

Kann ich mit einem Tool ggf. Reste von Plugins und Themes gezielt aus der DB entfernen?

Habe ich mal gemacht ... Ich habe jetzt ALLE Plugins gelöscht und damit ein blankes WP, in dem lediglich das verwendete Theme noch läuft.
An dem liegt es ja offensichtlich nicht, wie ich feststellen konnte.

Resultat: keine Änderung.

Zur Info: Ich habe jetzt erst einmal zwei Admin-Accounts. Für den einen liefert current_user_can() mir anhand der ID pauschal true zurück, damit ich agieren kann, und der andere ist zum Testen, ob sich etwas geändert hat.

Nein, ich habe sogar zwischenzeitlich alle Plugins deaktiviert, um sicher zu gehen.
Aktiv sind derzeit lediglich Count Per Day und WP-SpamShield.

Natürlich habe ich testweise auch ein Standard-Theme verwendet, um auszuschließen, dass das aktuell verwendete Theme RoundTheWorld Probleme macht.

Der Reihe nach:

SirEctor: Ja, ich habe einen neuen Admin angelegt. Indem ich kurzfristig wp-includes/capabilities.php:current_user_can() mit einem brachialen "return true;" ausgestattet habe, war das möglich. Aber auch der darf nicht mehr, als die anderen. Ich habe die Änderung in der Funktion natürlich sofort danach rückgängig gemacht...

r23: Ich weiß. PHP 5.3 habe ich auch nur verwendet, um zu sehen, ob es damit alternativ zur v5.5 läuft. Tut's nicht, also verwende ich eh wieder v5.5.
Der DB-User, den WP verwendet, hat (zurzeit) alle Rechte. Von read bis drop und create darf der alles machen. Sicher ist sicher in dieser Phase.

Trunk: Die Error-Logs für 5.3 und 5.5. sind beide leer

Ich habe mal das WP_User Object per echo ausgegeben. Vielleicht ist dort etwas zu sehen, das einem Hard-Core-Insider mehr sagt, als mir:

<!--
    WP_User Object
(
    [data] => stdClass Object
        (
            [ID] => 2
            [user_login] => XXXXXXXXXXXX
            [user_pass] => XXXXXXXXXXXXXXXXXXXX
            [user_nicename] => XXXXXXXXXXXX
            [user_email] => XXXXXXXXXXXXXXXXXXXX
            [user_url] => 
            [user_registered] => 2015-10-20 23:47:00
            [user_activation_key] => 
            [user_status] => 0
            [display_name] => XXXXXXXXXXXX
        )


    [ID] => 2
    [caps] => Array
        (
            [administrator] => 1
        )


    [cap_key] => wp_capabilities
    [roles] => Array
        (
            [0] => administrator
        )


    [allcaps] => Array
        (
            [switch_themes] => 1
            [edit_themes] => 1
            [activate_plugins] => 1
            [edit_plugins] => 1
            [edit_users] => 1
            [edit_files] => 1
            [manage_options] => 1
            [moderate_comments] => 1
            [manage_categories] => 1
            [manage_links] => 1
            [upload_files] => 1
            [import] => 1
            [unfiltered_html] => 1
            [edit_posts] => 1
            [edit_others_posts] => 1
            [edit_published_posts] => 1
            [publish_posts] => 1
            [edit_pages] => 1
            [read] => 1
            [level_10] => 1
            [level_9] => 1
            [level_8] => 1
            [level_7] => 1
            [level_6] => 1
            [level_5] => 1
            [level_4] => 1
            [level_3] => 1
            [level_2] => 1
            [level_1] => 1
            [level_0] => 1
            [administrator] => 1
        )


    [filter] => 
)


    -->

Nachtrag: Benutzerrechte der Dateien sind passend. PHP hat alle Rechte.

Hallo,

ich habe eine WP-Installation V 4.2.5 auf einen anderen Server migriert und dort ein kleines Problem, das auf dem ursprünglichen System nicht vorhanden war:

Administratoren können keine weiteren User anlegen, Seiten bearbeiten oder Plugins installieren. Sicher noch einiges mehr, aber danach habe ich dann nicht mehr weiter geforscht.
Das Problem taucht auf unter PHP 5.3 wie auch unter PHP 5.5 Weitere Versionen habe ich nicht zur Verfügung.
Die Migration habe ich vorgenommen, indem ich Dateien und DB-Inhalte komplett übernommen und die DB-Inhalte angepasst habe, wo die Pfade abweichend waren (serialized berücksichtigt).

Jetzt die große Preisfrage: Hat irgendwer eine Ahnung, woran das liegt?

Ich möchte das wissen, bevor ich die Installation auf die neueste Version bringe und das dann ggf. nicht mehr reproduzieren kann.

Das sind ein paar interessante Impulse. Danke an alle.

Ich werde mal eruieren, welches der sinnvollste Weg ist.

Monika: Nein, eine Projektplanung ist mein Job. Daher erkundige ich mich hier ja auch nach Möglichkeiten in WP, die mir noch nicht bekannt sind. Wolltest du noch mehr schreiben? Dein Posting sieht irgendwie unfertig aus.

Presskopp: Es wird bei WP bleiben. Bei Projekten wähle ich immer nur zwischen WP und Eigenprogrammierung. Das vereinfacht Wartung und Pflege bei ca. 40 Kunden.

Tubedesigner: Mehrere Installationen zu vernetzen erscheint mir kein wirklich eleganter Weg. Ich hatte vor, aus den üblichen Gründen der Pflege (Updfates, ...) auf die Multisite zu setzen.
Der Dienstleister bin übrigens ich selbst, und hinreichendes Engagement auf Seiten der Vereinsfunktionäre ist glücklicherweise vorhanden.

Hallo,

ich greife das (alte) Thema einmal auf, weil ich eine Vereinsseite plane.

Dazu habe ich mir überlegt, auf die Multisite zu setzen:

• Die Hauptsite ist der Verein selbst, auf der nur der Vorstand Inhalte ändern darf.
• Die Abteilungen sind eigenständig und über /fussball, /badminton, /tennis etc. erreichbar. Dort haben die jeweiligen Abteilungsleiter und Trainer ihre Accounts und können demnach nichts in Bereichen ändern, für die sie nicht zuständig sind.
• In allen Sites soll das selbe Theme verwendet werden.

Jetzt kommen aber die Fragen auf, zu denen mir keine Lösung einfällt:

• Header und Footer sollen grundsätzlich von der Hauptsite verwendet werden. Bei den Abteilungen soll also der jeweils eigene Header / Footer nicht greifen.
• Auf der Hauptsite werden zwar auch Beiträge geschrieben (z.B. Sommerfest, Mitgliederversammlung, ...) aber es sollen auch alle Beiträge der Abteilungen erscheinen, als seien es dort erstellte Beiträge.
• Ebenso sollen Kalender für bevorstehende Termine implementiert werden, in denen die Abteilungen ihre Daten eintragen, der Verein aber wie bei den Beiträgen alles abbildet (eigene und Abteilungstermine).

Das lässt sich sicher mit Eingriffen in die Codes lösen, aber damit wäre das ausgewählte Theme nicht mehr updatefähig.
Ein Plugin (oder mehrere) zu schreiben, um diese Anforderungen abzudecken, erscheint mir nicht sinnvoll, da der Aufwand sicher zu groß ist, sofern es keine Lösung mit Hausmitteln gibt.

Oder ...

Sollte man sowas einfach in einer simplen (nicht multi) Installation erledigen und dabei auf ein umfassenderes Rechtemanagement setzen? Ich weiß zwar, dass es verschiedene Plugins zur besseren Verteilung der Userrechte gibt, kenne aber keines wirklich und kann mir daher schlecht vorstellen, ob das eine Lösung wäre.

Würde mich freuen, wenn jemand dazu Ideen hat.

Ok, das scheint hier niemand zu wissen.

Macht aber nichts, denn ich habe das Problem umschifft und per .htaccess gelöst, da das WP-Plugin offensichtlich nicht vorsieht, das selbst lösen zu können (siehe auch https://wordpress.org/support/topic/cannot-add-domains-for-site-id1).

Und damit auch anderen geholfen werden kann: So sieht die Lösung aus:

Zitat

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

RewriteCond %{HTTP_HOST} ^example\.org$
RewriteRule ^(.*)$ http://www.example.org/$1 [L,R=301]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress

Alles anzeigen

Die beiden Zeilen in Fettschrift muss man dem WP-Regelwerk hinzufügen.
Dann wird jeder Aufruf von example.org auf http://www.example.org umgeleitet.
Durch Übergabe der Getparameter mittels $1 kallpt das dann auch mit dem direkten Aufruf von Seiten im Front- und Backend.
Alle anderen Domains bleiben von dieser Regel unberührt.

Hallo zusammen,

ich habe eine Multi-Domain Installation basierend auf dem WordPress MU Domain Mapping - Plugin.
Als Basis habe ich eine existierende Installation mit einer bereits laufenden Site genommen.
Zwar funktioniert alles völlig problemlos, aber ich suche vergebens nach einer Möglichkeit, eine alternative Domain auf die bisherige installation zu mappen.
Im Detail geht es darum, statt http://www.example.com auch example.com verwenden zu können.

Für die sekundären Installationen ist das kein Problem. Da habe ich unter "Werkzeuge" das Domain Mapping zur Verfügung. Für die primäre Installation habe ich das nicht ...

Gibt es da einen Workaround, oder einen Trick, den ich nicht kenne, oder muss ich die primäre Site nochmal als sekundäre Site einrichten und als primär irgendwas anderes nehmen?

Danke schonmal.