Guten Morgen, der Firefox 105.0.x scheint die Einbindung eines externen Quelltexteditors nicht mehr zu unterstützen. Es funktioniert seit Version 105.0.0 (Windows, 32 Bit) nicht mehr und in 105.0.1 ist es gleich. Einen Bugreport dazu finde ich auch nicht, also gehe ich mal davon aus, dass Firefox jetzt mit Absicht mit Edge und Chrome gleichzieht. (Siehe auch hier: Beitrag "Firefox 105.0.1: External Source Code Editor" ) Das Problem: Das zerstört bei mir einen 22 Jahre alten Workflow. Mittelfristig werde ich wohl einen anderen Workflow zum Schreiben von Webseiten entwickeln müssen. Kurzfristig suche ich aber eine Lösung, um erst einmal ein paar Seiten zu überarbeiten, und das navigieren im Dateibrowser ist echt mühsam. Kennt jemand von euch einen aktuellen Browser unter Windows 10, der einen externen Quelltext-Editor zum Anzeigen von Seiten-Quelltext öffnen kann?
Da würde ich jetzt z.B. mal bei Heise.de suchen/testen?
Heise empfiehlt Firefox - aber die Artikel sind auch schon etwas älter. Die Firefox Developer-Tools sind ganz nett als Debugger, aber lange Texte schreiben sich doch deutlich schneller in einem klassischen Text-Editor. (Der aktuell beworbene Edge-Workflow besteht wohl darin, Edge in VisualStudio einzubinden.)
:
Bearbeitet durch User
Ich suche jetzt seit gestern morgen nach einem aktuell verwendbaren HTML-Workflow und bin langsam verzweifelt. Klassisch mache ich es so, dass ich einen Haufen HTML-Dateien in einer Verzeichnissstruktur habe. Die Seite navigiere ich in einem Browser und die Seiten, die ich ändern will, öffne ich dann aus dem Browser heraus in einem Texteditor (z.B. Notepad++). Damit habe ich immer die gleiche Datei im Texteditor und im Browser verfügbar. Aus dem Texteditor heraus kann ich dann noch ein paar Skripte ausführen, die mir die Arbeit erleichtern. Der Weg, den Text-Editor aus dem Browser zu öffnen, ist jetzt verbaut. Bei Edge geht es seit Anfang an nicht, bei Chrome auch nicht und bei Firefox seit ein paar Wochen nicht mehr (siehe oben). Ich hätte nie gedacht, dass so eine Basis-Funktionalität verschwinden kann, aber es ist wohl so. Die "Developer-Tools" der Chromium-Browser scheinen nicht für diesen Anwendungsfall gedacht. Es scheint nicht möglich zu sein, die Ansicht im dem Entwicklungswerkzeugen und im Browser gleich zu halten. Man muss alles separat navigieren. Zumindest, soweit ich das jetzt die letzten zwei Stunden probiert habe. Die "Developer-Tools" von Firefox scheinen sich auch an niemanden zu richten, der Inhalt schreibt, sondern für PHP, Javascript, CSS, alles außer dem Seiteninhalt gedacht zu sein. Die klassischen Quellen (Selfhtml & Co.) propagieren immer noch "Texteditor+Browser", was ja aus den oben genannten Gründen nicht mehr (gut) funktioniert und die Suche in der Suchmaschine, wie Webseiten-Schreiben heute, September 2022, funktioniert, ist natürlich total mit Werbeagenturen verseucht. Sprich: Wer kennt eine gute Beschreibung, wie man heute, Ende September 2022 einen Neustart beim Website-Schreiben-Workflow machen kann? (Klar - der Notfall-Weg ist eine VM und ein klassischer Browser. Aber auf Dauer werfen einen solche Notlösungen nur noch weiter zurück.)
:
Bearbeitet durch User
Das funktioniert auch heute noch. https://www.thefastcode.com/de-eur/article/view-webpage-source-code-in-your-favorite-text-editor-firefox
Hast Du es mit dem aktuellen Firefox getestet? Ansonsten siehe hier: Beitrag "Firefox 105.0.1: External Source Code Editor" Wenn ja: Funktioniert es? Welche Version, welches Betriebssystem, welcher Text-Editor?
:
Bearbeitet durch User
Angehängte Dateien:
-
vscode_html.png
160 KB
Vorschlag: Nimm einen Browser, der einen Text-Editor enthält, der ein Live-Preview ermöglicht. iaw: VSCode. Plugin "HTML Preview" o.Ä. dazu. Fertig.
Immer noch Texteditor + Browser. Man editiert die Seite, danach öffnet man sie im Browser, nicht anders rum. Rohe HTML Seiten macht eh fast keiner mehr, JS hat manchmal noch ein souce map fürs debuggen, aber beim Rest hat was der Browser sieht oft nicht mehr viel mit dem zu tun, was man an Dateien bearbeitet. Ich nutze Kate und Git. Damit hab ich auch auf der Seite immer alle zum Projekt gehörenden Dateien. Ich weiss dann ja, was wo drinn ist.
DPA schrieb: > Man editiert die Seite, danach öffnet > man sie im Browser, nicht anders rum. Warum? Der Webbrowser ist doch viel besser zum navigieren von Websites geeignet als der Dateibrowser - zumindest wenn die Navigation der Website nicht vermurkst ist.
:
Bearbeitet durch User
Das Thema hat sich erledigt. Auch der aktuelle Firefox unterstützt noch einen externen Quelltext-Editor.
Das Problem ist, dass Deine 22 jährige Arbeitsweise nicht zu vermeintlich modernen Webentwicklungsmethoden 22 jähriger „Softwareengineers“ passt. Heutzutage kommen Texte aus einer Datenbank, das Design liegt in einer CSS Datei nebst einem 40 MB großen CSS Framework vor und die paar Zeilen JS die dann später zusammen mit drei,5 HTML tags im Browser gerendert werden passen auch noch in eine Datei. Das ganze wird dann eh noch in Docker Container verpackt und in der Cloud deployed. Um es kurz zu machen: Das Web besteht zu 99% aus irgendwelchen Contenmanagement Systemen und reine HTML Seiten sind ein Relikt aus 2000. Ob das wirklich besser ist? Ich denke nicht. Aber es ist einer der Gründe dafür, dass Browser alte Arbeitsmethoden nicht mehr unterstützen.
Walter T. schrieb: > Warum? Der Webbrowser ist doch viel besser zum navigieren von Websites > geeignet als der Dateibrowser - zumindest wenn die Navigation der > Website nicht vermurkst ist. Also meine Webserver sind so eingestellt das ein navigieren über die Struktur durch die Seiten eben NICHT möglich ist. In Zeiten von dynamischen Seiten mit PHP,JS,ASP,NodeJS,MySQL etc.. (und die "Zeiten" existieren schon seit 20 Jahren!) schreibt man doch kein Mensch reines HTML mehr - so das ein Webserver obsolet wird. Nimm dir einen der freien Editoren wie Atom oder Bracket - beide extrem flott - diese bieten auch eine Livevorschau über den Server hinweg sowie ein extrem gut strukturierter Verzeichnissbaum. Also auch mein Fazit: "Editor --> Browser" und nicht andersrum!
DevUps schrieb: > Um es kurz zu machen: Das Web besteht zu 99% aus irgendwelchen > Contenmanagement Systemen und reine HTML Seiten sind ein Relikt aus > 2000. Ob das wirklich besser ist? Ich denke nicht. Ich denke schon. Nicht die gesamten Frameworks, aber dynamische Seiten. Ich kann meine Seiten ohne ein MySQL und damit einhergehenden PHP backend nicht vernünftig betreiben - es sei denn ich möchte 2000+ Datensätze separat als HTML Datei schreiben. CSS Klassen legt man sich pro Projekt einmal an - und zwar in einer separaten CSS Datei - CSS Inhalte einer separaten CSS Datei landen im Cache - so das das laden solch einer Seite wesentlich schneller geht als das laden einer Seite mit innenliegendem CSS im HEAD.
Draconix schrieb: > In Zeiten von dynamischen Seiten mit PHP,JS,ASP,NodeJS,MySQL etc.. (und > die "Zeiten" existieren schon seit 20 Jahren!) schreibt man doch kein > Mensch reines HTML mehr Ich schon. Die Inhalte liegen bei mir in HTML vor, und werden per PHP in die Seite geladen. Die Inhalte/Codes bearbeite ich mit Notepad++.
Ich stehe ja auch noch auf den alten Weg und schreibe html, css und js weitestgehend per Hand, habe mittlerweile natürlich einiges an Blöcken und Funktion, die ich wiederverwenden kann. Zum Thema, VSCode + LiveServer Erweiterung macht doch genau das, was du suchst.
Kolja L. schrieb: > Zum Thema, VSCode + LiveServer Erweiterung macht doch genau das, was du > suchst. Die obengenannte Frage kam ja aus der irrigen Annahme, dass die Unterstützung externer Texteditoren in modernen Browsern ein Auslaufmodell sei. Solange es noch Mainstream-Browser gibt, die Quelltext-Ansicht in einem externen Editor erlauben, ist Browser+Editor (in meinem Fall Firefox + Notepad++) die Wunschkombination. Ein paar Skripte bauen mir die Menü-Struktur und den HTML-Header (inkl. Open-Graph-Metadaten) zusammen und das reicht mir eigentlich auch schon.
Draconix schrieb: > In Zeiten von > dynamischen Seiten mit PHP,JS,ASP,NodeJS,MySQL etc.. (und die "Zeiten" > existieren schon seit 20 Jahren!) schreibt man doch kein Mensch reines > HTML mehr - so das ein Webserver obsolet wird. Einen Vorteil von statischem HTML gibt es noch. -> weniger Sicherheitslücken. Mit den ganzen Frameworks und CMS steigt der Aufwand, weil man die sicherheitstechnisch auch noch pflegen muss. Bei statischen HTML Seiten ist es nur der Webserver und dessen Unterbau und der wird über die Repositories der Distro gut mit Sicherheitspatches versorgt. Der Aufwand geht da somit gegen 0. Natürlich haben statische HTML Seiten auch erhebliche Einschränkungen, aber wenn die Anforderungen gering sind, dann können die durchaus immer noch eine Lösung sein.
Draconix schrieb: > Ich denke schon. Nicht die gesamten Frameworks, aber dynamische Seiten. > Ich kann meine Seiten ohne ein MySQL und damit einhergehenden PHP > backend nicht vernünftig betreiben - es sei denn ich möchte 2000+ > Datensätze separat als HTML Datei schreiben. Das hängt ja auch immer vom Projekt ab, manchmal -- wie bei Dir -- braucht man eben irgendeine Art von Datenspeicher. Das muß ja nicht unbedingt eine klassische SQL-Datenbank sein, sondern kann zum Beispiel auch ein System wie Open- oder Elasticsearch sein, mit dem sich dann auch eine mächtige, hochperformante Volltextsuche integrieren läßt. Letzten Endes mache ich es aber auch bei statischen Seiten heutzutage so, daß ich sie mit einem Flask-Server entwickle, meinen HTML-Code in dessen Templates schreibe, und die einzelnen HTML-Dateien über die Vererbung von Flask (bzw. Jinja2) einbinde. Zum Deployment starte ich den Flask-Server in einem Container, lade die generierten Seiten dann mit wget(1) herunter und lege sie in einen zweiten Container, der dann mit Ansible lokal gebaut, in einen Tarball exportiert, auf den Webserver geladen, dort importiert und dann mittels docker-compose gestartet wird. Dabei meldet er sich über Umgebungsvariablen beim Reverse Proxy an, der sich vollautomatisch um die Hostnamen, um die Letsencrypt-Zertifikate, und alles Weitere kümmert. Diese Vorgehensweise hat ein paar eindeutige Vorzüge: wenn ich irgendwann etwas Dynamischeres brauche, habe ich es dank des Flask-Servers bereits fertig vorliegen. Und wenn ich einmal auf allen Seiten etwas ändern will, muß ich nur das Eltern-Template anpassen. Zudem kann ich die Container vor jedem Deployment lokal testen (lassen). Insofern kann ich mich komplett auf meine Inhalte konzentrieren, Testing und Deployment laufen automatisch. Und ich habe über die zentralen Eltern-Templates auch überall eine konsistente Navigation, für die ich nur diese eine Datei anfassen muß. Statische HTML-Seiten ohne diese Mechanismen schreiben... nee, das ist mir schon seit Jahren zu unkomfortabel, zu zeitaufwändig und, vor allem, viel zu fehleranfällig... das geht auf die Dauer nur für kleinere Aurtritte mit tendenziell eher wenigen Einzelseiten gut.
Nano schrieb: > Einen Vorteil von statischem HTML gibt es noch. -> weniger > Sicherheitslücken. ... und außerdem schnellere Ladezeiten und weniger Energieverschwendung.
Nano schrieb: > Natürlich haben statische HTML Seiten auch erhebliche Einschränkungen, > aber wenn die Anforderungen gering sind, dann können die durchaus immer > noch eine Lösung sein. Mir reichen statisches HTML und die speziell für mich erstellten Templates. Neue Seiten muss ich zwar manuell einpflegen, aber das kommt sehr selten vor. Ich komme auch ohne Cookies und Werbung aus, muss mich somit auch nicht um das ganze "Cookie Consent"-Gedöns kümmern. Da reicht statisches HTML aus, und das ist auch sicherer, da es in den Templates keine Angriffspunkte gibt. Der HTML-Zugriff auf den Webspace ist mit 2FA geschützt, und der FTP-Zugriff kann nicht so leicht geknackt werden.
René H. schrieb: > Ein T. schrieb: >> und, vor allem, viel zu fehleranfällig > > Welche Fehler kannst Du da machen? Zum Beispiel, einzelne Seiten bei Anpassungen zu vergessen.
Ein T. schrieb: > René H. schrieb: >> Ein T. schrieb: >>> und, vor allem, viel zu fehleranfällig >> >> Welche Fehler kannst Du da machen? > > Zum Beispiel, einzelne Seiten bei Anpassungen zu vergessen. Na ganz ohne Template muss man es ja nicht machen. Das Design steht ja in der index.php und in der CSS, die Inhalte lädt man per PHP. Dann muss man nur die reinen Inhalte mit den passenden Tags in die HTML schreiben und die "navigation.php" anpassen.
René H. schrieb: > geschützt, und der FTP-Zugriff kann nicht so leicht geknackt werden. SSH wäre besser. Bei mir tuts ein einfaches rsync+ssh. René H. schrieb: > a ganz ohne Template muss man es ja nicht machen. Das Design steht ja > in der index.php und in der CSS, die Inhalte lädt man per PHP. Dann muss > man nur die reinen Inhalte mit den passenden Tags in die HTML schreiben > und die "navigation.php" anpassen. Man kann auch Webseitengeneratoren benutzen. Das "Sphinx" tool welches von python.org für die Doku benutzt wird erzeugt aus ReST formatierten Testdateien (Sowas wie Markdown, Wiki formatierung, asciidoc...) eine komplete Webseite aus statischen Dateien mit etwas js Code für Suche, Bildergalerien o.ä. Kein PHP, Perl, ASP, SSI oder was auch immer notwendig. Funktioniert wie ein Compiler. Die Seite kann lokal mit einem ganz normalen Webbrowser komplett getestet werden, ein Webserver ist nicht nötig. Bei Bedarf erzeugt der Sphinx Compiler auch ein PDF, .PS etc. Anpassungen an Templates, Design sind damit kein Problem, Querverweise über die gesamte Seite natürlich auch nicht, selbst wenn man Seite in der Struktur komplett verschiebt wird das vollautomatisch berücksichtigt. Durch eigene Plugins bis zum umfallen erweiterbar. Und natürlich kann man auch .php Dateien mit erzeugen lassen, wenn mans braucht.
Andreas M. schrieb: > Man kann auch Webseitengeneratoren benutzen. Ich kenne keinen bei dem man hinterher nicht manuell nachbearbeiten muss.
Andreas M. schrieb: > Man kann auch Webseitengeneratoren benutzen. Das "Sphinx" tool welches > von python.org für die Doku benutzt wird erzeugt aus ReST formatierten > Testdateien (Sowas wie Markdown, Wiki formatierung, asciidoc...) eine > komplete Webseite aus statischen Dateien mit etwas js Code für Suche, > Bildergalerien o.ä. Ja, das stimmt, und von Armin Ronacher -- dem Autor von Flask -- gibt es mit Lektor sogar einen solchen statischen Generator. Aber einerseits hab ich meinen Workflow schon vor geraumer Zeit entwickelt und kann außerdem jederzeit auf mächtige Bibliotheken zur interaktiven Datenvisualisierung wie DataTables, Bokeh und Plotly zurückgreifen -- und, wie gesagt: wenn irgendwann eine Anforderung hinzukommt, die mehr Dynamik erfordert, habe ich die dazu nötige Infrastruktur schon fertig. Markdown, LaTeX und ein paar andere Formate gehen natürlich auch, da ist Python ja flexibel. Für mich persönlich überwiegen daher die Vorzüge meines Workflow, andere haben da bestimmt andere Anforderungen, Ideen und Vorlieben.
Es kommt auch auf den Umfang an. Meine HP ist vom Umfang her so klein, dass Wordpress & Co. m.E. überdimensioniert wären.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.