WebsiteBaker Logo
  • *
  • Templates
  • Help
  • Add-ons
  • Download
  • Home
*
Welcome, Guest. Please login or register.

Login with username, password and session length
 

News


WebsiteBaker 2.13.9 R24 is now available!


R.I.P Dietmar (luisehahne) and thank you for all your valuable work for WB
https://forum.websitebaker.org/index.php/topic,32355.0.html


* Support WebsiteBaker

Your donations will help to:

  • Pay for our dedicated server
  • Pay for domain registration
  • and much more!

You can donate by clicking on the button below.


  • Home
  • Help
  • Search
  • Login
  • Register

  • WebsiteBaker Community Forum »
  • Recent Posts

Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
General Help & Support / Re: Groß- Kleinschreibung bei Zugriffsdateinamen
« Last post by sternchen8875 on October 23, 2025, 02:41:17 PM »
Da hat sich der Dietmar ja was Feines ausgedacht  ;-)

Also.... der Dateiname läuft bei der Bearbeitung der Page-Settings dann als seo_title weiter. Das bedeutet, der User darf bestimmen, wie die Datei heißen soll. Damit folgte er anderen Systemen wie Wordpress oder (insbesondere) Joomla, wo das viel verbreitet wurde.
Reich code-technisch ist es so, das in der add.php der eingetragene Page_Title genutzt wird, das die erwähnte Funktion durchläuft, in der die Option CaseSensitive == false ist (per default)

Das läuft dann Analog auch in den Page-Settings, nur ist dort CaseSensitive == true, heißt: der User bestimmt die Schreibweise. Ich erspare mir die Sucherei im Forum, ob es dort mal eine Diskussion gegeben hat, könnte mir aber vorstellen, das das Setzen von CaseSensitive hier in guter Absicht passierte, um ein "Stück Selbstbestimmung" zu überlassen. Eine Rolle spielte dabei mit Sicherheit der Umbau der internen Funktionen und das Zusammenfassen mehrerer Funktionen in einer einzigen, der sanitizeFilename()
Sei es, wie es sei....

Nicht bedacht war dabei wohl die Option, die du verwendet hast, den Dateinamen herauszulöschen. In diesem Fall wird dann wieder auf den Page_Title zugegriffen, der in der Regel mit Großbuchstaben geschrieben wurde.

Was wäre die Lösung?
die Empfehlung geht ganz klar zur Kleinschreibung in Dateinamen. Es gibt auch keine Vor- oder Nachteile in SEO-Dingen. Von daher könnte man auf diese Option, die Schreibweise des Seo_Title selbst zu bestimmen, komplett verzichten, Dateinamen von AccessFiles werden dann immer klein geschrieben - Punkt. Fertig. Aber wir wissen, was da kommt, wenn etwas "weggenommen" wird....

die andere Option wäre es, genau deine Vorgehensweise abzufangen. Ist also kein sog seo_title übergeben, verwende wieder den Page_Title in Kleinbuchstaben

P.S.:
wen es direkt stört....

in der Datei admin/pages/settings2.php in Zeile 238

Original
Code: [Select]
$link = '/'.$parent_section.PreCheck::sanitizeFilename($seo_title,$bCaseSensitiv,$bPageNewstyle);
ändern in
Code: [Select]
$link = '/'.$parent_section.PreCheck::sanitizeFilename($seo_title, false, $bPageNewstyle);
22
General Help & Support / Re: Groß- Kleinschreibung bei Zugriffsdateinamen
« Last post by sternchen8875 on October 23, 2025, 01:36:14 PM »
Danke für den Hinweis.  (Y)
In der Theorie läuft der Dateiname durch die Funktion page_filename() - heute sanitizeFilename() - und die gibt einen klein geschriebenen Dateinamen zurück. Ich werde mal forschen, was da schief geht. Ich kann mich zwar nicht erinnern, da etwas getan zu haben, aber ein anderer kommt ja nicht in Frage.

Hast aber Recht, das sollte und muß einheitlich sein und wird dann wieder mit Kleinbuchstaben, wie es immer war.

23
General Help & Support / Groß- Kleinschreibung bei Zugriffsdateinamen
« Last post by ruebenwurzel on October 23, 2025, 01:13:15 PM »
Hallo,

mir ist gerade folgendes aufgefallen:

- beim Anlegen neuer Seiten wird der Acessfile Name kleingeschrieben. Beim Seitenname "Test" wird eine "test.php" erstellt.
- wenn ich bei den Seitenoptionen (pages/settings.php) den Namen der Zugriffsdatei herauslösche und über speichern neu generiere, wird beim Seitenname "Test" eine "Test.php" erstellt.

