Neue Unterkategorie wird nicht mehr angezeigt

[kai]

die ?> am Ende braucht man nicht und machen häufig Probleme. Die fehlen inzwischen in jeder Datei.

Das wäre mir völlig neu. Wo kann man denn dazu was nachlesen?

[Thorsten]

Hi,

die ?> am Ende braucht man nicht und machen häufig Probleme. Die fehlen inzwischen in jeder Datei.

Das wäre mir völlig neu. Wo kann man denn dazu was nachlesen?

im PHP Manual: http://www.php.net/manual/de/language.b ... ration.php

bye
Thorsten

[kai]

Bin jetzt soweit mit meinen Änderungen durch. Gibt es eigentlich eine "unterstützte" Art, die Sprachenauswahl zu beschränken? Ich habe da irgendwo im Code ein "$lang=all" o.ä. gesehen, das in 2.0.1 noch nicht vorhanden war. Bisher lösche ich einfach alle unerwünschten lang files.

Bei diesem Punkt wäre eine Änderung meines Ermessens sinnvoll:

lang files:
$PMF_LANG["msgLatestArticles"] = "Die neuesten Artikel";

Die Zahl entfernen. Dadurch wird es zum einen kürzer, so daß das RSS Icon noch in die gleiche Zeile paßt, zum zweiten kann man die Anzahl ja in constants.php ändern, so daß "fünf" dann falsch ist und angepaßt werden muß ... Die Entfernung der Zahl hat also zwei positive Effekte.
Im englischen ist der Text auch m.E. völlig falsch übersetzt:
$PMF_LANG["msgLatestArticles"] = "The five questions posted most recently:";

das sind eben nicht die letzten fünf Fragen, sondern eher die letzten 5 Antworten, oder nicht?
entsprechend angepaßt ohne Zahl:
$PMF_LANG["msgLatestArticles"] = "The latest articles";

[Thorsten]

Hi,

Bin jetzt soweit mit meinen Änderungen durch. Gibt es eigentlich eine "unterstützte" Art, die Sprachenauswahl zu beschränken? Ich habe da irgendwo im Code ein "$lang=all" o.ä. gesehen, das in 2.0.1 noch nicht vorhanden war. Bisher lösche ich einfach alle unerwünschten lang files.

nein, bis auf das manuelle Löschen gibts da derzeit noch nichts.

Bei diesem Punkt wäre eine Änderung meines Ermessens sinnvoll:

lang files:
$PMF_LANG["msgLatestArticles"] = "Die neuesten Artikel";

Die Zahl entfernen. Dadurch wird es zum einen kürzer, so daß das RSS Icon noch in die gleiche Zeile paßt, zum zweiten kann man die Anzahl ja in constants.php ändern, so daß "fünf" dann falsch ist und angepaßt werden muß ... Die Entfernung der Zahl hat also zwei positive Effekte.
Im englischen ist der Text auch m.E. völlig falsch übersetzt:
$PMF_LANG["msgLatestArticles"] = "The five questions posted most recently:";

das sind eben nicht die letzten fünf Fragen, sondern eher die letzten 5 Antworten, oder nicht?
entsprechend angepaßt ohne Zahl:
$PMF_LANG["msgLatestArticles"] = "The latest articles";

hab ich in der 2.0.13 und 2.5.0-alpha2 geändert. Danke für den Hinweis!

bye
Thorsten

[kai]

Hier mal ein Teil meiner Änderungen als Vorschlag. Ich nehme folgende Änderungen an der sidebar rechts vor.
Der Grund dafür ist eine wesentlich bessere Platzausnutzung. sowie ein m.E. vernünftigerer Datumsoutput.

Bei TopTen verbraucht die Standardausgabe mindestens zwei Zeilen, meine braucht nur eine und enthält dennoch die gleiche Information.

