Forum>Entwickler>Frage an die HTML-Spezis

Frage an die HTML-Spezis

alephnull
alephnull23.10.1716:03
Der Titel sagt's schon: Ich bin KEIN Spezi. Nutze nur seit "1000 Jahren" die letzte Version von Adobe GoLive für einfach Sachen. Hat bislang auch primstens geklappt. Bis heute! Folgendes Phänomen:

Eine bestimmt Menüstruktur, die Safari bis vor ein paar Tagen noch klaglos wiedergegeben hat, funktioniert jetzt nicht mehr - allerdings nur offline, also wenn Safari auf die Daten der Festplatte zugreift. Lade ich alles auf den Webserver hoch und lade es von dort via Safari, funktioniert es weiterhin ohne Probleme! Hat von Euch jemand eine Idee, was hier haken könnte?
0

Kommentare

adiga23.10.1716:11
Die 23. Zeile hat einen Schreibfehler!

Im Ernst, wie soll man das wissen ohne weitere Informationen? Ein Bildchen wie es sein sollte und eines wie es offline ausschaut. Und dazu noch ein bisschen Code und schon kann man sich ein Bild machen und helfen.
+3
alephnull
alephnull23.10.1716:40
Sorry. Bild 1 zeigt wie es sein soll: Klickt man links auf ein Datum im Menü/Navi, erscheinen links die Bildergalerie. Vom Webserver aus funktioniert das auch. Bild 2 zeigt das Ergebnis, wenn ich die Seite offline vom Rechner aus lade: Die Bildergalierie wird nun in das Menü-Fenster "gezogen". Der Code der Seite ist "ellenlang". Will ich mit allen Interna auch nicht unbedingt hier auf die Seite stellen. Evtl. schicke ich ihn Dir mal als PN?


0
alephnull
alephnull23.10.1716:50
Ich sag' mal laienhaft so: Am Code ändert sich ja rein gar nix, nur einmal funktioniert er (online), und einmal nicht (offline). Ist mir ein völliges Rätsel...
0
reneS
reneS23.10.1716:59
Bist Du Dir sicher, dass GoLive beim Upload nichts ändert. Ich habe früher auch damit gearbeitet und bin mir relativ sicher, dass beim Upload so GoLive spezifische Dinge rausgefiltert werden.

Sonst poste doch einfach mal den Quellcode der vor dem Upload von GoLive erzeugt wird.
„An Apple a day keeps Windows away“
+1
alephnull
alephnull23.10.1717:16
reneS
Bist Du Dir sicher, dass GoLive beim Upload nichts ändert.

Nein, das bin ich nicht. Nur, dass bis heute eine solche Änderung entweder nicht passierte oder keine Auswirkungen hatte. Hier der Code von index-Seite, die die beiden Fenster für Navi und Bildergalerie enthält:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta name="generator" content="Adobe GoLive" />
<title>Buchwerk</title>
</head>

<frameset cols="275,*">
<frame name="beschreibung" src="navi.html" noresize="noresize" />
<frame name="galerie" src="leer.html" noresize="noresize" />
<noframes>

<body>
<p></p>
</body>

</noframes>
</frameset>

</html>
0
Grundgütiger23.10.1717:18
Ich kann mich auch daran erinnern, dass "früher" manche Webseitengestaltungsprogramme ein paar Eigenheiten hatten, um intern Pfadangaben rechnerbezogen korrekt anzuzeigen. Vergleiche doch mal den nackten Code der online- und der offline-Dateien.
0
Grundgütiger23.10.1717:22
"frameset" ist obsolet nach den HTML5-Spezifikationen. Das sollte man also nicht mehr unbedingt verwenden und es wird nicht mehr wirklich unterstützt. Stattdessen sollte man "iframe" benutzen. Sonst sagt die index-Seite nicht viel aus, da müsste man die verlinkten Frameset-Seiten sehen.
0
alephnull
alephnull23.10.1717:26
Grundgütiger
Vergleiche doch mal den nackten Code der online- und der offline-Dateien.

