Beiträge von Harmageddon

Das ist nicht direkt ein Fehler, sondern eine Sicherheitseinschränkung. Geh mal per FTP in den Ordner, in dem dein Joomla! liegt. Im Ordner "installation" wurde eine Datei angelegt, deren Namen du in dieser Meldung siehst. Die löschst du, um zu beweisen, dass du Zugriff auf den Server hast. Dann kannst du mit der Installation fortfahren. Nichts anderes löschen, wenn du nicht darum gebeten wirst!

Zitat von firstlady

Ach, du hast schon. Ich hab grade einen PR mit list-group und list-group-item in Arbeit

Issue hat Phil Taylor vor einer Woche erstellt. Ich hab mich gerade an einer Lösung mit grid-Klassen versucht, hab aber noch nichts wirklich Tragfähiges hinbekommen und muss jetzt wieder weg. Also wenn du da eine Idee hast, lass dich nicht abhalten!

Eins der Kernfeatures von Version 4 sind die Workflows. Darüber kann jetzt individuell gesteuert werden, welchen Status ein Artikel hat. Das schließt "Hauptbeitrag" und "Veröffentlicht" ein. Du kannst den Status aber weiterhin mit zwei Klicks in der Liste ändern, ist nur eine Spalte nach links gewandert. Wenn du auf die Stufe (Stage) klickst, kannst du Aktionen auf dem Artikel ausführen, wie z.B. ihn zu veröffentlichen.

Zitat von firstlady

Harmageddon wollen wir das als joomla-bug behandeln? Ich glaub, da haben sich schon mehrere angesammelt.

Würde ich schon sagen. Vor allem, da im Quellcode an der Stelle ein "dl-horizontal" zu finden ist, das seit Bootstrap 4 aber keinen Effekt mehr hat. D.h. es war ursprünglich mal anders vorgesehen. Leider muss man das in BS4/5 komplizierter per grid nachbauen.

Gibt auch schon ein Issue dafür: https://github.com/joomla/joomla-cms/issues/32247

Dann stimmen entweder die SMTP-Einstellungen nicht (sind das die gleichen wie auf Seite 1?) oder es liegt am Provider. Müsstest du mit dem mal Kontakt aufnehmen.

Zitat von bebra

Zuerst mal Danke an alle, die geantwortet haben. Leider ist mein Problem noch nicht gelöst. Das Update auf Joomla 3.9.24 hat diesen Fehler nicht behoben. Die geänderte Datei application.php funktioniert auch nicht. Ich kann also nach wie vor keine Email per smtp versenden. Da ich in einer Joomla-Instanz den PHP-Mailer nicht nutzen kann - weil vom Provider gesperrt - kann ich aus dieser Joomla-Instanz keine Mails versenden. Das ist Sch... Wenn es keine Lösung gibt, muss ich wohl auf Ver 3.2.22 downgraden, was mir natürlich nicht behagt.

Habe mir den Thread hier nochmal durchgelesen und mir scheint, du hast zwei Probleme, die nicht unbedingt die gleiche Ursache haben müssen:

1. Auf Seite 1 wird die Testmail nicht über SMTP, sondern über den PHP-Mailer versandt.
2. Auf Seite 2 wird keine Mail per SMTP versandt.

Bitte korrigiere mich, wenn ich da falsch liege.

Dann würde mich interessieren, ob die Testmail auf Seite 1 auch mit 3.9.24 per PHP-Mailer versandt wird (das war ja das, was in 3.9.24 behoben sein sollte). Wie sieht es mit anderen Mails aus, z.B. über das Kontaktformular? Gleiches Problem? Und siehst du in den Logfiles irgendwelche Fehler, die sich auf den SMTP-Versand beziehen?

Mittlerweile bin ich etwas verwirrt. Reden wir über J3 oder J4? In Version 4 hast du Recht, da müsste man den entsprechenden Check in die Methode ArticleModel::getForm (administrator/components/com_content/src/Model/ArticleModel.php) einbauen. Das müsste dann auch mit dem Nachladen funktionieren. In Version 3 wird da bei mir nichts neu geladen bei der Kategorieauswahl. categoryHasChanged finde ich dort auch nur in der Custom-Fields-Komponente.

Sorry für die sporadischen Antworten meinerseits hier. Habe aktuell unter der Woche relativ wenig Zeit und will vor einer Antwort aber das Problem erst ausführlich selbst bei mir nachstellen, damit ich dir keinen Unsinn erzähle.

