Kubik-Rubik das wäre sehr interessant - gibt es eine Demo oder ähnliches? gefunden habe ich nichts
Hey tekknotrip,
habe leider aktuell keine Demo-Seite für die Erweiterung, aber hier sind zwei Screenshots:
Eingeloggt mit Moderatorrechten:
Kubik-Rubik das wäre sehr interessant - gibt es eine Demo oder ähnliches? gefunden habe ich nichts
Hey tekknotrip,
habe leider aktuell keine Demo-Seite für die Erweiterung, aber hier sind zwei Screenshots:
Eingeloggt mit Moderatorrechten:
Das ist ein Joomla! Regressionsbug, der in Joomla! 6.1.0 eingeführt wurde. Es tritt bei verschachtelten Subforms (Subforms in Subforms) auf.
Der Bug wurde in diesem PR eingeführt: https://github.com/joomla/joomla-cms/pull/42347
Problem: https://github.com/joomla/joomla-…903b2609d1e863c
Falsch:
<fieldset class="<?php echo !empty($fieldset->class) ? $this->escape($fieldset->class) : ''; ?>"
Richtig:
<fieldset class="<?php echo !empty($fieldset->class) ? $this->escape($fieldset->class) : ''; ?>">
Das fieldset-Attribut wird nicht geschlossen und zerschießt das Layout.
Oh je, acht Sicherheitslücken? Beim achten Sicherheitsproblem seit 2021 kann man wohl nicht mehr von einem bedauerlichen Einzelfall sprechen. Gerade bei einer kommerziellen Erweiterung sollte man erwarten dürfen, dass zumindest die grundlegenden Sicherheitsprinzipien sauber umgesetzt werden. Wer Software veröffentlicht (und dafür Geld verlangt), trägt auch die Verantwortung dafür, die Grundlagen der sicheren Entwicklung im Griff zu haben.
Hier wurde die SVG-Datei (mit PHP-Code) zuerst hochgeladen und im zweiten Aufruf in eine PHP-Datei umbenannt, um den PHP-Code auszuführen.
Hallo Seppo,
du solltest zwei aufeinanderfolgende POST-Anfragen finden.
Die erste Anfrage auf das Loginformular im Backend ist notwendig, um das Sitzungstoken zu extrahieren; die zweite Anfrage geht dann an den Ajax-Endpunkt mit der Upload-Aktion (wie David gerade schrieb).
Viel Erfolg!
Bitte nicht raten oder nur nach irgendwelchen Plugins schauen, sondern die Server-Logs gründlich auf schädliche Aufrufe analysieren.
Du kannst auch die nicht minimierte Version in die min-Datei eintragen; sie wird beim nächsten Update dann mit der optimierten Version überschrieben.
Wie Rolf bereits schrieb, behebt dieser PR das Problem in Firefox ab Version 148. Die Änderung wurde bereits in die Codebasis aufgenommen und ebenfalls auf Joomla! 6 übertragen. Mit dem nächsten Update funktioniert der Editor wieder korrekt im Firefox.
Wer nicht warten möchte, kann die Datei media/plg_editors_tinymce/js/tinymce.js auch manuell anpassen. Aber aufpassen, wenn ihr nicht im Debugmodus seid, dann muss die dazugehörige min-Datei angepasst werden: media/plg_editors_tinymce/js/tinymce.min.js
Habe das hier angerissene Plugin für die explizite Freigabe per E-Mail von Auto-Updates veröffentlicht: Auto Update Approval Guard (AUAG)
Hallo hcohl,
du hast volle Kontrolle über die URL und kannst einen beliebigen Parameter setzen, um solche Klicks zu erkennen (zum Beispiel ga=1). Aber das brauchst du nicht, in der Regel erkennst du solche Aufrufe auch über den Auto-Tagging-Parameter gclid. Du könntest auch die utm_ Parameter als Erkennungszeichen verwenden.
Deine Idee mit einem separaten Popup-Fenster solltest du aber überdenken, besser wäre ein Onpage-Modalfenster.
Das Problem ist, dass die Ajax-Requests auf die Variante ohne www gehen. Wenn man deine Website aber mit www aufruft, dann kommt es zum besagten CORS-Fehler.
Stelle sicher, dass die Variante mit www auf die Hauptdomain ohne www umleitet (zum Beispiel mit einer .htaccess-Regel).
Hallo Stefan,
das funktioniert auch im Firefox nicht. Du hast ein CORS-Problem:
Erkärung und Lösung: https://developer.mozilla.org/de/docs/Web/HT…singAllowOrigin
Moin Dirk,
danke noch mal für die Zusendung, ich habe eine neue Version meines Wiederherstellungsskripts veröffentlicht. Im Changelog beschreibe ich auch das Kollation-Problem etwas genauer.
Hallo Dirk,
könntest du mir den Dump (am besten Link zum Komplettbackup) per Mail für eine Analyse zur Verfügung stellen?
Das kann man sicher abfangen und optimieren, damit es zu keinem Fehler kommt.
Hallo Christine,
natürlich ist das okay, aber meine Lösung ist ja nur ein Workaround, um den bereits fertigen String mit Hilfe eines Template Overrides zu manipulieren, damit man nicht die Core-Dateien anfassen muss.
Wenn man das im Core korrekt implementieren möchte, dann muss man entweder in die HtmlView (components/com_content/src/View/Archive/HtmlView.php) oder noch besser in das dazugehörige Model für die Jahre (\Joomla\Component\Content\Site\Model\ArchiveModel::getYears) eingreifen.
Hallo Shuffle,
du musst die normale default.php bearbeiten.
Hallo Kato,
wie hattest du den Verzeichnisschutz umgesetzt? Manuell?
Versuche es mal über die Weboberfläche von HostEurope: https://www.hosteurope.de/faq/cpanel-hos…rzeichnisschutz
Was dein anderes Problem betrifft:
Deine JS-Dateien können vom Browser wegen einer fehlerhaften Kodierung nicht gelesen und ausgeführt werden. Öffne doch mal diese Datei und schau, was der Browser dir ausgibt: https://www.emilfischerschule.de/media/system/js/core.min.js
Hallo Courtino,
es ist möglich, die Liste auch in einem Template Override zu manipulieren. Jedoch ist es etwas komplizierter, weil du da nur den fertigen HTML-String abgreifen kannst (wie Viviana es bereits sehr gut zusammengefasst hat) und nicht das Objekt selbst, das dieses Feld generiert.
Im Grunde kannst du alle Strings beliebig mit Hilfe von regulären Ausdrücken manipulieren. In diesem Fall haben wir ja stets eine vordefinierte Struktur, was uns die Sache wesentlich vereinfacht.
1) Erstelle ein Override für das Archiv-Template (im Template Manager dein Template auswählen -> Overrides estellen -> Komponenten -> com_content -> archive)
2) Suche die Zeile:
3) Erseze sie mit folgendem Code:
<?php $html = $this->form->yearField;
preg_match('/<option value=""[^>]*>' . Text::_('JYEAR') . '<\/option>/', $html, $placeholderMatch);
preg_match_all('/<option value="(\d{4})">(\d{4})<\/option>/', $html, $yearMatches, PREG_SET_ORDER);
$years = [];
foreach ($yearMatches as $match) {
$years[] = [
'value' => $match[1],
'html' => $match[0],
];
}
usort($years, fn($a, $b) => $b['value'] <=> $a['value']);
$placeholder = $placeholderMatch[0] ?? '';
$optionsSorted = array_map(fn($y) => $y['html'], $years);
$selectYear = '<select id="year" name="year" class="form-select">' . "\n";
$selectYear .= ' ' . $placeholder . "\n";
$selectYear .= ' ' . implode("\n ", $optionsSorted) . "\n";
$selectYear .= '</select>';
echo $selectYear; ?>
Alles anzeigen
Das war's schon!
Hallo Christine,
ich verstehe schon, wie das funktioniert. Mir ging es nur darum, ob man nach dem Klick in der E-Mail das Update direkt anstoßen muss oder ob das System es selber noch mal versucht.
Zu deiner Frage: David meinte damit, dass ein Entwickler, der so ein Plugin schreibt, sich nicht um den eigentlichen Update-Prozess kümmern muss.