Ich würde eine einheitliche Schreibweise der Zugriffsdateinamen bevorzugen. Also entweder alles kleingeschrieben (meine bevorzugte Variante) oder in der gleichen Schreibweise wie der Seitenname. Auf die Funktionalität hat beides keinerlei Einfluss, insofern besteht technisch gesehen kein zwingender Grund hier was zu ändern, mir persönlich gefällt aber der Mischmasch aus unterschiedlich geschriebenen Zugriffsdateinamen nicht.

Gruß
Matthias

Ergänzung: WB 2.13.9 R24, PHP 8.4
24
Hilfe & Support (deutsch) / Re: Modul procalendar (v 1.8.2): Verbesserungen und Korrekturen
« Last post by sternchen8875 on October 17, 2025, 04:59:54 PM »
bevor ich mich hier ausklinke, versuch ich es noch einmal. Vielleicht verstehen wir uns ja nur falsch...

einer von uns scheint ein Zaubermodul zu haben oder es wurde schon soviel geändert, das es anders funktioniert. Kommentiere ich, wie vorgeschladen diese beiden Zeilen aus, fehlt mir in der Monatsübersicht des aktuellen Monats (Oktober 2025) die Auflistung der Termine
Code: [Select]
    $IsMonthOverview = ($month != date("n"));
    $IsMonthOverview = (($dayview && ($day != date("d"))) ? $IsMonthOverview : !$dayview);

Warum?

$IsMonthOverview ist per Initial == false

Nun Zeile 1

Code: [Select]
$IsMonthOverview = ($month != date("n"));Ist der Monat, der per Link kommt, ungleich dem von PHP ermittelten aktuellen Monat
Da Oktober 2025 mein Startmonat ist und wir Oktober 2025 haben, ist $IsMonthOverview immer noch false, weil die Bedingung nicht erfüllt wird

Möchte ich heute den Novemberkalender sehen, wäre die Bedingung wahr, der übermittelte Monat 11 ist nicht der PHP-Monat 10, $IsMonthOverview wäre dann true und heißt auf deutsch: zeige die Monatsanzeige (und nicht die Einzel-Tagesanzeige)

Nun Schalter 2

Code: [Select]
$IsMonthOverview = (($dayview && ($day != date("d"))) ? $IsMonthOverview : !$dayview);
Fall1: $IsMonthOverview ist false
übermittelt wird per Link nun entweder
page_id=18&day=18&month=10&year=2025&dayview=1
oder
page_id=18&month=11&year=2025

Uns interessiert vorallem $dayview in Link#1 und der day=18
da $dayview gesendet wurde und den Wert = 1 hat, wird es true. Bedingung 2 ist erfüllt, wenn der Link den day=18 übermittelt und PHP sagen würde, heute ist der Tag 18. Dann gilt also $IsMonthOverview. Und weil wir Oktober haben und PHP diesen Oktober als aktuellen Monat heute ermitteln würde, wäre $IsMonthOverview == false

Nun ist heute aber der 17 und nicht der 18. Bedingung 2 wird nun unwahr, es gilt also der letztere Teil hinter dem Doppelpunkt "!$dayview", also das Gegenteil vom Wert. $dayview war eine 1, das Gegenteil ist false oder 0. $IsMonthOverview ist also wieder false
Genau, was wir wollten, denn ich habe ja im Kalender angewählt, das die Tagesanzeige ausgegeben werden soll

Das funktioniert so auch hin und her, im Front- und Backend

Aber nach deiner Theorie muß ja die Version von hgs bei dir passen, also macht, wie ihr wollt, ist OpenSource


25
Hilfe & Support (deutsch) / Re: Modul procalendar (v 1.8.2): Verbesserungen und Korrekturen
« Last post by hgs on October 17, 2025, 03:25:04 PM »
ok, Danke sternchen8875 für die Info.
@ [/size]masju
 baust du eine 1.8.4.1 aus den Infos? Dann können wir weiter sehen und das fertige Modul wird dann am Ende eine 1.8.5 oder 2.0 (wie auch immer)
gerne dann hier anhängen zum testen

