Beiträge von Re:Later

Zitat von Pool

$db->setQuery($query);

macht erst mal nichts anderes als die DB-Instanz mit der Query zu befüllen. Ausgeführt wird noch nicht. In deinem Fall (löschen) fehl wohl

$db->execute();

Oder ausführlicher mit Fehler abfangen:

try
{
    $db->execute();
}
catch (RuntimeException $e)
{
    return JError::raiseWarning(500, $e->getMessage());
}

, was aber in Joomla 4 im Core in dieser Art wieder "abgeschafft wurde", ohne, dass ich verstanden hätte warum, was nun "best practice" ist. Funktioniert aber vom Prinzip her trotzdem noch.

->where($db->quoteName('id' == $id_lspd));

Das ist (neben falsch) ggf. auch gefährlich (SQL-Injections), wenn man versucht es falsch richtiger zu machen

So:

->where($db->quoteName('id') . ' = ' . $db->quote($id_lspd));

EDIT:

Wenn das eine ganze Integerzahl ist, dann würde ich das schon früher "sanitizen", bspw.

$id_lspd = (int) $app->input->get('kill_id_lspd');

aaaaaaber ich habe hier zu wenig mitgelesen. Nur so reingeplärrt.

Zitat von marscom

Beim und so weiter eben anstehe.

Na ja. Den Teil hattest du ja schon in deinem eigenen Code Zeilen 5 bis 12. Kannst natürlich auch mit empty($output) arbeiten. Vom Effekt das Selbe.

Zitat von jetlag1975

wenn ich möchte, dass ein Modul ohne Inhalt nicht angezeigt wird stecke ich es in

Das Modul ist ja nicht leer, wenn es nur keine Beiträge ausgibt. Das Grundgerüst des Modulstils wird trotzdem generiert, also das äußere Gerüst. Damit ist das count() leider auch WAHR.

Der "Advanced Module Manager" von RegularLabs hat einen Knopf drinnen "Ausblenden falls leer", der das glaub ich berücksichtigt. Da bin ich aber nicht sicher, ob das hier eine Lösung wäre, weil ja der Wunsch war, eine Alternative auszugeben.

In Joomla 4 wird es wohl eine weitere Methode geben mit der man über das count() oder ähnlich prüfen kann, ob "inhaltlich" leer. Habe ich aber aus den Augen verloren wie und ob das integriert wurde.

Und, wenn dich der Wurm "

\Joomla\CMS\Helper\ModuleHelper::...

" nervt, schreibst in der Datei, wo der Code drinnen ist nach dem

defined('_JEXEC') or die;

ein

use Joomla\CMS\Helper\ModuleHelper;

und kannst im eigenen Code abkürzen auf

ModuleHelper::...

ohne Wurm.

Zitat von marscom

Das Modul heisst - man staune - newsticker.

Das musst genauer klar machen. Ein Modul hat einen title und einen name. title ist das, was man im Titelfeld eingibt, name ergibt sich aus dem Erweiterungsnamen. Aus mod_custom wird der name custom.

Allgemein geht das so

<?php
// Abfrage der Module an einer POSITION(!!!!)
$output = '';
$position = 'banner';
$modules = \Joomla\CMS\Helper\ModuleHelper::getModules($position);

foreach ($modules as $module)
{
  // Oder name? Oder ...?
  if ($module->title == 'newsticker')
  {
   $output = \Joomla\CMS\Helper\ModuleHelper::renderModule($module);
   break;
  }
}

if ($output === '') und so weiter ....

Da empfiehlt sich dann vielleicht gleich eine Phantasie-Position nur für dieses Modul einzugeben. Weil der Titel oft unzuverlässig ist, wenn man ihn mal ändert.

<?php
// Abfrage der Module an einer individuellen POSITION(!!!!)
$output = '';
$position = 'meineErfundenePosition';
$modules = \Joomla\CMS\Helper\ModuleHelper::getModules($position);

// Sollte ja dann nur eins sein. Kann man sich das if sparen.
foreach ($modules as $module)
{
   $output = \Joomla\CMS\Helper\ModuleHelper::renderModule($module);
}

if ($output === '') und so weiter ....

