Verfasste Forenbeiträge

Ansicht von 11 Antworten – 1 bis 11 (von insgesamt 11)
  • Thread-Starter wordptester

    (@wordptester)

    Danke – so weit, so gut.
    Ich muss also den Fallback von rechts nach links
    (index.php -> singular.php -> page.php -> …) verfolgen, aber 😉

    Ich habe jetzt herausgefunden
    1) Mein Theme: Customizr nutzt als Template (Child Theme) keine page.php,
    sondern Einzelteile, konkret: /templates/parts/content/singular/page_content.php
    2) Um verschiedene page-templates im Child Theme nutzen zu können,
    dupliziere ich also diese Teildatei im child-theme-Verzeichnisbaum
    (rename die neue in: page_content-custchild.php)
    (habe dort also jetzt 2 verschieden benannte Template-Teile)
    und ändere die
    neue Datei (die erste php-Anweisung wird ergänzt um „/** … */“ wie folgt:
    [code]
    <?php
    /**
    * Template Name: custchild
    */
    /**
    * The template for displaying the single page content
    *
    * In WP loop
    */
    ?>
    [/code]

    In beide Template-Teildateien habe ich unterschiedliche <Div>-Container
    geschrieben, um daran zu erkennen, welche der beiden jeweils aufgerufen wird.

    Dann kreiere ich im Backend eine neue Testseite, die ich „custchild“ nenne und
    ordne ihr im Backend unten rechts das Template „custchild“ zu.
    Immerhin wird das neue Template im Backend zur Auswahl im Dropdown angezeigt,
    es wird also als weiteres Template erkannt.

    Trotzdem wird von der Seite im Frontend der Template-Teil „page_content.php“
    genutzt, nicht „page_content-custchild.php“.
    Alle Seiten nutzen das am <Div>-Container erkennbare Standard-Template-Teil.

    Wie finde ich heraus welcher „Pointer“ auch die besondere Seite trotz aller Ergänzungen/Änderungen anweist, das Standard-Modul „page_content.php“ zu verwenden?

    Eine singular.php existiert im Theme nicht. In den index.php-Dateien auf den verschiedenen Ebenen ist der Content immer nur: „silence is golden“.

    Für alle Tipps dankbar.

    Thread-Starter wordptester

    (@wordptester)

    Vielen Dank zunächst für die Antworten / Hilfeversuche.

    Ich habe jetzt ein paar Versuche mit Kombinationen aus Shortcodes, Image-Slider
    und Custom Sidebars gemacht – was alles nicht wirklich optisch das ergibt,
    was gewünscht ist.
    Zudem meldet Custom Sidebars nun, dass es ab WP5.7 nicht mehr unterstützt
    wird. Ich sehe die zu bauende Site schon mit allen Workarounds fertig und
    mit Einspielen von WP5.7 ff. nur noch einen einzigen Trümmerhaufen.

    Die schlechten Erfahrungen mit WPBakery (die den jetzigen kompletten
    Neu-Aufbau der fraglichen Site erzwingen) lassen mich sehr,
    sehr vorsichtig mit anderen Block-Editoren sein – auch wenn es der WP-eigene ist.

    Andererseits – wenn die Pläne der WP-Entwickler sogar dahin gehen,
    zukünftig noch weitaus mehr als nur Seiten und Beiträge mit dem
    WP-Editor (Gutenberg) bauen zu lassen, kommt man ja schlechterdings gar nicht
    mehr um ihn herum.

    Werde ich da jetzt zu meinem eigenen Besten ‚gezwungen‘ (bzw. die Eigner
    der Website) ?

    Wie steht es mit der Kompatibilität von themes mit dem WPEditor,
    für den Fall, dass später wieder ein frisches Outfit gewünscht wird?

    Beste Grüße

    Thread-Starter wordptester

    (@wordptester)

    Jaein 😉
    je länger ich drüber nachdenke, wo meine Hürde genau liegt, komme ich zu dem Punkt, dass mir unklar ist, wie auf der einen Seite WP mit seinen unterschiedlichen Seitentypen (auf Basis der WP-DB) mit einer neuen (eigenen) ‚Anwendung‘ inkl. selbst konfigurierter DB (respektive eigenen Detailtabellen) sinnvoll zusammen zu bringen ist.

    Ich werde ja z.B. die Felder eines Eingabeformulares nicht einfach in der Code-Ansicht einer normalen ‚Seite‘ mit eigenem PHP/MySQL einsetzen können.
    D.h. ich brauche eine Info, wie ich einen geeigneten Seitentyp selbst herstelle.
    Und dann wird es ja auch notwendig, einem Frontend-User die für die Bearbeitung der DB notwendigen Rechte zu geben, ohne z.B. Redakteursrechte im Backend oder weitgehende Löschrechte zu vergeben. Das ist nicht mit z.B. Plugins à la ‚Simple WP Membership‘ zu lösen. Sollte ich der Einfachheit halber einfach besser ’ne Subdomain mit statischen Seiten aufbauen, ohne WP-Integration?
    Danke für den Hinweis auf die Class WPDB, die mir, wenn’s in’s Detail geht, bestimmt weiterhilft.

    Thread-Starter wordptester

    (@wordptester)

    Oh – schnelle Tipps, danke. 🙂

    Pods macht ja schon einen elaborierten Eindruck.
    Aber ich würde es vorziehen, erstmal eine kleine DB als Übungsprojekt (die übliche Adressverwaltung oder so 😉 ) durchzuspielen. Gibt es da nicht irgendwas, Erklärbär-mäßiges zum Schritt-für-Schritt nachbauen unter WP?
    Meine letzte Web-DB habe ich vor 10 gewerkelt. Die meisten PHP- und MySQL-Funktionen, die ich kannte, dürften mittlerweile deprecated sein (ganz zu schweigen vom CSS).

    Beste Grüße

    Thread-Starter wordptester

    (@wordptester)

    Schade – aber vielen Dank.

    Thread-Starter wordptester

    (@wordptester)

    Hallo Hans-Gerd,
    zunächst ein Danke für die schnelle Antwort.
    Die von Dir beschriebene Problematik ist mir aber leider nur allzu bewusst. 🙂

    Die Idee ist eigentlich, mit Hilfe des existierenden Themes eine neue (leere)
    WP-Instanz aufzusetzen, dort zunächst die wichtigsten Inhalte neu einzugeben und
    nach Austausch der beiden Instanzen mit der Neuen weiter zu arbeiten.
    Ziel: Den meisten Aufwand einzusparen, ein Theme so anzupassen, dass es weitestgehend wie das jetzige aussieht.
    Eigentlich halte ich überhaupt recht wenig von Pagebuildern, allerdings werden einige der jetzigen Seiten ganz ohne einen Pagebuilder (Gutenberg?) nur schwer nachzubilden sein.

    Im Moment scheitert die Idee daran, dass das Theme in der neuen WP-Instanz nach dem WPBakery schreit.

    BG

    Thread-Starter wordptester

    (@wordptester)

    Wenn ich einen Link auf die Testseite einbände, wären geneigte Leser doch nur durch weitere Details von der Fragestellung abgelenkt. Es geht nicht (und ging nie) um eine evtl. unterschiedliche Farbdarstellung unterschiedlicher Browser und auch nicht unterschiedlicher Monitore.
    Bitte genau lesen.

    Nur um ein nicht unwichtiges Detail meiner Beschreibung noch einmal zu betonen: Alle Grafiken werden auf der _selben_ Seite (nicht: Site!) dargestellt. Nur wird die selbe Datei von WordPress einmal über den Beitragsbild-Modus eingeblendet, ein anderes Mal im Text über „Dateien hinzufügen“.
    Der Farb-Unterschied ist mit der Farbpipette messbar.

    Thread-Starter wordptester

    (@wordptester)

    Danke Torsten für die Links und das konstruktive Wieder-Aufgreifen meines Problems.
    Genau genommen hat Dennis natürlich Recht und das war eine Abschweifung meinerseits.

    Tatsächlich muß es möglich sein, reines HTML mit dem TinyMCE zu schreiben. Er wird ja noch in einigen anderen CMS eingesetzt und dort ist reines HTML möglich. Es ist also WordPress, das filtert, was aber in der WordPress-Philosophie konsequent ist.

    Wenn man – wie WordPress – versucht, es den Redakteuren/Usern so leicht wie möglich zu machen (z.B. durch Ausfiltern jedes falschen HTMLs), dann ist es natürlich unvermeidbar, daß _jeder_ Code bei einmaligem Ansehen durch den visuellen Editor wieder durch die Mühle gedreht wird.
    Insofern macht es nur Sinn, einen reinen HTML-Editor (wie ich es mir wünsche) anzubieten, wenn man damit gestaltete Beiträge/Posts für den visuellen sperren könnte.
    Und letztlich bin ich ja nicht gegen das Ausfiltern falschen HTMLs. Es stört mich, daß ich Tags, die WP ja im visuellen Editor einsetzt, im Texteditor nicht sehen kann (dort nur Leerzeile oder &nbsp – war das eigentlich ein Absatz oder ein
    ? Und es stört mich, daß auch korrektes HTML ausradiert wird.
    Ich werde mir auf jeden Fall Deine Links ansehen, vielen Dank.
    Beste Grüße

    Thread-Starter wordptester

    (@wordptester)

    Naja – gelöst … schaun wir mal 😉 auf jeden Fall werde ich den Thread als „gelöst“ markieren.
    Euch beiden natürlich großen Dank, daß Ihr Euch die Zeit genommen habt, Euch mit meinen Problemchen auseinander zu setzen.
    Beste Grüße

    Thread-Starter wordptester

    (@wordptester)

    Interessanter Ansatz. Sich nicht um HTML kümmern zu wollen, sei den ‚meisten Bloggern‘ gerne gegönnt. Aber ist dafür nicht der visuelle Editor gedacht?
    Wenn es schon ‚Text‘ heißt, dann doch bitte richtig und nicht diese Mischung. So manches direkte html-Editing bleibt ja durchaus von der Löschung verschont. Das ist nicht Fisch und nicht Fleisch.

    RawHTML oder PostSnippets sind ja Ansätze, um in reinem HTML arbeiten zu können. Leider wird alles von/in RawHTML Geschriebene sofort durch den Wolf des visuellen Editors gedreht, sobald man den Post (versehentlich) im Modus des visuellen Editors öffnet. Ich habe auch eine Möglichkeit gesehen, den visuellen Editor abzuschalten und nur mit „Allways Edit in HTML“ zu arbeiten. Das wiederum geht nur für alle User/Redakteure ==> schade.

    Die Umwandlung von Zeilenschlägen in Absätzen (<p>) kann man durch ein Plugin verhindern? Das wäre ja ein Ansatz, wenn auch nur ein Teil. Welches Plugin wäre das?

    Beste Grüße

    Thread-Starter wordptester

    (@wordptester)

    Du könntest (hoffentlich) Recht haben.
    Als das Ergebnis im html-Editor so gänzlich anders war als die bei schema.org beschriebene Syntax, habe ich das nicht geprüft.
    Ich bin wohl etwas schnell davon ausgegangen, daß das Plugin da eine einfach eine andere Syntax produziert.
    So wie der Text-Editor ja sowieso ’ne ziemlich eigene Sache ist.
    Mich nervt schon immer, daß der Text-Editor von WordPress kein richtiger html-Editor ist,
    – eine eigene Eingabe der Syntax entsprechend schema.org wurde nach Switch in visuell und zurück nach text von WordPress gelöscht
    – das <hr />-Tag im visuellen Editor nicht sichtbar
    – im visuellen Editor eingefügte Linebreaks oder Absatzmarken <p> sind im Text-Editor unterschiedslos, manchmal ein &nbsp
    – … und und und
    Komisch nur, daß das sonst niemanden zu stören scheint.

    Danke für die Antwort und
    beste Grüße

Ansicht von 11 Antworten – 1 bis 11 (von insgesamt 11)