Verfasste Forenbeiträge

Ansicht von 9 Antworten - 1 bis 9 (von insgesamt 9)
  • 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.

    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

    wordptester

    (@wordptester)

    Schade – aber vielen Dank.

    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

    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.

    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

    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

    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

    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 9 Antworten - 1 bis 9 (von insgesamt 9)