So kann ich locker die LatestArticles auf 10 erhöhen.
Außerdem ändere ich hier die Datumsangabe auf eine für Deutschland sinnvolle (hier wäre entsprechend vielleicht in constants.php eine Formatvorgabe möglich, die makeDateShort dann übernehmen könnte) und ich verzichte auf die Uhrzeit. Die meisten FAQs werden da keine Uhrzeit brauchen. Auch dadurch wird massig Platz gespart und der Titel der FAQ kommt besser zur Geltung.

Zeilennummern sind so nach der Änderung.

Code: Select all

functions.php:
function makeDateShort($date)
{
    $offset     = (60 * 60) * (PMF_DATETIME_TIMEZONE / 100);
    $current    = strtotime(substr($date, 0, 4) . '-' .
                  substr($date, 4, 2) . '-' .
                  substr($date, 6, 2) . ' ' .
                  substr($date, 8, 2) . ':' .
                  substr($date, 10, 2));
    $timestamp  = $current + $offset;
    return date('d.m.Y', $timestamp);
}

Faq.php:
Zeile 1573
getTopTen
    $output .= "<li>";
    #$output .= sprintf('<li><strong>%d %s:</strong><br />',
    #$row['visits'],
    #$this->pmf_lang['msgViews']);
    ....
    $output .= " (".$row['visits'].")";

Output dann: FAQ-Titel (Anzahl der Visits)

Zeile 1608
getLatest
    makeDateShort($row['datum']));

Output dann: FAQ-Titel (16.02.2009)

[Thorsten]

Hi,

gute Idee... das ist aber was für die 2.5, in der 2.0 fixe ich nur noch Bugs...

bye
Thorsten

[kai]

gute Idee... das ist aber was für die 2.5, in der 2.0 fixe ich nur noch Bugs...

Verstehe, schade. Muß ich das noch irgendwo als Vorschlag für die 2.5 einreichen oder reicht das dann?
2.5 habe ich mir noch nicht angeschaut. War da nicht PHP 5.2 die Voraussetzung?

Ich mache dann noch eine größere Änderung bezüglich des Logins in index.php/index.tpl. Ich entferne die Loginbox und die Anzahl der Logins (Sessions). Das ist für FAQs mit vielen Nutzern natürlich nicht so sinnvoll. Aber für FAQs mit einem oder wenigen Autoren paßt es gut, denn da brauche ich keine Loginbox auf der Startseite und auf jeder Folgeseite. Nimmt nur Platz weg und lädt zum Mißbrauch/Spielen ein. Stattdessen erscheint in der Navigation oben nur bei Zugriff über SSL ein weiteres Link "Administration", das einen dann zu admin/index.php bringt. Alternativ kann man auch die Loginbox behalten, aber eben nur bei SSL auftauchen lassen. o.ä.
Bei Interesse kann ich dafür noch den Code posten.

Alle anderen Änderungen sind eigentlich in Templates und überdauern die Updates

[Thorsten]

Hi,

Verstehe, schade. Muß ich das noch irgendwo als Vorschlag für die 2.5 einreichen oder reicht das dann?

am besten per E-Mail.

2.5 habe ich mir noch nicht angeschaut. War da nicht PHP 5.2 die Voraussetzung?

Ja, kennst du ein anderes PHP, das noch unterstützt wird?

Ich mache dann noch eine größere Änderung bezüglich des Logins in index.php/index.tpl. Ich entferne die Loginbox und die Anzahl der Logins (Sessions). Das ist für FAQs mit vielen Nutzern natürlich nicht so sinnvoll. Aber für FAQs mit einem oder wenigen Autoren paßt es gut, denn da brauche ich keine Loginbox auf der Startseite und auf jeder Folgeseite. Nimmt nur Platz weg und lädt zum Mißbrauch/Spielen ein. Stattdessen erscheint in der Navigation oben nur bei Zugriff über SSL ein weiteres Link "Administration", das einen dann zu admin/index.php bringt. Alternativ kann man auch die Loginbox behalten, aber eben nur bei SSL auftauchen lassen. o.ä.

Das ist mit der 2.5+ auch besser machbar, da kann man dann Blöcke in den Templates definieren...