Bei mir funktioniert der Codeschnipsel von Re:Later aus #4 einwandfrei, auch in J4. Um noch flexibler zu sein, könntest du auch den ModuleHelper verwenden. Dort lassen sich Module nach Position, ID oder Name laden, z.B. so:

$modules = ModuleHelper::getModules('sidebar-right');

foreach ($modules as $module)
{
    echo ModuleHelper::renderModule($module);
}

Zitat von Sieger66

Ergebnis identisch wie bei dir, wobei ich festgestellt hatte das die Erstellung und Veröffentlichung von Beiträgen im Backend problemlos möglich ist für die gleichen Benutzergruppen falls man diesen den Backendzugang ermöglicht.

Das geschilderte Problem also im Backend zumindest damals nicht vorhanden war.

Das kann ich auf einer 3.9.24 nicht reproduzieren. Da ist im Backend auch der Status gesperrt, solange man den Artikel noch nicht in der Kategorie abgespeichert hat, auf die der Benutzer Zugriff hat.

Zitat von LukasHH

Sobald in der Kategorieauswahl eine neue Kategorie ausgewählt wird, wird diese ID abgefragt, bevor die Ermittlung der Berechtigung erfolgt. Dadurch, dass die Seite bei der Auswahl neu geladen wird, funktioniert dieser Ansatz. Nur gibt es irgendwo noch andere "Stellschrauben", die ich noch nicht gefunden habe.

Das ist auch ein Lösungsansatz, der in dem Ticket genannt wird (überprüfen, welche Rechte man für die aktuelle Kategorie hat). Das müsste dann aber wahrscheinlich über AJAX laufen. Wo wird bei dir denn die Seite neu geladen? Wenn du die Kategorieauswahl im Frontend änderst? Das ist bei mir nicht der Fall.