Oder mehrere Module an der Phantasie-Position?

<?php
// Abfrage der Module an einer individuellen POSITION(!!!!)
$output = array();
$position = 'meineErfundenePosition';
$modules = \Joomla\CMS\Helper\ModuleHelper::getModules($position);

// Kann man sich das if sparen.
foreach ($modules as $module)
{   $output[] = \Joomla\CMS\Helper\ModuleHelper::renderModule($module);
}

$output = implode('', $output);

if ($output === '') und so weiter ....

Schau, ob es unter Erweiterungen > Überprüfen aufeglistet ist und installiere es nach. Ggf. den Knopf oben klicken. Weiß nicht wie der heißt. Wohl auch "Überprüfen".

Ansonsten musst erst den Ordner /plugins/system/updatenotification aus einem entpackten 3.9.24-Full-Paket per FTP hochkopieren. Dann noch mal Überprüfen.

Vielleicht fehlen dann noch Sprachdateien. Meld dich noch mal.

Zitat von Elwood

Denn der Seminarmanager ist ja aktuell

Man muss dazu wissen, dass der Seminarmanager ab Version 3 kostenpflichtig wurde. Daher dümpeln noch einige 2-er im Netz. (Unabhängig von der Tatsache, dass TE noch dazu eine bereits gehackte Version verwendet, so nenne ich das zumindest, die nicht geupdatet werden kann/darf/whatever.).

Sicherheits-Updates gab es auch für den SM in den letzten x Jahren immer mal.

Es ist stocksimpel für einen Hacker-Bot zu ermitteln, ob Seminarmanger überhaupt installiert ist bzw. auf eine harmlose Anfrage "reagiert". Wenn ja und wenn irgendwelche Vulnerabilitäten bekannt sind, egal, ob lange im Core gefixt, ballert man halt erweiterungsspezifisch weiter. Mal sofort, mal etwas später, mal forciert, mal dezent. Andere Bots ballern nur auf gut Glück vor sich hin.

Da hilft dann nur ein intensives Studium der Server-Access-Logs, die natürlich ausreichend vorliegen müssen, um die Linie des/der Bots zu erforschen.

Zum Thema eigen Funktionen und Kram.

Zumindest der alte Seminarmanager 2 hatte viele eigene Plugin-Events dabei. Findet man im Code an Stellen, die alle so oder so ähnlich aussehen:

$dispatcher=JDispatcher::getInstance();
JPluginHelper::importPlugin('seminarman');
$extData = $dispatcher->trigger('onGenerateSPEmail', array(array($queryResult->course_id, $msgSubject, $msgBody, $queryResult->attendees)));        

Es werden also Events/Methoden in Plugins der Plugin-Gruppe "seminarman" aufgerufen. Im obigen Beispiel Methode

onGenerateSPEmail

Kannst also schon mal eigene Plugins verwenden.

Es sollte aber auch funktionieren, ein eigenes Joomla-System-Plugin zu verwenden, in dem die Methoden enthalten sind. Im Normalfall werden die dann auch durch obige Zeilen aufgerufen.

Aber, ich weiß natürlich nicht, ob was dabei ist, was dir direkt hilft. Oft, wie z.B. bei JoomShop, das auch jede Menge so eigene Trigger drin hat, muss man noch einiges an HirnSchmalz aufbringen, in Controllern und Models rumwühlen, wenn man echt erweitern will, weil bestimmte Daten, auf die man eigentlich aus ist, gar nicht ans Plugin geschickt werden...

Meist ende ich in einem mehr oder weniger wüsten Konglomerat aus eigenem Plugin, Overrides, JavaScript mit AJAX (was ja dann auch via Plugin "verwaltet" werden kann). Aber wenigstens updatefähig Vom Grundprinzip her Wenn der Erweiterungs-Core sich deutlich ändert, muss man leider trotzdem nacharbeiten und -korrigieren.

Jedenfalls sollte man vorher abreißen, was "Kunde" eigentlich wirklich dringend benötigt und nichts vorschlagen, was "Kunde" vielleicht haben können wollte. Erfahrungswert

Zitat von Elwood

$mainContentWidth = 12 - ($asideLeftWidth + $asideRightWidth);