bye
Thorsten

[kai]

am besten per E-Mail.

ok, demnächst.

Ja, kennst du ein anderes PHP, das noch unterstützt wird?

Oh, ja, tue ich. Jede vernünftige Enterprise-Distribution unterstützt eine bestimmte PHP-Version, die von Anfang an dabei ist. Security Fixes und andere Bug Fixes werden dann "backported". Wir benutzen z.B. CentOS 5 (z.Z. 5.2). Das kommt mit PHP 5.1.6 und wird bis 2014 unterstützt. Und es gibt keinen Grund, damit nicht bis dahin zu laufen. Bisher habe ich auch noch keine Probleme mit dem 5.1.6 entdeckt. Genauso läuft bei uns noch CentOS 4 (momentan in der Version 4.7) mit PHP 4.4.3 (wenn ich mich recht erinnere). Ähnlich ist es bei Suse-Enterprise. Und so ähnlich siehst du das bei fast allen Providern und vielen Firmen, besonders größeren. Wer sich das neueste Fedora, Suse oder Ubuntu draufpackt, sind vor allem Privatuser mit Rootserver. Diese Privatdistributionen werden i.d.R. viel zu kurz mit Sicherheitspatches bedacht und was glaubst du wohl, welche Distributionen da regelmäßig gehackt werden? Ja, genau diese. Denn irgendwann gibt's keine Sicherheitsupdates mehr, aber der User scheut das Inplace-Upgrade auf eine komplett neue major-Version.

Das ist mit der 2.5+ auch besser machbar, da kann man dann Blöcke in den Templates definieren...

Tja, wenn es denn mit 5.1.6 laufen würde. Ich könnte zwar auf 5.2.irgendwas per CentOSPlus upgraden, aber sehe ehrlich gesagt keine Veranlassung dazu, da 5.1.6 eben perfekt läuft und sicherheitsmäßig unterstützt wird, worauf ich mich bei dem 5.2.irgendwas nicht so ganz verlassen kann.

[kai]

hab ich in der 2.0.13 und 2.5.0-alpha2 geändert.

Hier ist noch ein Fehler in den langs:

$PMF_LANG["msgWriteComment"] = "Artikel kommentieren";

muß heißen

$PMF_LANG["msgWriteComment"] = "Artikel zu kommentieren";

und ein Punkt fehlt am Ende des Satzes.

[kai]