Hier ist der Code von der Seite, die mir Safari gibt, wenn sie aus dem Internet geladen wurde. Ist nicht völlig identisch mit dem "offline-Code", aber der Unterschied für mich Böhmische Dörfer.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta name="generator" content="Adobe GoLive" />
<title>Buchwerk</title>
</head>

<frameset cols="275,*">
<frame name="beschreibung" src="navi.html" noresize="noresize" />
<frame name="galerie" src="leer.html" noresize="noresize" />
<noframes>

<body>
<p></p>
</body>

</noframes>
</frameset>

</html>
0
alephnull
alephnull23.10.1717:29
Ämm....nee, doch identisch. Ich glaub', ich seh schon was, wo nix ist....
0
Grundgütiger23.10.1717:37
alephnull
Ämm....nee, doch identisch. Ich glaub', ich seh schon was, wo nix ist....

Und ich dachte schon, ich hätte was an den Augen und hab' mir den Code in einen Texteditor geladen, um das zu vergleichen...

Aber GoLive bzw. Frameset-Gebastel ist schon ewig her bei mir. Das hatte ich schon ganz vergessen, dass es das gibt. Sowas würde ich mit Containern lösen, aber das wäre ja jetzt keine Lösung für dich. Ich erinnere mich aber auch, dass Framesets schon immer irgendwie schlecht mit allen Browsern funktioniert haben, das war irgendwie nix richtiges. Man hat's aber dennoch gerne benutzt.

Kannst du nicht auf das Frameset verzichten und immer die Navigationsleiste in den Seiten beibehalten?
0
alephnull
alephnull23.10.1717:57
Ja, ich weiß, hätte längst eine Alternative zu Golive suchen sollen. Aber so lange es funktioniert....so ist der Mensch halt.
Grundgütiger
Kannst du nicht auf das Frameset verzichten und immer die Navigationsleiste in den Seiten beibehalten?

Sicher geht das irgendwie, übersteigt aber schon meinen Horizont. Als Menü nutze ich das Plagin "MenueMachine", das zwar genial (für mich), aber ebenso steinalt wie Golive ist:. In "MenueMachine" kann ich das Menü bauen und es erzeugt dann so eine Art Platzhalter, den ich einfach nur auf die Seite für das einen Frameset-Fensters schieben brauche. Und im zweiten Frameset-Fenster werden dann die Bildergalerien angezeigt, die man im Menü auswählen kann.

Hier noch mal die unterschiedliche Struktur:
0
Grundgütiger23.10.1718:06
Da stocher' ich etwas im Dunkeln. Die Verweise besagen, dass sich "navi.html" im gleichen Verzeichnis befinden muss wie "leer.html", etc.. Ist das der Fall, oder ist "navi.html" (und die dazugehörigen Dateien) woanders?

Ganz andere Idee: Versuch das mal mit einem anderen Browser und/oder lösche den Cache in Safari.
0
alephnull
alephnull23.10.1718:07
Was auch immer die Ursache sein mag, wirklich komisch ist, dass ich jahrelang online und offline dieselben Resultate hatte. Seit heute ist der Wurm drin.
0
Grundgütiger23.10.1718:08
(Du könntest deine Web-Site auch etwas aufräumen, indem du die verschiedenen Bereiche/Themen in entsprechende Ordner/Unterordner verschiebst. Das macht das Ganze beim Bearbeiten übersichtlicher.)
0
alephnull
alephnull23.10.1718:21
Grundgütiger
(Du könntest deine Web-Site auch etwas aufräumen, indem du die verschiedenen Bereiche/Themen in entsprechende Ordner/Unterordner verschiebst. Das macht das Ganze beim Bearbeiten übersichtlicher.)

Das habe ich eigentlich von Beginn an gemacht. Ansonsten hätte ich keinen Überblick mehr.