Muss sein

$mainContentWidth = 12 - ((int) $asideLeftWidth + (int) $asideRightWidth);

Es gäbe auch noch andere Ansatzstellen im Code, um letztlich zum Ergebnis zu kommen.

Eigentlich wäre es schon Aufgabe des Eingabefelds im Templatestil eine Integerzahl zu forcieren. Geht in Joomla nämlich ganz einfach durch Verwendung von filter="" in den Feldern.

Also: Überall wo man mit Zahlen rechnet und die Zahlen ganze Integerzahlen sind, was ja oben der Fall ist, setzt mein ein (int) oder (integer) davor. So erzwingt man das "Diese Variable ist jetzt eine ganze Zahl; zum Rechnen geeignet".

Ein String, der nicht mit einer Zahl beginnt, wird zur Zahl 0 durch das (int).

"" wird zu 0.

"5" wird zu 5.

"0" wird zu 0.

"1blödesDing" wrd zu 1.

"blodesDing1" wird zu 0.

"3.89" wird zu 3

mit (int) davor.

Bei Kommawerten, nimmt man dann was anderes, um die Zahl zu erzwingen.

Stichwort "Type Casting": https://tutorials.supunkavinda.blog/php/type-casting

Wäre

$asideLeftWidth

schon eine Integer-Zahl, stört das (int) auch nicht. Läuft dann eher unter "unnötig doppelt gemoppelt".

Zitat von deltapapa

jetzt brauche ich nur noch ein Opt-In für den Cookie

Das Coolcat-Dingens Schreibt doch erst Cookie, wenn Benutzer aktiv einen Knopf klickt. Da schreibst halt drüber: "Wenn Sie klicken, willigen Sie ein Blah blah ... Schreibt Cookies! ... Siehe Datenschutzerklärung!".

Da müssen die jeweiligen Cookies halt zusätzlich erwähnt werden.

Bzgl. des ersten Fehlers würde ich mal die error.php des Templates umbenennen, falls das die Ausgabe schon inklusive Debug und "Fehler berichten" = Maximum war. Der Stack wäre schon interessant.

Zitat von Elwood

Nach Umschaltung auf Protostar mit Call Stack erscheint das

Da wundert mich, dass der Override aus dem anderen Template überhaupt gezogen wird. Der sollte ja Protostar gar nicht interessieren, falls nicht irgendein Framework-Plugin und oder dummes Modul oder so den ins Spiel bringt. "wrap_with_tag(" ist jedenfalls weder ein Joomla noch ein PHP-Ding. Heißt also, dass die Datei, in der diese Funktion hinterlegt ist gar nicht geladen wird.

Zu Fehler 1: In PHP8 gibt es ein paar Ecken und Ösen, dass man z.B. bei Verwendung von "+" explizit numerische Werte verwenden muss. Oder Strings eben mit "." verknüpfen muss und nicht mit "+" darf. Irgendsowas wird das bei dir sein. Meist aber leicht zu kösen, wenn man die Fehlerstelle sieht...

Eigentlich gibt es nur Probleme, wenn de Seite, die den Iframe einbindet unter https läuft und die Zielseite http ist. Umgekehrt sollte das gehen.

Es gibt allerdings Seiten, die blockieren, dass man sie als Iframe einbindet.

Und für Leute, die das gerne mal ausprobieren, ohne lange rumsuchen zu müssen, welcher Sprach-String ist das denn?

Zitat von Mister.X

Darf ich mal blöd fragen, ob das evtl. in der Joomla 4 einfacher möglich wird?

Ich sage nicht, dass es nicht echt blöde (=nervig) ist, dass die FieldsHelper nicht was drinnen haben, was solche Abfragen ohne Verwirrung und Gefluche möglich macht, noch dazu, wenn man bspw. auch noch mit Feldgruppen arbeitet, nach denen man filtern (nicht nur sortieren/gruppieren!) möchte, aber, jetzt die Antwort, wohl nein, weil eben im Joomla-Core selbst kein Bedarf besteht. Noch weniger bei Benutzern als bei Artikeln.

Wenn mir jetzt jemand widerspricht, bin ich natürlich hoch erfreut