faqcategories reicht nicht, du brauchst auch faqcategory_groups und faqcategory_user[/b

Sodale, bin jetzt dazu gekommen, mir das anzuschauen. Die neuen (und nicht angezeigten) Subkategorien haben die Ids 44, 45 und 46. 44 und 45 sind "real" und gehören zur Kategorie 43 (parent_id). Die 46 hatte ich nur zum Test hinzugefügt und einer anderen Kategorie zugeordnet.
Ich hatte bisher *keine* Änderungen außerhalb PHPMyFAQ daran durchgeführt.
group enthielt jeweils 0 für alle drei Subkategorien, für alle anderen, angezeigten dagegen -1.
user enthielt 0 für 44 und 46 und -1 für 45.

Nach Änderung von 0 auf -1 in der group Tabelle wird diese Kategorie angezeigt.
Die Tabelle user scheint hier nichts weiter zu bewirken, habe aber trotzdem die beiden 0-Werte auch auf -1 gesetzt.
-1 heißt wohl "alle" oder so.

Nur, wie kann ich dieses Problem jetzt für künftige Hinzufügungen vermeiden? Ich will ja nicht jedesmal in die Tabelle schauen und das korrigieren. Was ist da beim Upgrade schiefgelaufen? In der User-Verwaltung sehe ich überhaupt keine "Gruppe". Auch beim Hinzufügen der Kategorien sehe ich keine Gruppe.

Nachtrag
-1 ist anonymous, alles klar, findet sich in faquser. Meine faqgroup-Tabelle ist aber leer und m.E. brauche ich auch keine Gruppen. Könnte auch gar keine anlegen. faquser_group-Tabelle ist ebenfalls leer.

[kai]

Hier noch ne kleine Änderung, die ich nach Update auf 2.0.12 vornehmen musste. Schlage Hinzufügung von

wow
WoW
WOW
gold
Gold
GOLD
Chinese
chinese
warcraft
Warcraft

zu blockedword.txt vor.

Unsere chinesischen Freunde waren innerhalb weniger Tage wieder flott dabei ...

[Thorsten]

Hi Kai,

Ja, kennst du ein anderes PHP, das noch unterstützt wird?

Oh, ja, tue ich. Jede vernünftige Enterprise-Distribution unterstützt eine bestimmte PHP-Version, die von Anfang an dabei ist. Security Fixes und andere Bug Fixes werden dann "backported". Wir benutzen z.B. CentOS 5 (z.Z. 5.2). Das kommt mit PHP 5.1.6 und wird bis 2014 unterstützt. Und es gibt keinen Grund, damit nicht bis dahin zu laufen. Bisher habe ich auch noch keine Probleme mit dem 5.1.6 entdeckt. Genauso läuft bei uns noch CentOS 4 (momentan in der Version 4.7) mit PHP 4.4.3 (wenn ich mich recht erinnere). Ähnlich ist es bei Suse-Enterprise. Und so ähnlich siehst du das bei fast allen Providern und vielen Firmen, besonders größeren. Wer sich das neueste Fedora, Suse oder Ubuntu draufpackt, sind vor allem Privatuser mit Rootserver. Diese Privatdistributionen werden i.d.R. viel zu kurz mit Sicherheitspatches bedacht und was glaubst du wohl, welche Distributionen da regelmäßig gehackt werden? Ja, genau diese. Denn irgendwann gibt's keine Sicherheitsupdates mehr, aber der User scheut das Inplace-Upgrade auf eine komplett neue major-Version.

Das ist mit der 2.5+ auch besser machbar, da kann man dann Blöcke in den Templates definieren...

Tja, wenn es denn mit 5.1.6 laufen würde. Ich könnte zwar auf 5.2.irgendwas per CentOSPlus upgraden, aber sehe ehrlich gesagt keine Veranlassung dazu, da 5.1.6 eben perfekt läuft und sicherheitsmäßig unterstützt wird, worauf ich mich bei dem 5.2.irgendwas nicht so ganz verlassen kann.

ich kenne diese Problematik. Bei mir in der Arbeit habe ich auch Kunden, die noch Red Hat Enterprise Linux 3 und 4 verwenden... Die Lösung ist einfach, PHP selber zu kompilieren. Das ist eh immer das beste, da die Distros leider immer mal wieder fiese Bugs in PHP einbauen, siehe zB diesen Blogeintrag: http://derickrethans.nl

phpMyFAQ 2.5 kann sicher auch mit einem PHP 5.1.6 aus CentOS laufen, wenn einige PECL-Module mit einkompiliert werden. Die nötigen Module, die in PHP 5.2 im Core sind und in 5.1 noch nicht, liste ich hier auf.

Ich kann dich verstehen, dass du gerne das PHP-Paket aus der Distro verwenden willst, aber ich möchte gerne phpMyFAQ auf eine modernere Basis stellen und benötige daher PHP 5.2, auch für zukünftige Versionen, die dann schneller freigegeben werden können.

Was ich dir anbieten kann, ist dich dabei zu unterstützen.

Nur, wie kann ich dieses Problem jetzt für künftige Hinzufügungen vermeiden? Ich will ja nicht jedesmal in die Tabelle schauen und das korrigieren. Was ist da beim Upgrade schiefgelaufen? In der User-Verwaltung sehe ich überhaupt keine "Gruppe". Auch beim Hinzufügen der Kategorien sehe ich keine Gruppe.

Ich schaue mir diese Problematik an, warum das bei dir plötzlich passiert. Die faqgroups brauchst du nicht, wenn du keine Gruppen hast.

bye
Thorsten