Könnte es ja noch verstehen, wenn die Daten via Webserver irgendwie unbrauchbar werden. Ist aber gerade umgekehrt. Nach dem Hochladen funktioniert's, vorher nicht! - Und auch das erste seit heute!!
0
Grundgütiger23.10.1718:40
Wenn das vorher immer funktioniert hatte und jetzt nicht mehr und sich an der Struktur der Dateien nichts geändert hat, dann müsste das ja am Browser liegen. Daher würde ich mal den Cache leeren und auch einen anderen Browser ausprobieren. Ist der Safari neu?
0
alephnull
alephnull23.10.1718:55
Grundgütiger
Wenn das vorher immer funktioniert hatte und jetzt nicht mehr und sich an der Struktur der Dateien nichts geändert hat, dann müsste das ja am Browser liegen. Daher würde ich mal den Cache leeren und auch einen anderen Browser ausprobieren. Ist der Safari neu?

Ja, das war auch mein erster Verdacht. Hab Safari vorgestern "ge-updatet". Als erstes versucht, via TimeMachine das alte Safari wieder drüber zu bügeln. Geht aber nicht! Da hat Apple schon vorgebaut.

Aber wenn es am neuen Safari liegen sollte, warum werden dann die fraglichen Seiten vom Webserver mit dem neuen Safari korrekt angezeigt und nur die offline-Daten nicht.

Habe es auch mit Chrome und Firefox probiert. Dasselbe Spiel: online wow, offline mau!
0
alephnull
alephnull23.10.1719:09
So, noch was probiert:
Habe die Daten (mit FTP-Client) vom Web-Server mal wieder auf den Rechner "zurückkopiert". Und wenn ich die Seiten dann vom Rechner aus im Browser lade, tritt der Fehler wieder auf. Also, etwas verkürzt:

Offline (Fehler) ---hochladen- Online (korrekte Wiedergabe) ---runterladen- Offline (Fehler)

Irgendwie Gaga, oder...?
0
Grundgütiger23.10.1719:17
alephnull
Irgendwie Gaga, oder...?

Ziemlich. Aber, wie ich schrieb: vergleiche mal alle Seiten (nicht nur index.html) miteinander.
Wenn das nicht vorher funktioniert hätte, hätte ich auf Verweisfehler getippt, weil - wie reneS schon vermutete - GoLive wahrscheinlich intern eine eigene Dateibehandlung benutzt. Das würde es machen, weil es keinen eingebauten Webbrowser als Betrachtungsmodelll benutzt, sondern irgendwas anderes. Beim Hochladen würden die GoLive-eigenen Verweise dann an die HTML-Spezifikationen angeglichen.

Es reicht aber nicht, sich nur die index.html-Seite anzuschauen, sondern man müsste sich alle Seiten anschauen und noch die Seitenstruktur.
0
alephnull
alephnull23.10.1719:25
Grundgütiger
Es reicht aber nicht, sich nur die index.html-Seite anzuschauen, sondern man müsste sich alle Seiten anschauen und noch die Seitenstruktur.

Da muss ich dann mal wie der Farbenblinde, die Farben vergleichen.
Würde aber auch noch nicht erklären, warum das bei mir auf'm Rechner seit ca. 15 Jahren funktioniert hat - und just seit heute nicht mehr.
0
Grundgütiger23.10.1720:22
alephnull
Würde aber auch noch nicht erklären, warum das bei mir auf'm Rechner seit ca. 15 Jahren funktioniert hat - und just seit heute nicht mehr.

Wie man's nimmt. Sind die Seiten unterschiedlich und bei den offline-Daten ist irgendwelcher HTML-Kram komisch, dann könnte GoLive ein Problem haben. Sind sie identisch, könnte außerdem noch Safari ein Problem haben - neben Problemen, die wo ganz anders liegen.