Deine obige Lösung (Post #7) würde in das gleiche Problem laufen, wenn der Benutzer in mehreren Kategorien Beiträge erstellen, aber nur in einer den Status bearbeiten darf. Also entweder man lässt das wie aktuell statisch, sodass man einmal zwischenspeichern muss, damit die Kategorie feststeht, oder man lädt die Info per AJAX nach.

Zitat von Sieger66

Ich wollte eigentlich selbst schon ein Issue öffnen, wollte es aber erst in Joomla! 4 mal testen bzw. nachstellen ob das Problem dort auch noch so vorhanden ist. Ich hatte aber leider zuwenig Zeit dazu.

Hab es gerade getestet - es sieht aus, als wäre das in J!4 ähnlich. Könnte dort aber mit Workflows eventuell nochmal komplizierter werden, das weiß ich gerade spontan nicht.

Edit:

Zitat von LukasHH

Aber so wie dort darin geschrieben wurde, hatte das ja mal funktioniert. Wahrscheinlich, weil irgendwo an anderer Fehler vorlag und diese gefixt wurde.

Das würde mich ehrlich gesagt wundern. Aber solange niemand sagen kann, wann das mal funktioniert haben soll (und wie) halte ich das erst mal für Spekulation.

Das ist meines Wissens ein bekanntes Problem, da man bevor die Kategorie gewählt wird nicht wissen kann, welche Rechte dafür bestehen. Siehe z.B. https://github.com/joomla/joomla-cms/issues/17812

Wenn du hingegen für den "Artikel erstellen"-Menüpunkt die Kategorie festlegst, sollte es gehen. Müsste ich aber nochmal genauer nachschauen.

Wo genau findet man die Links in deinen Beiträgen? Bzw. wo sollten sie sein? Geht es nur um den Weiterlesen-Link oder auch um andere Weblinks? Der zu Google funktioniert bei mir.

Die Startseite sieht jetzt anders aus als gestern. Ich bin mir nicht sicher, ob ich dein Problem richtig verstehe, versuche es aber mal (mit dem, woran ich mich von der gestrigen Version erinnere, da ich bei der heutigen Version keinen Fehler sehe).

Du hattest Beiträge in einem Modul oberhalb der eigentlichen Startseite angezeigt. Wenn man da auf einen Beitrag geklickt hat, sah es so aus, als würde sich die Seite nicht verändern, da die Module oberhalb des Inhaltsbereiches gleich geblieben sind. Unten im Inhaltsbereich wurde mir der Artikel angezeigt. Wenn du die Beiträge auf deiner Startseite nicht im Inhaltsbereich, sondern im Modul anzeigen willst, und dann dieses Modul auf den Unterseiten ausblenden willst, hilft dir vielleicht der Advanced Module Manager. Mit dem kannst du einstellen, dass das Modul nur auf der Startseite angezeigt wird. Im Core kannst du sowas zwar auch einstellen, allerdings bezieht sich das dann auf den aktuellen Menüpunkt. Da deine Beiträge keine eigenen Menüpunkte haben, bleibt der Startseiten-Menüpunkt aktiv und daher auch die ihm zugeordneten Module.

Wenn du die Module selbst programmierst, kannst du darin entweder onContentPrepare triggern, sodass das Plugin die Ersetzung vornimmt, oder (besser, da keine Ersetzung vonnöten) selbst das zweite Modul per PHP nachladen. Dafür gibt es den ModuleHelper, siehe z.B. im loadmodule-Plugin, wie dieser verwendet wird: https://github.com/joomla/joom…odule/loadmodule.php#L232

Hallo und herzlich Willkommen!

Joomla! bietet von Haus aus leider keine Möglichkeit an, das Update per Kommandozeile durchzuführen. In deinem Fall würde ich empfehlen, ein Backup von Dateien und Datenbank zu machen, dieses in einer lokalen Testumgebung (XAMPP, Wamp, Mamp o.Ä.) einzuspielen, dort zu aktualisieren und dann die aktualisierte Version wieder hochzuladen. Ist eh deutlich sicherer, als das Update direkt auf der Produktivseite online durchzuführen, weil du dann, wenn irgendwas schief geht, schneller wieder auf das Backup zurück kannst und nix kaputtmachst.

Da wird die error-log-Datei von Joomla! erstellt. Das an sich ist kein bedenklicher Vorgang, da wird ja nur etwas protokolliert, z.B. dass jemand versucht hat, sich mit dem falschen Passwort einzuloggen, oder dass irgendeine Erweiterung Fehler produziert. Schau doch mal in die Datei rein, was da drin steht.

Es gibt auch Plugins, die das Backend so sichern, dass man nur mit einem Token zugreifen kann, also mit administrator/index.php?token=blablubb. EasyCalcCheck Plus (ECC+) wäre so ein Kandidat. Das vielleicht auch mal über die Datenbank deaktivieren.

Empfehlenswert ist auch, die Option "Kopie an Absender" zu deaktivieren, da auch diese zum Spamversand genutzt werden kann. (Jemand trägt ins Textfeld Spamtext ein, gibt eine tatsächlich existierende Mailadresse eines Dritten an, und dann bekommt dieser Spam, der von deiner Website versandt wird.)

Versuch mal, erst im Event-Handler das chkboxes-Array neu aufzubauen. Also:

    var lastChecked = null;
    $('.chkbox').click(function(e) {
      var $chkboxes = $('.chkbox');
...

Denn wenn du die Variable $chkboxes in Zeile 1 erstellst, ändert sich deren Reihenfolge danach nicht mehr.

Ich schließe mich eurer Meinung an. Finde das auch an vielen Stellen lästig, das Datum dann zurückrechnen zu müssen (hier im Forum auch, wobei das hier noch etwas eher gerechtfertigt ist). Allerdings vermute ich, dass das mit J3 nicht mehr geändert wird, sondern erst in J4.

Ich habe hier einen Pull Request erstellt, um einen Parameter einzuführen, mit dem man diese Anzeige ausschalten kann: https://github.com/joomla/joomla-cms/pull/31675

Wenn du darauf nicht warten willst, könntest du dir auch für das Administratortemplate ein Template Override dieser Ansicht (com_actionlogs / actionlogs / default.php) erstellen, und dort diese Zeile

                            <td>
                                <span class="hasTooltip" title="<?php echo HTMLHelper::_('date', $item->log_date, Text::_('DATE_FORMAT_LC6')); ?>">
                                    <?php echo HTMLHelper::_('date.relative', $item->log_date); ?>
                                </span>
                            </td>

so abändern:

                            <td>
                                <span class="hasTooltip" title="<?php echo HTMLHelper::_('date', $item->log_date, Text::_('DATE_FORMAT_LC6')); ?>">
                                    <?php echo HTMLHelper::_('date', $item->log_date, Text::_('DATE_FORMAT_LC6')); ?>
                                </span>
                            </td>

Wenn ich das richtig sehe, müsste es aber auch gehen, wenn du vor dem Versenden der Testmail das Passwortfeld nochmal ausfüllst (ohne zu speichern). Klappt das?

Zitat von courtino

Danke euch allen

PS: wie kann ich die lokale php einstellen, hab sowas noch nie gemacht

Falls du den Beitrag von JoomlaWunder meinst: Mit global ist die Einstellung beim Hoster gemeint, mit lokal die in der htaccess für das Verzeichnis.