Ich habe meinem Waagen-Service 50 Google Landingpages gebaut für alle möglichen Kombinationen von Waagen-Fachbegriffen und Orten der Region.
Er ist mit so ziemlich allem auf Platz 1.
Und, wie ich eben festgestellt habe: innerhalb einer Stunde von 0 auf 1 - obwohl es ein wenig Konkurrenz gibt.
Was ich aber festgestellt habe: Mobi geht da langsam in die Knie. Mein HP ist recht neu und hat 1300 gekostet, also keine Krücke.
Mobi wird langsam - so ab 50 Seiten
-
Tommy Herrmann
- Site Admin
- Beiträge: 8086
- Registriert: So 6. Dez 2020, 07:37
- Wohnort: Berlin
- Kontaktdaten:
Re: Mobi wird langsam - so ab 50 Seiten
Moin,
ja - 50 Seiten ist auch schon recht viel.
Ich empfehle immer möglichst unter 35 Seiten zu bleiben. Gucke Dir mal die Größe der Projekt-Datei an, das ist bei 50 Seiten schon enorm.
ja - 50 Seiten ist auch schon recht viel.
Ich empfehle immer möglichst unter 35 Seiten zu bleiben. Gucke Dir mal die Größe der Projekt-Datei an, das ist bei 50 Seiten schon enorm.
Re: Mobi wird langsam - so ab 50 Seiten
6 MB finde ich nicht so riesig....
Gerade für Google-Optimierungen mit kreuz- und quer-Verlinkung sind mehrere Projekte nicht mehr im Rahmen eines Low-Budge-Projektes zu händeln.
Gerade für Google-Optimierungen mit kreuz- und quer-Verlinkung sind mehrere Projekte nicht mehr im Rahmen eines Low-Budge-Projektes zu händeln.
-
Tommy Herrmann
- Site Admin
- Beiträge: 8086
- Registriert: So 6. Dez 2020, 07:37
- Wohnort: Berlin
- Kontaktdaten:
Re: Mobi wird langsam - so ab 50 Seiten
Du - nein - das Problem ist natürlich nicht die Dateigröße selbst, sondern die Tatsache, dass hier eine JSON-Datei (Textdatei), die nur relativ langsam verarbeitet werden kann, von Mobirise intern bearbeitet wird, was bei dieser Größe zu erheblichen Problemen führen kann. Dabei kommt es aber immer auch darauf an, wie das Projekt aufgebaut wurde.
Kurzantwort (mit ChatGPT überarbeitet):
Ja, es kann langsamer werden – aber nicht, weil die Datei 50.000 Zeilen hat, sondern weil Mobirise bei einem großen JSON-Projekt intern sehr viel mehr Arbeit hat. Die Dateigröße (5–6 MB) ist grundsätzlich noch im Rahmen, aber je nach Umsetzung der Software kann das trotzdem spürbar ausbremsen.
Ich geh das mal Schritt für Schritt durch.
1. Zeilenanzahl ist fast egal – die Struktur ist entscheidend
Textdateien interessieren Computer nicht als „Zeilen“, sondern als Bytes.
Ob deine project.mobirise 10.000 oder 50.000 Zeilen hat, ist egal – wichtig ist:
Wie groß ist die Datei (z. B. 6 MB)?
Wie komplex ist das JSON (wie viele Objekte, Verschachtelungen, Listen)?
Für einen modernen Computer sind 5–6 MB Text an sich überhaupt kein Problem. JSON-Dateien mit 20–50 MB lassen sich technisch problemlos laden und parsen. Das Problem entsteht eher danach – sobald Mobirise aus diesen Daten seine interne Struktur und Oberfläche aufbaut.
2. Warum JSON trotzdem bremsen kann
JSON ist ein Textformat. Das heißt:
Die Datei wird als Text eingelesen.
Der Text wird vom JSON-Parser in echte Datenstrukturen verwandelt:
Arrays (Listen von Seiten, Blöcken etc.)
Objekte (Einstellungen, Eigenschaften, Texte, Styles)
Das kostet Rechenzeit, aber das ist in der Regel immer noch relativ schnell.
Die Probleme beginnen, wenn die Software nicht effizient mit der wachsenden Datenmenge umgeht:
Alles wird auf einmal geladen
Viele Programme laden das komplette Projekt in den Speicher und bauen sofort alle Objekte: jede Seite, jeder Block, jeder Text, jeder Button.
Je mehr Seiten → desto mehr Objekte → desto mehr Arbeit beim Laden und Speichern.
UI wird komplett neu gerendert
Wenn du etwas änderst (z. B. einen Text oder eine Einstellung), könnte Mobirise intern:
die Projektstruktur aktualisieren,
eventuell große Teile der Oberfläche neu zeichnen,
vielleicht sogar intern das komplette Projekt-JSON neu erzeugen.
Wenn das naiv gemacht ist, kostet jede Änderung Zeit proportional zur Projektgröße.
Keine cleveren Datenstrukturen
Wenn z. B. immer komplette Listen durchlaufen werden („Such mal den Block mit ID XY in allen Seiten“), wird jede Operation mit wachsendem Projekt spürbar langsamer. Statt:
„suche in einem kleinen Array“
wird es
„suche in einer riesigen Liste mit hunderten Seiten und tausenden Blöcken“.
3. Was an JSON speziell “teuer” ist
JSON selbst ist nicht „schlecht“, aber:
Redundanz: Viele wiederholte Strings, IDs, Attribute.
Alles als Text: Zahlen müssen konvertiert werden, Booleans auch, Strings sind oft relativ lang.
Kein Index: JSON kennt keine „Nachschlage-Struktur“, alles sind Arrays und Objekte.
Im Gegensatz dazu könnte ein internes binäres Format oder eine Datenbank:
effizienter speichern,
mit Indizes schneller suchen,
selektiv nur Teile laden.
Mobirise nutzt JSON (bzw. ein JSON-ähnliches Format) vermutlich, weil es:
portabel,
gut zu debuggen,
leicht zu sichern/kopieren ist.
Der Preis dafür: mehr Aufwand beim Laden, Speichern und Bearbeiten von sehr großen Projekten.
4. Warum der Effekt ab ~40–50 Seiten auffällt
Dass es bei dir ab 40–50 Seiten zäh wird, passt zu typischen Mustern:
Die Anzahl der Blöcke wächst stark (jede Seite hat ja mehrere Abschnitte).
Jede Aktion (z. B. Seite auswählen, Block hinzufügen, speichern) läuft dann über eine große Struktur.
Je nach interner Umsetzung kann aus „merklich“ schnell ein „nervig langsam“ werden, ohne dass die Datei selbst riesig wirkt.
5–6 MB Text sind kein Drama, aber tausende Elemente im Projektbaum können es schon sein – vor allem, wenn:
die Programmiersprache eine Garbage Collection hat, die bei vielen Objekten öfter läuft,
die UI-Bibliothek bei vielen Elementen träge wird,
alles Single-Threaded läuft (keine Auslagerung in Hintergrund-Threads).
5. Was du praktisch tun kannst
Auch wenn wir Mobirise intern nicht ändern können, kannst du dir ein bisschen helfen:
Projekt aufteilen
Statt ein Riesensystem mit 50+ Seiten:
mehrere Projekte: z. B. „Hauptseite“, „Blog/Archiv“, „Landingpages“, etc.
Gemeinsame Styles und Menüstrukturen eventuell manuell nachziehen.
Aufräumen
Nicht genutzte Seiten löschen oder in ein Archiv-Projekt auslagern.
Temporäre / Test-Seiten rauswerfen.
Backups behalten, aber schlank arbeiten
Mit einer „Arbeitskopie“ mit weniger Seiten arbeiten,
eine komplette Kopie nur als Backup halten.
Projektdatei mal ansehen
Wenn du neugierig bist:
project.mobirise in einem Editor öffnen,
prüfen, ob dort z. B. große Base64-Bilddaten drinstehen (lange Strings mit data:image/...;base64,).
Falls ja, wird die Datei unnötig aufgebläht und Mobirise muss beim Laden nicht nur Struktur, sondern auch riesige Textblöcke anfassen.
6. Fazit in einem Satz
Ja, eine project.mobirise mit vielen Seiten/Blöcken kann die Software deutlich verlangsamen – nicht wegen der Zeilenanzahl, sondern weil Mobirise bei einem großen JSON-Projekt immer mehr Daten einlesen, umwandeln, verwalten und in der Oberfläche darstellen muss.
Wenn du magst, kannst du mir grob sagen:
Dateigröße deiner größten project.mobirise
ungefähr wie viele Seiten & Blöcke du hast
Dann kann ich dir etwas konkreter einschätzen, was „normal langsam“ und was eher „da macht Mobirise etwas ungeschickt“ ist – und dir eine Strategie zum Aufteilen vorschlagen.
Kurzantwort (mit ChatGPT überarbeitet):
Ja, es kann langsamer werden – aber nicht, weil die Datei 50.000 Zeilen hat, sondern weil Mobirise bei einem großen JSON-Projekt intern sehr viel mehr Arbeit hat. Die Dateigröße (5–6 MB) ist grundsätzlich noch im Rahmen, aber je nach Umsetzung der Software kann das trotzdem spürbar ausbremsen.
Ich geh das mal Schritt für Schritt durch.
1. Zeilenanzahl ist fast egal – die Struktur ist entscheidend
Textdateien interessieren Computer nicht als „Zeilen“, sondern als Bytes.
Ob deine project.mobirise 10.000 oder 50.000 Zeilen hat, ist egal – wichtig ist:
Wie groß ist die Datei (z. B. 6 MB)?
Wie komplex ist das JSON (wie viele Objekte, Verschachtelungen, Listen)?
Für einen modernen Computer sind 5–6 MB Text an sich überhaupt kein Problem. JSON-Dateien mit 20–50 MB lassen sich technisch problemlos laden und parsen. Das Problem entsteht eher danach – sobald Mobirise aus diesen Daten seine interne Struktur und Oberfläche aufbaut.
2. Warum JSON trotzdem bremsen kann
JSON ist ein Textformat. Das heißt:
Die Datei wird als Text eingelesen.
Der Text wird vom JSON-Parser in echte Datenstrukturen verwandelt:
Arrays (Listen von Seiten, Blöcken etc.)
Objekte (Einstellungen, Eigenschaften, Texte, Styles)
Das kostet Rechenzeit, aber das ist in der Regel immer noch relativ schnell.
Die Probleme beginnen, wenn die Software nicht effizient mit der wachsenden Datenmenge umgeht:
Alles wird auf einmal geladen
Viele Programme laden das komplette Projekt in den Speicher und bauen sofort alle Objekte: jede Seite, jeder Block, jeder Text, jeder Button.
Je mehr Seiten → desto mehr Objekte → desto mehr Arbeit beim Laden und Speichern.
UI wird komplett neu gerendert
Wenn du etwas änderst (z. B. einen Text oder eine Einstellung), könnte Mobirise intern:
die Projektstruktur aktualisieren,
eventuell große Teile der Oberfläche neu zeichnen,
vielleicht sogar intern das komplette Projekt-JSON neu erzeugen.
Wenn das naiv gemacht ist, kostet jede Änderung Zeit proportional zur Projektgröße.
Keine cleveren Datenstrukturen
Wenn z. B. immer komplette Listen durchlaufen werden („Such mal den Block mit ID XY in allen Seiten“), wird jede Operation mit wachsendem Projekt spürbar langsamer. Statt:
„suche in einem kleinen Array“
wird es
„suche in einer riesigen Liste mit hunderten Seiten und tausenden Blöcken“.
3. Was an JSON speziell “teuer” ist
JSON selbst ist nicht „schlecht“, aber:
Redundanz: Viele wiederholte Strings, IDs, Attribute.
Alles als Text: Zahlen müssen konvertiert werden, Booleans auch, Strings sind oft relativ lang.
Kein Index: JSON kennt keine „Nachschlage-Struktur“, alles sind Arrays und Objekte.
Im Gegensatz dazu könnte ein internes binäres Format oder eine Datenbank:
effizienter speichern,
mit Indizes schneller suchen,
selektiv nur Teile laden.
Mobirise nutzt JSON (bzw. ein JSON-ähnliches Format) vermutlich, weil es:
portabel,
gut zu debuggen,
leicht zu sichern/kopieren ist.
Der Preis dafür: mehr Aufwand beim Laden, Speichern und Bearbeiten von sehr großen Projekten.
4. Warum der Effekt ab ~40–50 Seiten auffällt
Dass es bei dir ab 40–50 Seiten zäh wird, passt zu typischen Mustern:
Die Anzahl der Blöcke wächst stark (jede Seite hat ja mehrere Abschnitte).
Jede Aktion (z. B. Seite auswählen, Block hinzufügen, speichern) läuft dann über eine große Struktur.
Je nach interner Umsetzung kann aus „merklich“ schnell ein „nervig langsam“ werden, ohne dass die Datei selbst riesig wirkt.
5–6 MB Text sind kein Drama, aber tausende Elemente im Projektbaum können es schon sein – vor allem, wenn:
die Programmiersprache eine Garbage Collection hat, die bei vielen Objekten öfter läuft,
die UI-Bibliothek bei vielen Elementen träge wird,
alles Single-Threaded läuft (keine Auslagerung in Hintergrund-Threads).
5. Was du praktisch tun kannst
Auch wenn wir Mobirise intern nicht ändern können, kannst du dir ein bisschen helfen:
Projekt aufteilen
Statt ein Riesensystem mit 50+ Seiten:
mehrere Projekte: z. B. „Hauptseite“, „Blog/Archiv“, „Landingpages“, etc.
Gemeinsame Styles und Menüstrukturen eventuell manuell nachziehen.
Aufräumen
Nicht genutzte Seiten löschen oder in ein Archiv-Projekt auslagern.
Temporäre / Test-Seiten rauswerfen.
Backups behalten, aber schlank arbeiten
Mit einer „Arbeitskopie“ mit weniger Seiten arbeiten,
eine komplette Kopie nur als Backup halten.
Projektdatei mal ansehen
Wenn du neugierig bist:
project.mobirise in einem Editor öffnen,
prüfen, ob dort z. B. große Base64-Bilddaten drinstehen (lange Strings mit data:image/...;base64,).
Falls ja, wird die Datei unnötig aufgebläht und Mobirise muss beim Laden nicht nur Struktur, sondern auch riesige Textblöcke anfassen.
6. Fazit in einem Satz
Ja, eine project.mobirise mit vielen Seiten/Blöcken kann die Software deutlich verlangsamen – nicht wegen der Zeilenanzahl, sondern weil Mobirise bei einem großen JSON-Projekt immer mehr Daten einlesen, umwandeln, verwalten und in der Oberfläche darstellen muss.
Wenn du magst, kannst du mir grob sagen:
Dateigröße deiner größten project.mobirise
ungefähr wie viele Seiten & Blöcke du hast
Dann kann ich dir etwas konkreter einschätzen, was „normal langsam“ und was eher „da macht Mobirise etwas ungeschickt“ ist – und dir eine Strategie zum Aufteilen vorschlagen.
Re: Mobi wird langsam - so ab 50 Seiten
Hm, also früher, so in der Steinzeit der Programmierung, habe ich Text-Ini-Files immer komplett in ein Array gelesen und umformatiert, dann in diesem Inifile gearbeitet und dieses dann als Textfile wieder gespeichert, so dass man es auch als Mensch lesen konnte, aber die Verarbeitungsgeschwindigkeit sehr flott war.
Tja....ist heute scheinbar uncool. Wobei Mobi ja so ein paar Ecken hat, wo man nur den Kopf schütteln kann. Lieber noch ein sinnloses Template mehr bauen....
Tja....ist heute scheinbar uncool. Wobei Mobi ja so ein paar Ecken hat, wo man nur den Kopf schütteln kann. Lieber noch ein sinnloses Template mehr bauen....
Re: Mobi wird langsam - so ab 50 Seiten
Genau für sowas kann man mein MINI CMS nutzen 
Kann man alles auslagern - Mobirise muss nichts an Bilder und Texte speichern
Kann man alles auslagern - Mobirise muss nichts an Bilder und Texte speichern
Re: Mobi wird langsam - so ab 50 Seiten
Dann schau mal eben in die https://www.wms-hano.com rein.
Ganz unten im Fuß siehst Du Unmengen an Landingpages.
Die ganzen Seiten leben davon, dass sie den korrekten Namen haben, die entsprechende Description, alle etwas andere Texte und Alt-Tags, in der Sitemap sind und auch alle in der Searchconsole einzeln angemeldet werden können.
Es wundert mich, dass diese uralte Technik momentan wieder funktioniert.
Aber das ist mit dem CMS möglich?
Beim nächsten Google-Intensiv-Projekt würde ich das mal testen (obwohl momentan Ebbe bei meinem Webdesign ist)
Ganz unten im Fuß siehst Du Unmengen an Landingpages.
Die ganzen Seiten leben davon, dass sie den korrekten Namen haben, die entsprechende Description, alle etwas andere Texte und Alt-Tags, in der Sitemap sind und auch alle in der Searchconsole einzeln angemeldet werden können.
Es wundert mich, dass diese uralte Technik momentan wieder funktioniert.
Aber das ist mit dem CMS möglich?
Beim nächsten Google-Intensiv-Projekt würde ich das mal testen (obwohl momentan Ebbe bei meinem Webdesign ist)
-
Tommy Herrmann
- Site Admin
- Beiträge: 8086
- Registriert: So 6. Dez 2020, 07:37
- Wohnort: Berlin
- Kontaktdaten:
Re: Mobi wird langsam - so ab 50 Seiten
Moin Frank,
was meinst Du denn mit: "Aber das ist mit dem CMS möglich?"
Im CMS ist doch nichts anders als in der normalen Webseite, nur dass die Inhalte aus anderen Quellen inkludiert werden.
Gucke mal in den Quelltext meiner CMS-Seite, dich ich mit Volkers Skript erstellt habe. Das funktioniert sehr einfach und ganz prima.
https://www.mobirise-tutorials.com/Tutorials-4/CMS.html
Diese gesamte Seite ist fast ausschließlich über das CMS erstellt worden.
was meinst Du denn mit: "Aber das ist mit dem CMS möglich?"
Im CMS ist doch nichts anders als in der normalen Webseite, nur dass die Inhalte aus anderen Quellen inkludiert werden.
Gucke mal in den Quelltext meiner CMS-Seite, dich ich mit Volkers Skript erstellt habe. Das funktioniert sehr einfach und ganz prima.
https://www.mobirise-tutorials.com/Tutorials-4/CMS.html
Diese gesamte Seite ist fast ausschließlich über das CMS erstellt worden.
Re: Mobi wird langsam - so ab 50 Seiten
Die Frage ist nicht ganz unberechtigt, weil die Inhalte eben nicht im Quelltext auftauchen und somit weniger Google freundlich sind. Allerdings könnte man das auch leicht anpassen in dem man das dann so in der Art einbaut:
Also nicht per Java einbinden, sondern mit PHP, dann wird es auch im HTML gerendert.
Ursprünglich war ja auch gedacht das man das in seine HTML Seiten einbinden kann. Wer SEO braucht muss dann auf PHP die Seiten umstellen und eine PHP Datei einbinden, die die ID´s aus der DB ausgibt. Das ist wie gesagt kein Problem und kann mit dem bestehenden Mini CMS auch so gemacht werden.
Wer also HTML Code im Quelltext haben möchte, der muss wie folgt vorgehen:
Hier den Pfad anpassen !!
Dann muss diese Datei im selben Verzeichnis liegen: get_article.php
Hier natürlich auch die Pfade anpassen
Hier auf der Testseite der letzte Block mit dem Auto ist so eingebunden aus dem CMS:
https://www.niederastroth.de/test1/
Code: Alles auswählen
<div class="cms-content"><?php include('artikel.php?id=12'); ?></div>Ursprünglich war ja auch gedacht das man das in seine HTML Seiten einbinden kann. Wer SEO braucht muss dann auf PHP die Seiten umstellen und eine PHP Datei einbinden, die die ID´s aus der DB ausgibt. Das ist wie gesagt kein Problem und kann mit dem bestehenden Mini CMS auch so gemacht werden.
Wer also HTML Code im Quelltext haben möchte, der muss wie folgt vorgehen:
Code: Alles auswählen
<div class="cms-content">
<?php
$id = 12;
include($_SERVER['DOCUMENT_ROOT']."/test1/get_article.php");
?>
</div>Dann muss diese Datei im selben Verzeichnis liegen: get_article.php
Code: Alles auswählen
<?php
// Artikel-ID übernehmen
$id = isset($id) ? intval($id) : 0;
// Pfad zur DB (korrekt!)
$dbPath = $_SERVER['DOCUMENT_ROOT'] . '/test1/cms.sqlite';
// DB öffnen
$db = new PDO('sqlite:' . $dbPath);
// Inhalt aus Tabelle "contents" laden
$stmt = $db->prepare("SELECT content FROM contents WHERE id = ?");
$stmt->execute([$id]);
$row = $stmt->fetch(PDO::FETCH_ASSOC);
if (!$row) {
echo "Kein Inhalt mit ID " . $id . " gefunden.";
exit;
}
// HTML ausgeben (TinyMCE-HTML direkt)
echo $row['content'];
Hier auf der Testseite der letzte Block mit dem Auto ist so eingebunden aus dem CMS:
https://www.niederastroth.de/test1/
Re: Mobi wird langsam - so ab 50 Seiten
So, nun habe ich das ganze noch leicht modifiziert 
Man kann jetzt online ( wie in WP) alles editieren.
https://www.niederastroth.de/test1/?edit=1
Man muss eben die URL so aufrufen wie oben mit dem ?edit=1
Um Speichern zu können muss man natürlich das Login aufrufen:
https://www.niederastroth.de/test1/login.php Passwort: admin123
Dann kann man erst Änderungen speichern
Das ganze ist jetzt richtig nah an Word Press - nur besser
Man kann jetzt online ( wie in WP) alles editieren.
https://www.niederastroth.de/test1/?edit=1
Man muss eben die URL so aufrufen wie oben mit dem ?edit=1
Um Speichern zu können muss man natürlich das Login aufrufen:
https://www.niederastroth.de/test1/login.php Passwort: admin123
Dann kann man erst Änderungen speichern
Das ganze ist jetzt richtig nah an Word Press - nur besser
Re: Mobi wird langsam - so ab 50 Seiten
Moin Tommy,Mir hat das vorher besser gefallen, das ist irgendwie verwirrend den Editor auf der Seite zu haben
Gruß Tommy
das ist ja auch nur eine Art das zu machen. Man kann auch nach wie vor über das Dashboard gehen und dort die Texte eingeben. Ich wollte halt auch mal innovativ sein
Das ganze CMS mit PHP ist auch nur eine DEMO um zu zeigen das es auch so ginge/geht. Muss man auch nur benutzen wenn man HTML Code erzeugen möchte für Google. Ansonsten einfach das alte CMS mit Java weiter nutzen. Wer PHP braucht wird das irgendwann auch bei mir im Download finden
Re: Mobi wird langsam - so ab 50 Seiten
Nun ja, also an WP erinnert mich das jetzt nicht wirklich.
Upload von Bildern?
So ein paar Grund-Design-Elemente wie Tabellen oder Feature-Blöcke?
Ich habe ja mal einen Blog im Zusammenspiel mit Blogger.com gebaut. Kann eigentlich schon mehr.
Aber für einen ordentlichen Blog fehlt z.B. eine einbaubare Galerie, wie auch bei Deinem CMS.
Ist das A&O für einen Reiseblog oder einen Koch-Blog.
Upload von Bildern?
So ein paar Grund-Design-Elemente wie Tabellen oder Feature-Blöcke?
Ich habe ja mal einen Blog im Zusammenspiel mit Blogger.com gebaut. Kann eigentlich schon mehr.
Aber für einen ordentlichen Blog fehlt z.B. eine einbaubare Galerie, wie auch bei Deinem CMS.
Ist das A&O für einen Reiseblog oder einen Koch-Blog.
Re: Mobi wird langsam - so ab 50 Seiten
Naja Frank,
eigentlich kannst du das alles doch einbauen
Du kannst kompletten HTML Code einbauen oder auch Bilder hoch laden und im Dashboard auch Bilder verwalten.
Ich werde wohl ein Video dazu machen müssen
Es gibt beim PHP CMS das selbe Dashboard wie beim Mini CMS. https://www.niederastroth.de/test1/admin/dashboard.php
Allerdings kann man in der PHP Version eben auch Inline die Blöcke editieren. Das geht beim MINI CMS nicht.
Ich kann im Tiny alles an HTML Code eingeben oder Tabellen erstellen oder sonst was. Da sind ja alle Möglichkeiten gegeben- man muss sie nur sehen
Hab mal Deine Seite hier eingebaut : https://www.niederastroth.de/test1/test.php
HTML kein Problem - kann man alles einbauen
Man könnte das ganze auch noch weiter ausbauen mit PHP Modulen ( Termine, Galerien, News usw. ) und die dann mit Platzhaltern einbauen nach dem Schema:
eigentlich kannst du das alles doch einbauen
Du kannst kompletten HTML Code einbauen oder auch Bilder hoch laden und im Dashboard auch Bilder verwalten.
Ich werde wohl ein Video dazu machen müssen
Es gibt beim PHP CMS das selbe Dashboard wie beim Mini CMS. https://www.niederastroth.de/test1/admin/dashboard.php
Allerdings kann man in der PHP Version eben auch Inline die Blöcke editieren. Das geht beim MINI CMS nicht.
Ich kann im Tiny alles an HTML Code eingeben oder Tabellen erstellen oder sonst was. Da sind ja alle Möglichkeiten gegeben- man muss sie nur sehen
Hab mal Deine Seite hier eingebaut : https://www.niederastroth.de/test1/test.php
HTML kein Problem - kann man alles einbauen
Man könnte das ganze auch noch weiter ausbauen mit PHP Modulen ( Termine, Galerien, News usw. ) und die dann mit Platzhaltern einbauen nach dem Schema:
oder<h2>Aktuelles</h2>
{{module:news limit=5}}
Ob das alles Sinn macht ist natürlich die andere Frage - aber gehen würde das ganz easy{{module:gallery folder=urlaub2025}}
Re: Mobi wird langsam - so ab 50 Seiten
Login mit "admin / admin123" ?
Ich lande immer auf Deiner niederastroth-Startseite.
Ich lande immer auf Deiner niederastroth-Startseite.
Re: Mobi wird langsam - so ab 50 Seiten
Nach dem Login einfach noch mal aufrufen: https://www.niederastroth.de/test1/admin/dashboard.php
Leitet falsch gerade weiter Muss ich noch ändern...
Du kannst die Seiten auch inline bearbeiten. Einfach ?edit=1 an die URL hängen. Login wie gehabt. Zum Speichern braucht man Admin Rechte.
Leitet falsch gerade weiter
Muss ich noch ändern...Du kannst die Seiten auch inline bearbeiten. Einfach ?edit=1 an die URL hängen. Login wie gehabt. Zum Speichern braucht man Admin Rechte.
Wer ist online?
Mitglieder in diesem Forum: Amazon [Bot], Majestic-12 [Bot] und 3 Gäste