Du könntest mal die plist-Datei von GoLive und/oder Safari (sollte vorher geschlossen sein) auf den Desktop verschieben und schauen, wie sich das dann verhält. So ein Computer ist ja auch nur ein Mensch und hat sich womöglich irgendwo mal verschluckt und das kann dann die komischsten Auswirkungen haben.
0
michimaier23.10.1720:42
Also ich versuch mal mit den vorliegenden Informationen eine hilfreiche Antwort zu finden.
.htaccess schon gecheckt?
Gibts das bei GoLive?
0
alephnull
alephnull23.10.1720:44
@Grundgütiger: Hab' Dir schnell mal eine PN geschickt.
0
alephnull
alephnull23.10.1721:04
@michimaier: Hast auch 'ne PN.
0
michimaier23.10.1721:09
Muss dich enttäuschen - läuft lokal einwandfrei...
Habs in XAMP laufen lassen.
Der Code scheint richtig zu sein - ich tippe darauf dass du bei GoLive irgendwas zerhauen hast -
oder - vielleicht das allseits so beliebte Rechte Problem?
Bei Apache könnte ich dir jetzt weiter helfen bei GoLive...muss ich leider passen
+1
michimaier23.10.1721:38
Was sagt denn die Konsole?
0
Grundgütiger23.10.1721:52
Bei mir läuft das auch. Die Navigation läuft mit zwei Java-Scripten, da habe ich auch nix auffälliges gesehen, bin aber auch kein super Java-Scripter.
Seltsam ist tatsächlich, dass die wieder-runtergeladenen Daten auch das Fehlverhalten verursachen.

Ich schätze jetzt mal, dass Safari ein Problem hat, die Verzeichnisstruktur, wie sie die Java-Scripte abbilden, richtig zu interpretieren, sobald die Dateien offline liegen. Ist das in Safari eventuell ausgeschaltet? Das geht in den Einstellungen unter "Sicherheit".
0
alephnull
alephnull23.10.1721:58
michimaier
ich tippe darauf dass du bei GoLive irgendwas zerhauen hast

Aber die Daten, die jetzt bei dir lokal einwandfrei laufen, sind doch mit demselben Golive erstellt.

Konsole? Hab ich mich noch nie damit beschäftigt. Was kann die App machen, damit ich weiß, wo/wie die Daten haken?
0
alephnull
alephnull23.10.1722:01
Grundgütiger
Ist das in Safari eventuell ausgeschaltet? Das geht in den Einstellungen unter "Sicherheit".

Nee, war und ist dort aktiviert.
0
alephnull
alephnull23.10.1722:58
Bekomme ich wahrscheinlich nicht mehr gelöst (zumindest heute nicht mehr ).

Habe neben TM noch ein bootbares Backup. Damit laufen die (neuen) Golive-Daten auch lokal ohne Probleme. Scheint u.U. wirklich am Safari-Update zu liegen.
Chrome ist dassleb wie Safari. Aber Firefox funktioniert doch!! Somit nutze ich jetzt erstmal Firefox fürs lokale Testen der Seiten.

Was anderes:
Was wäre Euere Empfehlung für ein Alternativ-Programm zu Golive? Müßte ein WYSIWYG-Editor sein, der aber Freiheiten läßt, z.B. Web-Galerien (HTML) einzubauen, die ich mit Lightroom erzeuge.
0
Ndugu
Ndugu24.10.1702:17
Der Code da oben ist absolut gruselig. Ein Body tag mit einem leeren p-Element? GoLive ist noch älter als die Steinzeit und Du solltest es wirklich nicht mehr benutzen.

Die Möglichkeiten eines WYSIWYG-Editors sind heutzutage eher noch begrenzter als früher, Stichwort "Responsive Design". Wenn Du aber bereit bist Einschränkungen hinzunehmen, dann versuch folgende Programme:

Blocs
Blocs ist wirklich cool, aber man kann nicht sehr weit von den vorgegebenen Möglichkeiten abweichen. Kostet 79,- irgendwas.

