Beiträge von smartware.cc

    Du solltest natürlich vorher bedenken, ob Du tatsächlich "alles" in einer Installation haben willst. Du hast ja dann alle Themes und alle Plugins, die Du irgendwo in irgendeinem der Blogs verwendest, alle in einer WP Installation. Das wird schnell unübersichtlich.

    Und wenn Du mit "Kunden" tatsächlich externe Kunden meinst, dann würde ich mir wirklich gut überlegen ob die alle in einer MultiSite Installation liegen sollten. Es würden dann ja alle Daten aller Kunden in einer Datenbank liegen. In der Regel kann Kunde x zwar nicht auf die Daten von Kunde y zugreifen - aber es wäre auf jeden Fall eine ziemliche Sicherheitslücke. Und was ist wenn Kunde x irgend etwas herumtürkt und dann die Seite von Kunde y nicht mehr geht? Ich würds nicht machen.

    Was spricht dagegen, WordPress gleich je Kunde zu installieren und für jeden Kunden in einer sauberen Installation zu beginnen?

    Und bist Du fit in SQL? Das Ändern der Domain in der Datenbank ist insofern eine heikle Sache, dass bei einem Fehler wahrscheinlich überhaupt nichts mehr geht. Ohne fundierte SQL Kenntnisse solltest Du davon auf jeden Fall die Finger lassen.

    Peter

    Hallo Jim,

    ich bin nicht wirklich der Regex-Profi, aber ich denke mit folgender Regel in der .htaccess sollte es gehen (nicht getestet):

    Apache Configuration
    RewriteRule ^([0-9]{4})/([0-9]{2})/(.*)$ /design-anmerkungen/$1/$2/$3 [R=301,L]

    Diese Regel sollte nur dann zutreffen, wenn die URL dem Muster mit Jahr und Monat entspricht.

    Peter

    OK, d.h. es sollte folgendes erreicht werden:

    Alle Links mit .../JAHR/MONAT/xxx ändern auf .../design-anmerkungen/JAHR/MONAT/xxx

    Bei allen anderen Links hinten .html anhängen.

    Korrekt so?

    Bekommst Du das hin oder brauchst Du da Hilfe?

    Nebenbei bemerkt solltest Du Dir überlegen, auch bei den Blog-Beiträgen hinten .html an die Permalinks anzuhängen, damit das identisch ist. Ist so nicht ganz durchgängig.

    Peter

    Man sollte doch erst mal schauen, warum SSL aktiviert ist und nicht durch eine mod_rewrite Regel das Problem "lösen".

    Da hast Du natürlich recht, aber wenn ich die Frage richtig lese, dann ist das kein Problem sondern durchaus so gewollt.

    Ich verstehe die Frage so (ein Link wäre schön, dann müssten wir alle nicht raten) dass SSL sehr wohl nötig ist, vielleicht für einen Shop oder warum auch immer. Es sollen ausschließlich die Blog-Beiträge nicht per SSL erreichbar sein - was gar keine schlechte Idee ist.

    Der Blog (läuft in einem Unterverzeichnis "blog") soll aber eigentlich kein HTTPS verwenden.

    Peter

    Um zu Deiner ursprünglichen Frage zurückzukommen - und ja, es ist mit rewrite lösbar.

    Folgende Regel sollte das gewünschte Ergebnis bringen und alle URLs Deines Blogs von https auf http umleiten (nicht getestet):

    Apache Configuration
    RewriteCond %{HTTPS} on
    RewriteRule ^blog(.*)$ http://www.examlpe.com/blog$1 [R=301,L]

    Einfach unmittelbar nach "RewriteEngine On" als erste Regel rein.

    Peter

    Normalerweise würde man so etwas in der .htaccess machen. Aber ich stelle mir das schwierig vor. Ich nehme an, dass "verzeichnis" nicht immer identisch ist sondern dass es sich wahrscheinlich um eine Kategorie handelt. Woher willst Du automatisiert in einer Regel wissen, was "verzeichnis" im jeweiligen Fall ist?

    Ist nur so eine Vermutung. Poste doch den Link zu Deiner Seite. Dann kann man sich eher ein Bild machen und Du bekommst leichter und schneller eine Antwort...

    Peter

    Zu Deiner Frage nach den Alternativen:

    Du brauchts die fertigen Seiten eigentlich gar nicht umziehen sondern kannst diese in Deiner MultiSite Installation belassen - falls das für Dich eine denkbare Option ist.

    MultiSite kommt auch mit mehreren Domains zurecht. Dazu gibt es Plugins aber es geht auch komplett ohne. Ich hab das schon öfter gemacht. Und zwar aus dem gleichen Grund den Du beschreibst. Zuerst in Unterverzeichnis testen und dann live gehen. Ist ganz problemlos und in ein paar Minuten gemacht wenn Du mit MySQL zurechtkommst.

    Man muss sich dazu halt nur schon vor dem Start überlegen, ob es Sinn macht, die fertigen Seiten in einer MultiSite Intsallation beisammen zu haben.

    Falls Interesse besteht kann ich gerne kurz beschreiben wie das geht...

    Peter

    Hallo radislav,

    Melewo hat völlig recht, dass das ohne entsprechende PHP Kenntnisse schwierig ist.

    Unabhängig davon möchte ich eine Frage aufwerden, die mir selbst erst jetzt gekommen ist: Ist es überhaupt sinnvoll den Titel einer Seite dynamisch zu gestalten? Sollte nicht der Titel immer gleich sein und die Information, die Du in den Titel packen möchtest eigentlich eher eine Zusatzinfo sein?

    Ich denke, dass der Titel eine Seite identifiziert und sich nicht ändern sollte. Möglicherweise ist auch das der Grund, warum WordPress Shortcodes im Titel nicht interpretiert.

    Denk mal darüber nach. Vielleicht kommst Du zu dem Schluss, dass es ohnehin mehr Sinn macht, die dynamische Zusatzinfo an den Anfang des Inhalts zu stellen. Da hast Du ja dann mit Shortcodes alle Möglichkeiten. Du könntets das auf den gewünschten Seiten einfach immer in der selben Form an den Anfang stellen und als Überschrift formatieren. Wäre dann quasi ein Untertitel.

    Peter

    Ich nutze CleverReach, kenne das Plugin aber nicht, da ich den Code immer manuell ganz ohne Style verwende, damit ich die von CleverReach generierten Elemente in meiner eignenen CSS komplett selbst zum Design der Seite passend formatieren kann. Nur dann sieht es wirklich "schick" aus.

    Das individuelle Formatieren wird mit dem Widget mit Sicherheit nicht möglich sein. Wenn Du Dir das komplett von CleverReach so generieren lässt, dann hat das sicherlich auch genau das von CleverReach vorgegeben Design. Mag sein, dass das halbwegs passt - oder eben auch nicht.

    Den Code kannst Du dir genauso gut inkl. Formatierung von CleverReach ausgeben lassen und dann einfach kopieren und 1:1 in ein Text-Widget einfügen. Das benötigt zwei Klicks mehr und ist damit nicht wirklich viel aufwändiger.

    Mehr Aufwand ist es nur dann, wenn Du das CSS dazu selbst machst. Dann passt aber das Ergebnis auch optisch perfekt zum Rest Deiner Seite. Und das geht mit dem Widget nicht. Der Aufwand hängt also davon ab, ob Du mit dem vorgegebenen CleverReach-Design zufrieden bist oder nicht.

    Peter

    Also eigentlich keine Sortierung sondern ein Auswahl und es sollen dann nur die Beiträge angezeigt werden, die der Auswahl entsprechen?

    Hab ich das richtig verstanden?

    Dann würd ich die Orte einfach als Kategorien anlegen und die Beiträge diesen zuordnen. Du brauchst dann nur eine Liste der Kategorien - das kann auch ein Dropdown sein. Der Rest ist dann nur noch ein Auflisten der Artikel für die gewähle Kategorie.

    Peter

    An die von Melewo genannte Anzahl Connections habe ich auch schon gedacht und dabei bin ich auf eine andere Idee gekommen.

    Was haltet Ihr von der Idee eines Plugins das alle mit wp_enqueue_script und wp_enqueue_style registrierten js und css Dateien jeweils zu einer zusammenfasst und so die Anzahl der nötigen Verbindungen reduziert? So ein Plugin könnte auch gleich sämtliche Kommentare sowie unnötige Whitespaces entfernen und müsste auch @import auflösen. Das Ergebnis kann als File gecached werden.

    Das Parsen der Dateien stelle ich mir nicht ganz so trivial vor - es sollte ja danach auch noch alles funktionieren - aber im Prinzip dürfte das gar kein so großer Act sein.

    Bitte um Euer Feedback. Ich denke, das wäre ein sehr sinnvolles Plugin und würde ich würde es gerne angehen.

    Peter

    Wie schon erwähnt finde ich die grundsätzliche Fragestellung durchaus interessant und eine Diskussion wert aber ich kann nicht anders und muss folgendes dazu loswerden:

    Ladezeiten spielen heute nicht mehr wirklich die große Rolle - selbst bei Mobilgeräten nicht. Wenn eine Seite lange lädt dann sind meist andere Dinge daran schuld als ein paar kleine css oder js Dateien - wie beispielsweise riesige Bilder die dann im Browser skaliert werden.

    Wenn eine Seite extrem langsam ist, dann ist irgend etwas grundsätzlich schiefgegangen.

    Klar kann man immer optimieren und das Vermeiden von unnötigem Traffic will ich auch gar nicht abwerten sondern sehe es durchaus als sinnvoll an. Aber ob es wirklich nötig ist, mit großem Aufwand ein paar Byte einzusparen, bezweifle ich. Oft kann an anderer Stelle wesentlich mehr mit wesentlich weniger Aufwand eingespart werden.

    Bei den Plugins heißt das eben, nicht unnötig viele Plugins einzusetzen und bei Projekten, die im Laufe der Zeit gewachsen sind, einfach wieder einmal zu hinterfragen ob alle 237 aktiven Plugins wirklich noch nötig sind.

    Was die Auswahl der Plugins betrifft so bevorzuge ich persönlich schlanke Plugins die genau eine Sache effizient machen anstatt Schwergewichte mit einer Fülle von Funktionen, von denen ich nur 5% benötige.

    Peter