26
Hilfe & Support (deutsch) / Re: Modul procalendar (v 1.8.2): Verbesserungen und Korrekturen
« Last post by masju on October 17, 2025, 12:01:55 PM »
Quote from: hgs on October 17, 2025, 10:35:20 AM
Die Verbesserung konnte ich allerdings nicht nachvollziehen, Nach dem Speichern ist im BE wieder der aktuelle Monat sichtbar, oder mache ich einen Bedienfehler?
Der Monat bleibt (derzeit) nur beim Edit eines Events erhalten (Bearbeite z. B. einen Eintrag im Dezember 2025 und die Anzeige springt nach dem Speichern wieder auf Dezember 2025).
Zu überlegen wäre, ob noch eingebaut wird, dass das Kalender-Backend beim Neueintrag eines Events auch gleich in den Monat des neu angelegten Events springt.
27
Hilfe & Support (deutsch) / Re: Modul procalendar (v 1.8.2): Verbesserungen und Korrekturen
« Last post by masju on October 17, 2025, 11:50:43 AM »
Okay, das mit dem Schalter: einverstanden  :-) meine Erklärung war falsch.

Aber die Auswertung von $dayview ist hier trotzdem nicht wie erwartet. Denn: lasse ich die beiden Zeilen drin, verhält es sich wie folgt:

Klicke ich im Frontend im aktuellen Monat einen Tag an, schaltet der Kalender auf die Anzeige der Termine des angeklickten Tages (korrekt).  (Y)
Wechsel ich auf irgendeinen anderen Monat und klicke einen Tag an, bleibt die Anzeige trotzdem auf "Monatsübersicht" (nicht korrekt)  :-o.

Die Anzeige sollte nur von der Variable $dayview oder meinetwegen $IsMonthOverview abhängen.
28
Hilfe & Support (deutsch) / Re: Modul procalendar (v 1.8.2): Verbesserungen und Korrekturen
« Last post by sternchen8875 on October 17, 2025, 11:22:30 AM »
Besserwisser-Mode == on
Code: [Select]
$IsMonthOverview = ($month != date("n"));
    $IsMonthOverview = (($dayview && ($day != date("d"))) ? $IsMonthOverview : !$dayview);

Zeile 1 prüft, ist der im Funktionsaufruf übermittelte Monat $month gleich dem aktuellen Monat lt date-Funktion
Antwort ist true oder false - auf deutsch Ja oder Nein

Zeile 2 mußt du zerlegen in alle Einzelteile
$dayview und $day kommen aus dem Funktionsaufruf,
$dayview ist wieder true or false oder 0 bzw 1
$day ist der übermittelte Tag nach date-Funktion

also "auf deutsch": Ist dayview wahr UND der übermittelte Tag $day == dem ermittelten Tag aus der date-Funktion für heute, dann verwende den Wert von $IsMonthOverview. Ist das nicht der Fall, verwende den umgekehrten Wert von $dayview aus dem Funktionsaufruf

das Ganze ist also keine Initialisierung, es ist ein Schalter, der zwischen Tages- und Monatsansicht umschaltet und das unter verschiedenen Bedingungen

Nimmst du die Zeilen weg, wie vorgeschlagen, bekommst du in der Folge weitere Warnings, weil $IsMonthOverview nicht definiert wurde.

Zum Rest:
ich würde empfehlen, die Werte beim POST-Empfang schon zu validieren

also z.b. hier

Code: [Select]
$js_end_time = $admin->get_post('date2');
Wir wissen, es ist das Datum des End-Termins, es könnte in der Theorie aber alles sein (gilt für alles, was hier per POST in der save.php ankommt)

Setzt dir einen solchen dump in der save.php ganz oben

Code: [Select]
echo "<pre class='debug-dump'>DEBUG in " . basename(__FILE__) . " on line " . __LINE__ . ":<br>";
print_r($_POST);
echo "</pre>";

das macht es leichter
29
Hilfe & Support (deutsch) / Re: Modul procalendar (v 1.8.2): Verbesserungen und Korrekturen
« Last post by hgs on October 17, 2025, 10:35:20 AM »
OK, hier die geänderte Version 1.8.4.

Alle Änderungen sind wie folgt in den jeweiligen  Dateien gekennzeichnet worden.
Ist bestimmt nicht Codingstandard, aber zum nachvollziehen sollte es reichen.

// modify from https://forum.WebsiteBaker.org/index.php/topic,32440.new.html#new

Die Verbesserung konnte ich allerdings nicht nachvollziehen, Nach dem Speichern ist im BE wieder der aktuelle Monat sichtbar, oder mache ich einen Bedienfehler?

Viel Spaß beim testen, siehe weiterer Verlauf


Anhang gelöscht
30
Hilfe & Support (deutsch) / Re: Modul procalendar (v 1.8.2): Verbesserungen und Korrekturen
« Last post by masju on October 17, 2025, 08:39:56 AM »
Sehr gerne  :-)!
Pages: 1 2 [3] 4 5 ... 10
  • SMF 2.0.19 | SMF © 2017, Simple Machines
  • XHTML
  • RSS
  • WAP2