Macaw
Macaw ist umsonst. Ich habe selbst lange damit gearbeitet und habe es geliebt, aber das Programm wird nicht weiter entwickelt (deshalb jetzt für umme). Macaw hat ein paar Bugs und Quirks, die aber erst bei komplexeren Layouts und vielen Seiten auftreten. Man muss eigentlich ein Grundverständnis von HTML und CSS haben, um damit wirklich arbeiten zu können, es geht aber auch ohne. Ich habe es jedenfalls recht weit gebracht mit Macaw ohne damals coden zu können.

Sparkle
Sparkle ist ein WYSIWYG-Editor wie Du ihn wahrscheinlich suchst und ich nehme an, dies wird Deine Wahl sein. Einige hier im Forum kennen es und finden es gut. Der Entwickler von Sparkle ist übrigens der erste, der die Möglichkeiten eines WYSIWYG-Editors, wie Du ihn wahrscheinlich suchst, sehr kritisch sieht.

Ich verfolge Sparkle schon länger und mir fielen an der Sparkle-Eigenen Website immer irgendwelche Schlampigkeiten auf, weshalb ich das Programm nie in Erwägung gezogen habe. Wer seine eigene Website schlampig erstellt, dem kaufe ich kein Programm ab, das Webseiten macht. Die Entwicklung von Sparkle machte auf mich auch immer eher einen schleppenden Eindruck.

Webflow
Webflow ist ein Software As A Service, kein Programm das Du kaufen kannst. Es ist super, aber Du hängst für immer bei denen an der Nadel.

Pinegrow
Pinegrow ist deutlich ausgefeilter als alle anderen Programme. Es hatte ein grauenvolles Interface, aber mit V3 ist alles viel besser. Das wäre meine Wahl.

Es hat WYSWYG Eigenschaften, plus Code-Editor. Die Entwickler sind wirklich gut, wenngleich sie nichts von Design verstehen und es sie wohl auch nicht interessiert. Die Pinegrow-Website macht auch irgendwie einen überforderten Eindruck, was daran liegt, dass die Entwickler auch überfordert sind, denn sie arbeiten an ihrer Software wirklich mit Leidenschaft und großem Engagement, weshalb sie wohl keine Zeit für ihre eigene Website aufbringen.
Ich würde Dir dieses Programm empfehlen.

Viel Glück!
„These things are uuugly!“
+3
michimaier24.10.1708:14
Mach doch lieber mal folgendes,
tausche doch einfach mal die relativen Pfade gegen absolute.
Ich würde die Navigations Datei sogar direkt von online verlinken.

So findet man u.U. auch lokal Fehler die live wären ( ist zwar genau das Gegenteil von deinem Problem ) sollte aber auch funktionieren...
0
Grundgütiger24.10.1708:54
Da GoLive schon seit 10 Jahren nicht mehr wirklich existiert und auch das Navigations-JavaScript ewig alt ist, kann das schon passieren, dass neuere Browser einige der Sachen nicht (mehr) richtig umsetzen.

Die Seite, so wie du sie hast, würde man heute ohne Java-Script und Framesets machen, mit Containern. Für's bloße Navigieren bräuchtest du aber in dem Frameset auch kein JavaScript, das bietet ja nur einige überflüssige Zusatzfunktionen, wie Animationen, etc. Der pure Verweis auf eine bestimmte Seite im rechten Frameset geht auch ohne.

Ich hatte in den 1990ern Webseiten für Institutionen gestaltet und da auch mal GoLive ausprobiert. Ich fand das aber umständlicher als den Text direkt in einem Texteditor zu schreiben - damals waren die HTML-Tags noch überschaubar(er). Da die meisten Programme aber kruden HTML-Code geschrieben haben, musste man hinterher sowieso immer noch mal aufräumen. Ich kann unaufgeräumten HTML-Code nicht leiden (so wie der von Ndugu bemerkte leere Absatz). Ich mach' das aber schon lange nicht mehr, bzw. nur noch meine eigene Seite und Seiten von Projekten, die ich mache und da benutze ich das Programm Espresso, das ist aber kein Wysiwyg.

Vielleicht wäre für dich auch Wordpress was. Das unterstützt inzwischen jeder Provider.

