Pro JCE: Ich kann unzählige Bilder auf einmal in den Beitrag einfügen. Meines Wissens kann das der TinyMCE nicht, zumindest zu der Zeit, als ich deswegen auf die Pro Variante vom JCE umgestiegen bin.
Ich kann mehrere Fotos per Drag & Drop in das Beitragsfenster ziehen. Aber bei dieser Methode landen alle Bilder unstrukturiert in images-Ordner. Das will ich nicht. Ich lege themenbezogene Ordner an, aus denen ich dann über den Bildermanager von JCE die jeweiligen Fotos in den Beitrag einpflege.
Ich kopiere mal die die relevanten Zeilen hier rein.
Edit: Ich wollte Euch die Lösung nicht vorenthalten. Ich arbeite ungern bei diesen Temperaturen am Rechner und ganz profan: Ich musste erst erst Kdiff zum Vergleich der beiden Dateien installieren. Brauchte ich bis jetzt nicht.
Von Netcup erzeugte htaccess
RewriteEngine On
## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site then comment out the operations listed
# below by adding a # to the beginning of the line.
# This attempts to block the most common type of exploit `attempts` on Joomla!
#
# Block any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root home page
RewriteRule .* index.php [F]bisherige htaccess
RewriteEngine On
RewriteCond %{THE_REQUEST} ^.*/index\.php
RewriteRule ^(.*)index.php$ /$1 [R=301,L]Hallo an alle Entwarung,
ich habe die Lösung gefunden ohne aufwändige Analyse: Ich habe einfach unter einer Subdomain ein frisches Joomla direkt über Netcup installiert und die frisch genierte htaccess in die betroffene Joomla-Installation kopiert und siehe da, es läuft.
Danke alle alle für die Hilfe.
Gruß Lars
Danke Elwood. Die Badischen Temperaturen sind zum ....
Habe ich gemacht. Ergebnis: Alle URL werden mit index.php ergänzt, also http://www.example.de/index.php/Unterseite. Damit ist aber die Suchmaschinenindexierung hin, die ja ohne index.php auf die Seiten verweist.
Hallo CurlY BracketS
ich habe Neuigkeiten. Ich habe die htaccess probeweise deaktiviert und komme wieder ins Backend. Aber dafür kommt beim Aufrufen einer Unterseite Error 404. Schalte ich die htaccess wieder ein, funktioniert die Webseite wieder, aber nicht das Backend.
Ich habe unten den Code meiner htaccess eingestellt. Vielleicht erkennt jemand von den Code-Expertinnen und -Experten den Fehler.
Auf der Seite zu Joomla und Nginx https://docs.joomla.org/Nginx/de steht zwar, wie ich das einrichten soll, aber im Plesk ist dafür nicht vorgesehen. Zumal auch Netcup bei automatischen Joomla Installationen eine htaccess erstellt. Im Plesk ist der u.a Screenshot aktiviert. Nach meiner Logik gilt dann das, was für Apache gilt.
##
# @package Joomla
# @copyright (C) 2005 Open Source Matters, Inc. <https://www.joomla.org>
# @license GNU General Public License version 2 or later; see LICENSE.txt
##
##
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
#
# The line 'Options +FollowSymLinks' may cause problems with some server configurations.
# It is required for the use of Apache mod_rewrite, but it may have already been set by
# your server administrator in a way that disallows changing it in this .htaccess file.
# If using it causes your site to produce an error, comment it out (add # to the
# beginning of the line), reload your site in your browser and test your sef urls. If
# they work, then it has been set by your server administrator and you do not need to
# set it here.
##
## MISSING CSS OR JAVASCRIPT ERRORS
#
# If your site looks strange after enabling this file, then your server is probably already
# gzipping css and js files and you should comment out the GZIP section of this file.
##
## OPENLITESPEED
#
# If you are using an OpenLiteSpeed web server then any changes made to this file will
# not take effect until you have restarted the web server.
##
## Can be commented out if causes errors, see notes above.
# Options +FollowSymlinks
Options -Indexes
## No directory listings
<IfModule mod_autoindex.c>
IndexIgnore *
</IfModule>
## Suppress mime type detection in browsers for unknown types
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>
## Protect against certain cross-origin requests. More information can be found here:
## https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)
## https://web.dev/why-coop-coep/
#<IfModule mod_headers.c>
# Header always set Cross-Origin-Resource-Policy "same-origin"
# Header always set Cross-Origin-Embedder-Policy "require-corp"
#</IfModule>
## Disable inline JavaScript when directly opening SVG files or embedding them with the object-tag
<FilesMatch "\.svg$">
<IfModule mod_headers.c>
Header always set Content-Security-Policy "script-src 'none'"
</IfModule>
</FilesMatch>
## These directives are only enabled if the Apache mod_rewrite module is enabled
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{THE_REQUEST} ^.*/index\.php
RewriteRule ^(.*)index.php$ /$1 [R=301,L]
#
## End - Rewrite rules to block out some common exploits.
## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects
##
# Uncomment the following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##
# RewriteBase /
## Begin - Joomla! core SEF Section.
#
# PHP FastCGI fix for HTTP Authorization, required for the API application
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
# -- SEF URLs for the API application
# If the requested path starts with /api, the file is not /api/index.php
# and the request has not already been internally rewritten to the
# api/index.php script
RewriteCond %{REQUEST_URI} ^/api/
RewriteCond %{REQUEST_URI} !^/api/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the /api/index.php script
RewriteRule .* api/index.php [L]
# -- SEF URLs for the public frontend application
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.
</IfModule>
## These directives are only enabled if the Apache mod_rewrite module is disabled
<IfModule !mod_rewrite.c>
<IfModule mod_alias.c>
# When Apache mod_rewrite is not available, we instruct a temporary redirect
# of the start page to the front controller explicitly so that the website
# and the generated links can still be used.
RedirectMatch 302 ^/$ /index.php/
# RedirectTemp cannot be used instead
</IfModule>
</IfModule>
## GZIP & BROTLI
## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
## directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this file, and you see
## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
## then your server is already gzipping css and js files and you don't need this
## block enabled in your .htaccess
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]
# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]
# Serve correct content types, and prevent mod_deflate double compression.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1,E=no-brotli:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1,E=no-brotli:1]
<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header set Content-Encoding gzip
# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>Ja ist es. Aber, ich möchte es noch einmal betonen: Ich habe ganz simpel eine saubere Kopie der Website eingespielt, die vorher auf dem selben Server "normal" lief. Hätte ich damals das Problem gehabt, dann hätte ich auch kein Backup erstellen können, denn dazu muss ich ins Backend.
Mittlerweile wurde ich vom Support abgewatscht. Mein Anliegen sei kein Sicherheitsproblem, ich muss mich selbst und die Lösung kümmern. Mache ich. Andere Mütter haben auch schöne Töchter...
Hallo miteinander,
bis heute hat sich mein Hoster nicht gemeldet. Kein Problem, die Domain mitsamt der Website zieht um, der Vertrag mit Netcup wird gekündigt. Daher markiere ich den Thread als erledigt
Nun ja, Der IONOS Server musste aber erst das Haus betreten, die Verzeichnisstrukur hinuntersteigen und erkannte dann, das im Keller Licht brennt. 😉
Nichts für ungut, typisch deutsch. Das sind genau die Typen, die neben einen Kindergarten ziehen und verlangen, dass er dicht macht, weil sie ihre Ruhe haben wollen. Und jetzt mal meinen Senf zu den Mails von kitepascal : Ich betreibe fünf Webseiten mit Joomla und bei einer Seite bekam ich die Mail von ihm, die vor der unsicheren JCE-Komponente warnte. Da war ich aber schon im Absichern. Bei einer Seite ist es mir durch eigene Schusslichkeit misslungen, sie wurde gehackt aber noch um 23:30 Uhr durch ein sauberes Backup ersetzt. Die XML-Files sind öffentlich einsehbar, also was soll dieses Gehabe? Dass ich bei fünf Seiten nur bei einer Seite eine Mail von kitepascal erhielt, beweist doch, dass er nicht alle ereichbaren Seiten gescannt hat. In seiner Mail steht auch nichts davon, dass ich irgendwelche kostenpflichtigen Dienste von ihm in Anspruch nehmen muss, sondern wie man sich beim Hack behilft. Das sehe ich als Nachricht und nicht als Werbung an.
Hi Pascal,
danke für den schnellen Tipp. Da mein Beitrag zu #128 in der Mod-Schleife hing, hat sich Deine Antwort mit meiner Lösung überschnitten. Ich habe global die components/com_eventgallery freigegeben. Aber wenn die Einzeldateifreigabe ausreicht, gebe ich das feingranualar frei. Und zukünftig schaue ich die Console. Ich habe damit bisher nicht arbeiten müssen.
Gruß Lars
Hi Pascal,
#126 hat sich erledigt. Ich musste bei Ordner komplett freigeben folgendes eintragen: components/com_eventgallery
Jetzt läuft es wieder.
Gruß Lars
Hi Pascal,
leider muss ich mein Lob etwas einschränken: Ich benutze die Eventgallery. Seit Aktivierung von HTProtect funktioniert die Eventgallery nicht mehr. Ich habe in den erweiterten Einstellungen die unten aufgeführten Freigaben vorgenommen. Es klappt nicht. Wo muss ich schrauben? Danke
Gruß Lars
Ein Login-Loop wird typischerweise dann ausgelöst, wenn in der configuration.php bei $cookie_domain etwas eingetragen ist.
Dann einfach leer lassen und auch bei $live_site einen möglichen Eintrag auf jeden Fall entfernen. Ansonsten sind Probleme vorprogrammiert.
Hallo JoomlaWunder,
Danke Dir. Ich habe möglicherweise den "Loop" falsch verstanden. Manchmal arbeitet das Denkwerk bei der Hitze nicht so, wie es soll. Ich wollte damit ausdrücken, dass das Eingabeformular nach Eingabe der Daten und klicken auf Anmeldung sofort wieder in die Ausgangslage gelangt.
Alles anzeigenHi Lars,
willkommen im Forum.
Meldet die Browser Konsole was? Rechtsklick -> Untersuchen oder F12.
Wie schaut denn deine configuration.php aus, wenn der Login nicht möglich ist?public $cookie_domain = ''; -> leer ?
public $cookie_path = ''; -> leer?
public $live_site = ''; -> leer?
public $session_handler = 'database'; -> auf database setzen.
ggf. die #__session Tabelle mal checken/leeren.<oder mal mit
public $session_handler = 'filesystem';
probieren.Oder testweise mal force_ssl auf 0 statt 2.
Gruß
Pascal
Hi Pascal, vielen Dank für die Willkommensgrüße und ein dickes Lob an HTProtect. Die Komponente habe ich sofort auf meine anderen Webseiten installiert und sie funktioniert einwandfrei.
Nun zu meinen Problem. Alle EInträge in der configuration.php, die auf "leer" stehen müssen, sind leer. Das Umstellen von database auf filesystem ändert nichts. Die Konsole bei Brave meldet für den Bruchteil einer Sekunde eine rote Meldung, die aber verschwindet und nicht stehen bleibt. Nur Vivaldi gab die Meldung aus, die unten im Screenshot steht. Wie schon gesagt: Bei anderen Hostern läuft die Seite. Es muss also an Netcup liegen. Mehrals eine eins zu eins Kopie bei unveränderten Servereinstellungen kann ich nicht einspielen.
Hallo an alle hier,
ich bin neu hier, aber nicht bei Joomla. Da bin ich seit Version 1.5 dabei und bis dato immer alles sicher gelaufen. Nur leider jetzt nicht mehr.
ich habe ein Problem, das nur bei einen Server auftritt, der Nginx verwendet. Bei anderen Servern (vermutlich Apache) tritt das Problem nicht auf. Aber der Reihe nach:
Meine Website war leider Opfer des JCE-Hacks. Dummerweise habe ich vergessen, dass ich bei dieser Seite auch den JCE nutze. Bei meinen anderen Webseiten habe ich den JCE auf die neueste Version upgedatet. Sie waren nicht vom Hack betroffen.
Als ich ich die Website aufrief und auf einer dubiosen Site weitergeleitet wurde, war mir klar: Jetzt heißt es handeln. Ich habe ein garantiert sauberes Backup eingespielt und dachte, jetzt ist Ruhe. Denkste.
Ich wollte mich nach dem Zurückspielen sofort ins Backend einloggen und JCE aktualisieren. Geht nicht. Ich komme nicht ins Backend. Sobald ich die Daten eingebe, gibt es einen kurzen Loop, die Daten werden gelöscht und das war es.
Ich bin aber noch bei anderen Providern Kunde. Also die Website unter einer Subdomain dort eingespielt und siehe da, sie läuft einwandfrei. Ich habe dann alle notwendigen Updates vorgenommen und die Seite wieder mit Akeeba gepackt und wiederum bei Netcup eingespielt. Das selbe Problem.
Die ganzen Tipps wie Browsercache löschen, Einträge in der Configuration.php bringen nichts. Die Datei hat keine relevanten Einträge und das Problem tritt bei allen Browsern auf.
Außerdem habe ich die Seite nur zurückgespielt und nichts im Controllpanel des Poviders geändert.
Ich habe als Test, ob auf die Datenbank zugegriffen wird, einfach erfundene Daten in die Maske eingegeben. Resultat: Es kommt keine orange Fehlermeldung über die falschen Daten. Daher gibt es keine Datenbankabfrage auf Plausibilität, die eingegebenen Daten werden nur gelöscht
Kann es sein, dass All Ink Apache-Server betreibt? Ich hatte bisher nie Probleme mit Joomla-Webseiten unter Apache.
Netcup schweigt über das Problem bis jetzt. Ich wollte mit meinem Post die Expertinnen und Experten hier fragen, ob ein solches Problem wie meins bekannt ist?
Ich habe kein Problem, die Domain zu All Ink zu transferieren und dort die Seite zu betreiben.
Vielen Dank schon mal für die Antworten
Gruß Lars