Musst dir also selber Helper-Klassen schreiben müssen, wenn du so was öfter benutzen willst und dir beim nächsten Projekt die Abfragen erleichtern willst. Eigenes hat oft den Vorteil, dass du es eben bei Bedarf selbst erweitern kannst. Grundlegendes Problem ist ja meist die komplexe Struktur der Felder-Komponente, -Plugins und des resultierenden Datenbankaufbaus, wenn man mal eben dann wenigstens eine eigene Datenbankabfrage basteln will. Z.B. nur Felder, dann noch nach Namen, für mehrere Benutzer ziehen, wenn Benutzer in betr. Feldgruppe überhaupt Felder belegt haben. Das beschäftigt einen dann schon, je nach Skills, unverhältnismäßig lange; irgendwie...

Zitat von tekknotrip

und ich im Backend das Session handling von MySQL auf PHP umstelle, so funktioniert das wieder.

Warum lässt du's dann nicht einfach auf "PHP"?

Die /tmp-Meldung meint eine PHP-Einstellung, nicht das Joomla-Temp-Verzeichnis. 2 Paar Stiefel.

Zu Session-Problematik kann ich mich weiters nur erinnern, dass ich für einen Kunden mal den "session.save_path" umschreiben musste, auf ein Verzeichnis innerhalb des Kunden-Accounts, so, dass wir die Schreib/Lese-Rechte dann selber setzen konnten und wir sicher sein konnten, dass keine weiteren serverseitigen Restriktionen zuschlugen. Danach war Ruhe...

Zuerst würde ich "Fehler berichten" in der Joomla-Konfiguration ausschalten.

Zusammenhang könnte sein, dass die "PHP Notice" dazu führt, dass "incomplete headers" entstehen. Also, einfach kaputt sind durch die zuvor abgeschickte Notice.

Mal sehen...

Geh erst mal in die Joomla-Konfiguration.

Dort Tabulator "Textfilterung".

Prüfe die Einstellung für die Benutzergruppe zu der dein angemeldeter Benutzer gehört.

Joomla-Core hat keine Instagram-Erweiterung dabei.

Fällt mir nur ein, mit 2 verschiedenen Browsern zu arbeiten.

Zitat von JoomlaWunder

Aber womöglich gar nicht jene, welche in den sql-Dateien im Verzeichnis "installation" liegen, da das dann ja gar nicht mehr existiert?

Exakt. Kannst ja mal in die plugins/sampledata/blog.php reinschauen. Eine SQL wird da nicht gezogen. Lediglich per PHP die Datenbank weiter befüllt. Deswegen meinte ich oben

Zitat von Re:Later

Klar kann man aus so einem Plugin theoretisch auch SQL-Dateien ausführen lassen und diese userIds anpassen, Konflikte lösen etc. pp.

Zitat von JoomlaWunder

müsste es doch irgendwie möglich sein, diese sql-Datei anstatt der base.sql, extensions.sql und supports.sql zu verwenden, also so wie in #1 unter Punkt 2 beschrieben.

Das nicht. Die Dateien müssen allerwenigstens existieren, sonst bricht die Installation ab. Ob man sie nun leer lassen kann, müsste man prüfen.

Ich würde erst mal plump eine zusätzliche custom.sql hinterlegen mit einem unverfänglichen Einzeiler oder so. Ob die Datei ausgeführt wird. Mir scheint das so.

Es gibt da dieses Array

https://github.com/joomla/joom…nController.php#L143-L149

Die Werte sind letztlich SQL-Dateien ohne sql-Endung. Wobei die custom1 und custom2 optional existieren können.

Je nach Installationsschritt wird nach ein wenig Prüfungsgeplenkel diese Methode aufgerufen

https://github.com/joomla/joom…el/DatabaseModel.php#L472

die die SQL-Datei ausführt.

So meine fiktive Interpretation des Codes

Man darf sich nicht davon irritieren lassen, dass die Dateien alle $schema oder ähnlich im Codeverlauf genannt werden. Für mich war "Schema" zuvor auch was anderes Auch die Warnmeldungen, die von Schema reden, meinen oft lediglich "Datei fehlt".