Wo ich gerade in Erinnerungen krame: Früher gab es das Projekt "Selfhtml". Da hatte jemand in den 1990ern begonnen, ein deutsches online-Handbuch für die HTML-Skriptsprache zu schreiben. Das wuchs zu einer richtig guten Sache heran. Und wie ich gerade sehe, gibt's das heute noch immer: . Da kannst du dich mal etwas in HTML-Tags und Seitenaufbau einlesen.

Viel Erfolg mit deinem Projekt!
+2
Macdoor24.10.1710:01
Darf man fragen warum du nicht auf etwas moderneres umsattelst ? Es gibt auch aktuelle "einfache" CMS Systeme mit denen du ein ähnliches / besseres Ergebnis erreichen wirst.
„Jeder hat das Recht auf seine eigene falsche Meinung“
+1
alephnull
alephnull24.10.1711:50
Danke Euch sehr für alle Hinweise, vor allem für die kommentierte Auflistung von Ndugu und die SELFHTML-Seiten von Grundgütiger! Werde mich dranmachen, alles durchzusehen und dann entscheiden.

Es ist natürlich schon richtig: Ich trage die GoLive-Leiche seit Jahren vorm Friedhof hin und her. Der Umstieg muss kommen, schon deshalb, weil ich bei jedem MacOS-Update befürchten muss, dass Golive nicht mehr unterstützt wird. Als Nicht-Spezi geht man halt oft den Weg des geringsten Widerstanden, auch wenn der in die Sackgasse führt.

Was ich brauche, ist sowas (alles nur Beispiel und nur eine Bildergalerie verknüpft):
Die Bildergalerien rechts auf der Bsp.-Seite erstelle ich mit Adobe Lightroom, und es sind wirklich SEHR viele. Das wird auch so bleiben, weil ich in LR mit den RAW-Daten der Bilder arbeite. Und die so mit LR gewonnenen HTML-Seiten muss sich dann einbinden - was eben relativ komfortabel gehen sollte!

Vor einiger Zeit hatte ich auch mal RapidWeaver probiert, die Ausgangsseite ist damit gemacht. Bin dann aber für die vielen Bildergalerien wieder auf Golive zurückgefallen.
0
Grundgütiger24.10.1712:36
Ich hab's noch nie gemacht, aber wenn du Lightroom benutzt: Dort gibt es eine Webgalerie. Hast du das mal versucht? Wenn du mal im Internet nach "Fotogalerie web" oder ähnlichen Stichworten suchst, kommen auch eine ganze Menge Templates und Hilfen für gerade solche Sachen.

Viel Erfolg!
0
GoMac24.10.1716:12
Dachte wäre der letzte Golive (GL) user . Am einfachsten Dreamweaver (DW) CS 6 besorgen, letzte mietfreie
Neues DW Projekt starten. In den Ordner die alten html, media pages etc. Dann öffnen und schon kann man weiter arbeiten, kurz auf HTML 5 umstellen, die geniale Menue Maschine läuft leider nicht. Also neue Navi erstellen.
Fertige Galerien, Navis und co gibt es bei extendstudio.com. Mit Dreamweaver bin ich allerdings nicht so richtig warm geworden. Hoffen ja immernoch auf jemand der GL weiterentwickelt (nicht Adobe!)– viele würde sofort Bares hinlegen. Wurde meines Wissens in Hamburg entwickelt und dann an Adobe verkauft. Freeway wird wohl auch wieder aufleben.
0
Meome24.10.1718:45
Ich würde mir: Webacapella Responsive: https://www.webacappella.com/en/ mal ansehen. Für Plugins: https://www.tontonduweb.com (nicht vom Französisch abhalten lassen, Google Translate hilft etwas), Einkauf über die Website eines oder mehrerer Plugins funktionierte bei mir sehr gut.
Die Grundfunktionen reichen für viele schon und es lässt sich mit dem nötigen Fachwissen (kann man auch anmieten) Anspruchvolleres realisieren. Die Mehrspachigkeit der Website ist eingebaut und auch sehr einfach zu realisieren.
Der Preis ist für eine Standalone Anwendung sehr gut.
Die Software ist eingedeutscht, logisch und verständlich. (Eine 7-seitige "Standard" Website ist ohne Templatenutzung in einer Stunde entworfen und präsentierbar)

