Beiträge von helix

  • Aufruf klappt nicht bei Ablage im Unterverzeichnis

    Ich finde das mit index.php im html-Verzeichnis immer Gefummel. Und halte für sinnvoller, die Domain einfach auf den Ordner WordPress routen zu lassen. Bevor man das Domain-Routing umstellt, sollte man mit einem passenden PlugIn die Einträge in der Datenbank auf die neue Domain ändern, also die ohne /wordpress im Pfad.

    Das geht im Prinzip genau gleich wie jeder Domain-Umzug. Zu diesem Suchstichwort findest du viele viele Anleitungen.

    Gruß
    helix

  • bilder werden nicht angezeigt, obwohl sie vorhanden sind und der pfad stimmt

    Nur kurz und beschrieben – ich kann notfalls einen Screenshot nachreichen. Bei mir, aktueller Firefox auf Mac OS 10.6, werden manche Umlaute nicht richtig dargestellt, sondern erst der Vokal und dann das Trema (Pünktchen) über einer Leerstelle. Es betrifft nicht alle Umlaute in den Titeln, insofern vermute ich, dass es die Titel sind, die nicht komplett neu eingegeben wurden, sondern letztlich – mittelbar – aus dem Dateinamen mit Umlaut generiert sind.

    Gruß
    helix

  • bilder werden nicht angezeigt, obwohl sie vorhanden sind und der pfad stimmt

    Zitat von irmen

    warum werden die bilder auf dem alten server angezeigt


    vermutlich andere Einstellungen

    Zitat von irmen

    und auf dem neuen nicht


    weil du Umlaute in den Bildnamen hast …

    Zitat von irmen

    - wie gsagt ist der gleiche host ...


    Ist ja auch nicht so, dass du auf der alten Seite kein Umlaut-Problem hättest. Da ist es in den h3-Bildunterschriften.

    Zitat von irmen

    habt ihr einen tipp für mich wie ich die 60 Bilder von den umlauten befreie, ohne sieeinzeln zu bearbeiten. kann ihc das irgendwie mit dem pluugin better search and replace machen?


    Ja, könnte mit einem dieser Datenbank-PlugIns gehen. Allerdings, die Dateinamen auf FTP musst du natürlich auch anpassen.

    Gruß
    helix

  • Bilderupload Name schon vergeben

    Ja, ich vermute das auch.
    Andererseits sagt mir mein schwaches Gedächtnis, dass ich doch aber auch schon Bilder mit gleichem Bildnamen wie ein Beitrags-Slug hochgeladen habe und dass das ging … ?

    Man müsste das wirklich mal dezidiert nachvollziehen. Also in einer Testumgebung Bilder mit gleichem Dateinamen hochladen, wie es schon Beitrags-Slugs gibt …
    … gesagt, getan.

    Der Bildname bleibt. Ohne angehängte -2. Aber wenn ich das Bild auf die Attachment-Seite verlinke, hat die Attachment-Seite im Slug die angehängte -2.

    Konkret, dann ist es wohl am einfachsten zu verstehen:
    Beitrag: meine-domain.tld/allgemein/lightbox-test/
    Bildpfad: meine-domain.tld/wp-content/uploads/lightbox-test.jpg
    Attachment-Seite: meine-domain.tld/allgemein/lightbox-test/attachment/lightbox-test-2/
    Permalinkstruktur: /%category%/%postname%/

    Also liegt es vielleicht doch eher daran, dass es ein Bild mit dem Dateinamen schonmal gegeben hat.
    Bei dem Beispiel mit dem tierfreien Mandelmus – den alternativen Bildnamen, der nicht dem Beitragsnamen entspricht, hat es den schonmal gegeben?

    Ich kann mir grundsätzlich vorstellen, dass unterschiedliche WordPress-Installationen auf unterschiedlichen Servern (mit unterschiedlicher Servereinrichtung) da unterschiedliche Ergebnisse bringen.
    Ich bin neulich auf diese Zeile in der wp-config.php gestoßen:

    PHP
    define( 'IMAGE_EDIT_OVERWRITE', true );


    – Und habe sie eingefügt, weil es mir vernünftig erschien.

    Zitat von wp-codex

    Cleanup Image Edits

    By default, WordPress creates a new set of images every time you edit an image and when you restore the original, it leaves all the edits on the server. Defining IMAGE_EDIT_OVERWRITE as true changes this behaviour. Only one set of image edits are ever created and when you restore the original, the edits are removed from the server.


    Quelle: https://codex.wordpress.org/Editing_wp-config.php

    Gruß
    helix

  • Slider auf dynamischer Startseite einbauen

    Nein, das betrifft wieder eine statische Seite als Startseite. (Zumindest laut Beitragstitel)

    Hast du ein Child-Theme? (Andernfalls ist es sowieso sträflich, wenn du den Code in der header.php veränderst – beim nächsten Theme-Update wäre das weg).

    Zuständig ist ziemlich sicher die content.php
    Wenn du die anpassen willst, müsstest du mit Conditional Tags arbeiten, also einer Anweisung, dass der Slider nur eingebunden wird, wenn du auf der Startseite bist.
    Eine Alternative kann sein, dass du die content.php kopierst und als home.php abspeicherst. Und dort deinen Slider-Shortcode einfügst.
    Für eine dynamische Startseite nimmt WordPress sich das Template home.php – wenn eine solche Datei im Theme-Ordner liegt.

    Gruß
    helix

  • Kategorieseiten nicht editierbar

    Ist „File not found“ wirklich der Wortlaut der Fehlermeldung? Oder wie ist der Wortlaut.

    Was heißt „verschiedene Themes“? Hast du auch mit einem Standard-Theme Twenty-irgendwas getestet?
    Hast du mal alle PlugIns deaktiviert?

    Hast du mal die Permalinks neu abgespeichert?

    Hast du dir mal den Debug-Modus eingeschaltet, um genauere Fehlermeldungen zu erhalten?

    Gruß
    helix

  • Öffnungszeiten

    Ja, das Textwidget ist erstmal ein vernünftiger Ansatz, um die Öffnungszeiten überhaupt anzuzeigen. Damit hat er aber noch nicht die Ausgabe, ob derzeit geöffnet oder geschlossen ist.

    Möglicherweise ist „schedule“ oder „timetable“ ein weiterführender Suchbegriff.

    Gruß
    helix

  • Child Thema, Widgets übernehmen?

    Die bereits erstellten Widgets bleiben dir auf jeden Fall erhalten.

    Wenn das neue Theme die gleichen Widget-Areas vorsieht wie das ursprüngliche Theme – und das ist bei einem Child-Theme normalerweise so – bleiben dir deine Widget-Areas mitsamt Inhalt erhalten.
    Wenn du auf einmal anders angelegte / benannte Widget-Areas hast, schiebt WordPress die in einen Bereich „inaktive Widgets“ und von dort kannst du die wieder in deine neuen Widget-Bereiche einordnen (das ist dann eher bei einem tatsächlichen Theme-Wechsel).

    Gruß
    helix

  • wp-login.php als popup ?

    Okay.
    Dann machst du es wie beschrieben. Ist ja letztlich egal, ob dein bisheriger Link zur LogIn-Seite aus dem Standard-Widget oder im Button oben auf der Seite zum Trigger für dein PopUp-Fenster umgearbeitet wird.

    Du schreibst, dass du es nicht über ein PlugIn lösen willst.
    Dann muss ich doch irgendwie bei dir die Skills voraussetzen können, dass du jetzt weißt, was du zu tun hast?

    Gruß
    helix

  • wp-login.php als popup ?

    Kommt auf deine Skills an.

    Eine Lightbox / modales Fenster mit HTML / CSS zeigt einen Inhalt, der schon mit der Seite geladen wird. Normalerweise wird die wp-login.php als eigene Seite aufgerufen.

    Wo soll denn die Lightbox erscheinen? Wenn du den „Link“ klickst, z.B. in der Seitenleiste?

    => Dann schreib dein Sidebar-Template so um, dass dort nicht ein Link zur LogIn-Seite erscheint, sondern diese schon in einem HTML-Element ausgegeben wird, das du dann zum modalen Fenster stylest.
    Möglicherweise lässt es sich auch in ein Widget packen.

    Gruß
    helix