Nachteil (nicht ganz ernst gemeint): Die Programmierer sind stolze Franzosen (mein sehr persönlicher Eindruck) und mögen kein Englisch, sodass es vorkommen kann dass man in einem Forum oder bei Tutorials französisch Kenntnisse braucht (die Tutorials für Scripte und Extensions sind mittlerweile in Englisch).
PS: Ich habe damit z. B. unsere "Familiensite erstellt, mit ca 70 Personen und pro Person bis zu 500 Fotos in hoher Qualität. Die Site ist richtig schnell, obwohl nur Standardhosting bei 1&1.
0
Ndugu
Ndugu24.10.1718:50
@alephnull
Lightroom spuckt Dir HTML Seiten aus? Warum nicht gleich eine ganze Site mit Galerie?

Eine Website mit Bildergalerie ist aber in Wahrheit nicht die Banalität, nach der es aussieht. Erst recht nicht, wenn noch ein bisschen CMS Funktionalität dazu kommen soll, wie die Möglichkeit neue Fotos einfach rein stopfen zu können, die automatisch einsortiert werden und auf der Site auftauchen. HTML und CSS können das nicht.

Du brauchst zum Einen ein Script, das verschiedene Funktionalitäten der Galerie herstellt, z.B. den Slider, die Vor-zurück Buttons (< und >), die Pagination. Dann kommen noch so Kleinigkeiten wie Kompression, Optimierung der Fotos für Web und das Laden der geeigneten Bildgröße hinzu. Willst Du dass Leute 3MB große Fotos in x-tausend Pixel X x-tausend Pixel über Mobilfunk auf ihr iPhone laden, dessen Bildschirm nur 320px - 700px breit ist? Eher nicht. Also entweder Dein HTML und CSS Code erledigt das oder Du oder ein Script. Gut wäre zum Beispiel daß Fotos, die noch nicht zu sehen sind, nicht sofort geladen werden sondern per "lazyload" etwas verzögert.
Mit dem ganzen Zeug bist Du längst auf Javascript/ JQuery Territorium.

Wenn Du dann oben genannte CMS Funktionalität willst, dann muss das über den Server laufen und dann hast Du es mit PHP zu tun und dann ist die Datenbank dran mit MySQL und eine Minute später bindest Du Dir gleich noch Wordpress ans Bein. Wordpress sieht zwar im ersten Moment nach einer guten Lösung aus, aber in Wirklichkeit ist das nur der Eingang in ein schwarzes Zeitloch.

Es gibt im Netz ein paar nette Sachen für Bildergalerien, die aber eingebaut werden müssen:

Mit Dead Simple Gallery kannst Du Fotos in einen Ordner stopfen und das PHP Script erledigt den Rest. Ganz ohne Datenbank, MySQL oder gar Wordpress.


Für den Slider brauchst Du dann zum Beispiel:
Flickety
oder
Owl Carousel


Für einfaches CMS ist auch Sitecake ziemlich genial:


Oder Du kaufst Dir Blocs, Pinegrow oder gar Sparkle.
„These things are uuugly!“
0
Ndugu
Ndugu24.10.1718:57
@GoMac
Ich hab vor einiger Zeit mit einem der beiden ursprünglichen Entwickler von GoLive gesprochen - keine Chance, dass die das wiederbeleben… .

Von Freeway würde ich die Finger lassen. Der Vogel ist tot. Habe selbst jahrelang Freeway begeistert benutzt (bis V.7), aber die Software ist veraltet und funktioniert für Responsive Design nicht wirklich.
„These things are uuugly!“
0
alephnull
alephnull24.10.1720:51
Ndugu
@alephnull
Lightroom spuckt Dir HTML Seiten aus? Warum nicht gleich eine ganze Site mit Galerie?


Doch, genau das tut Lightroom. Kein Spaß!
Die Bsp.-Galerie aus meinem Link oben habe ich mal "nackig" ins Web gestellt. Das ist (außen den Bildern) purer LR-Code: Die Größe der Bilder kann man festlegen - im Bsp. hier 1.000 Pixel (lange Kante).
Das ist vielleicht nicht der letzte Schrei, deckt aber ein paar Grundbedürfnisse fürs Zeigen im Web ab. LR spuckt mir solch eine Galerie in ein paar Sek. aus, und mehr brauche ich auch nicht für meine Zielgruppe. Das einzige, was noch an Funktionalität hinzutreten muss, ist ein(e) Navi/Menü/Linkleiste, mittels der man verschiedene Bildergalerien aufrufen kann - möglichst natürlich auf derselben Seite, an derselben Stelle.

Ich bearbeite und katalogisiere meinen gesamten Bildbestand in LR. Und die Bider liegen ausschließlich im RAW-Format vor. Für jedes andere Programm, das die Bilder zu Galerien "verwurstet", müßte ich sie dafür erstmal exportieren. Im Moment für mich ein unnötiger Schritt.
Ndugu
Du brauchst zum Einen ein Script, das verschiedene Funktionalitäten der Galerie herstellt, z.B. den Slider, die Vor-zurück Buttons (< und >), die Pagination. Dann kommen noch so Kleinigkeiten wie Kompression, Optimierung der Fotos für Web und das Laden der geeigneten Bildgröße hinzu. Willst Du dass Leute 3MB große Fotos in x-tausend Pixel X x-tausend Pixel über Mobilfunk auf ihr iPhone laden, dessen Bildschirm nur 320px - 700px breit ist? Eher nicht. Also entweder Dein HTML und CSS Code erledigt das oder Du oder ein Script. Gut wäre zum Beispiel daß Fotos, die noch nicht zu sehen sind, nicht sofort geladen werden sondern per "lazyload" etwas verzögert............

Das ist alles absolut überlegenswert - aber erst im nächsten oder übernächsten Schritt (wenn es mal dazu kommt). Derzeit schießt es aber weit über mein Ziel hinaus. Auch reichen all die Funktionalitäten bereits an sogen. Asset Management heran, und wenn man nicht ausgemachter Web-Programmierer ist und das nötige Kleingeld hat, dann legt man sich gleich so etwas wie Canto Cumulus zu:

Lange Rede, kurzer Sinn: Klar, Golive ist nur noch das sinkende Schiff, mit dem ich mich gerade so über Wasser halte. Was ich brauche, ist ein komfortables Bötchen mit 'ner Navi an Bord, kein Dampfer, der erst noch ein Kapitänspatent erfordert.
+1
Ndugu
Ndugu25.10.1704:40
Was ich brauche, ist ein komfortables Bötchen mit 'ner Navi an Bord, kein Dampfer, der erst noch ein Kapitänspatent erfordert.
Und genau das ist das Problem!
„These things are uuugly!“
0
alephnull
alephnull25.10.1708:08
Ndugu
Was ich brauche, ist ein komfortables Bötchen mit 'ner Navi an Bord, kein Dampfer, der erst noch ein Kapitänspatent erfordert.
Und genau das ist das Problem!

Ich hab‘s geahnt.😉
+2

Kommentieren

Sie müssen sich einloggen, um sich an einer Diskussion beteiligen zu können.

OK MacTechNews.de verwendet Cookies unter anderem für personalisierte Inhalte, Seitenanalyse und bei der Auslieferung von Google-Anzeigen. Dies war zwar schon immer so, auf Wunsch der EU muss nun jedoch explizit darauf hingewiesen werden. Durch Nutzung der Website erklären Sie sich damit einverstanden. Weitere Informationen