Gesammelte Ideen ...

[OcassionalUser]

Guten Morgen !

Ich bin vor kurzem auf phpMyFAQ aufmerksam geworden, weil ich mich über
versch. FAQ-Systeme informieren musste, um eine private FAQ zu realisieren.
Soweit hat mir phpMyFAQ eigentlich ganz gut gefallen - schön kompakt und
ausgesprochen einfach zu installieren und auch ansonsten kein echter
Overkill, wie es bei manchen anderne Systemen der Fall ist.
Dennoch sind mir persönlich ein paar Dinge aufgefallen, die ich
teilweise für verbesserungswürdig erachte - und obwohl sicherlich nicht
alle Vorschläge unbedingt sinnvoll sind, so wären einige sicherlich
ganz unproblematisch in der Umsetzung und würden die Benutzbarkeit
noch verbessern.


"Offene Fragen"

Beim Einrichten meiner FAQ hätte ich es außerdem
praktisch gefunden, wenn ich als Administrator
die Möglichkeit gehabt hätte, nicht nur direkt
vollständige Beiträge mit Frage/Antwort
hinzuzufügen, sondern halt auch ganz normal
offene Fragen, die dann von der User-Community
beantwortet werden sollen.
Da es diese Funktion so nicht gab, musste ich
für jede einzelne offene Frage, den manuellen
Weg gehen. - bis ich mir dann dafür ein Script
gebastelt habe.

-
Administration und Feedback

Beim Administrieren wäre es praktikabel, wenn
man nach einer erfolgreich durchgeführten Aktion
nicht nur die Statusmeldung erhalten würde,
sondern auch in die Funktion zurückspringen
würde, wo man zuletzt gearbeitet hat.
Es ist schließlich recht naheliegend, dass man
wenn man eine Kategorie hinzugefügt hat, unter
Umständen noch eine weitere hinzufügen will -
das spart Zeit und liegt auf der Hand.

-
Optionale Angabe von eMail-Adresse

Optionale Angabe von eMail-Adresse - anstatt
bei jeder neuen Frage eine korrekte eMail
Adresse zu erwarten. Könnte man doch
problemlos als Option einbauen, dass eine
eMail Adresse kein Muss ist. Ebenso ist manchmal
auch die Angabe eines User-Namens nicht zwingend
erforderlich - ggf. könnte man das ja auf bestimmte
Kategorien beschränken, sozusagen eine Property
für jede Kategorie, ob das Posten ohne Angabe von
mail/user zulässig sein soll oder nicht.


Desweiteren ist mir auch aufgefallen, was bereits
in Eurem Forum zu lesen ist - die Sache mit
der Prüfung auf MX-Record scheint unter Linux
zwar zu funktionieren aber die DNSErr-Funktion
gibt immer einen Fehlwert unter Windows
zurück - zumindest unter bestimmten php-Configs.
Deswegen wäre es ganz sinnvoll, wenn man die
Sache konfigurationstechnisch ganz abstellen könnte.

-
Kategorien verschieben

Das steht auch schon in Eurem Forum - aber das
Verschieben scheint wirklich nicht ganz so zu
funktionieren, wie man es erwarten würde.
Bequemer wäre eine Möglichkeit, einen Item/eine
Kategorie mittels Checkbox auszuwählen und
dann gezielt an eine bestimmte Stelle zu verschieben-
mitsamt allen untergeordneten Items -
möglicherweise via Combo-Box. Denn die aktuelle
Funktionsweise ist extrem frustrierend und zeitaufwendig
bei verschachtelten Kategorien.

-
Verschieben zwischen faqdata und faqfragen

Beim Erstellen meiner FAQ hätte ich es persönlich
extrem praktisch gefunden, wenn es die Möglichkeit
gegeben hätte, unter faqdata liegende Fragen
ggf. auch als "offene" Fragen zu markieren -
um Ergänzungen von Usern zu bereits beantworteten Fragen zu kriegen.
Aber leider scheint das "entweder/oder" zu sein -
entweder es handelt sich um eine offene Frage,
die noch beantwortet werden muss, oder aber eine
Frage aus der FAQ.

Wenn ich dagegen mehrere Vorschläge für die
Beantwortung ein und derselben offenen Frage erhalten habe,
wäre es ausgesprochen praktisch, wenn
die versch. Antworten entsprechend kategorisiert
werden bzw. wenn ich mehrere Antworten
ausschnittweise direkt miteinander verknüpfen könnte


-
Mailing-Funktionen

Das Script scheint einfach per Default Mails
versenden zu wollen und auch die entsprechenden
Community-Funktionen freigeschaltet zu haben -
es wäre begrüßenswert, wenn der Admin eine
Möglichkeit hätte, diese Funktionalität im
Menu zu beschränken, bzw. ganz zu deaktivieren.
Das wäre schon allein für die diversen Hosts sinnvoll,
wo sendmail wegen der Spam-Problematik deaktiviert wurde.

-
Ãœbersichtsseite

Die Ãœbersichtsseite sollte ein paar grundlegende
Funktionen ermöglichen auch ohne immer erst die
Detailseite für einzelne Fragen öffnen zu müssen
- das Löschen einer Frage sollte nicht unbedingt
das Öffnen der Frage erfordern - das könnte man
ja mit einem verlinkten Symbol deutlich vereinfachen.

Ein "Preview" Link wäre auch ganz
praktikabel wenn es nur um eine Vorschau geht.

Hilfreich wäre vielleicht auch eine optionale Angabe der
Größe in KByte einzelner Einträge.

-
Offene Fragen und FAQ

Eine Frage sollte auch dann noch als "offen"
gelten können, wenn sie bereits in die FAQ
aufgenommen worden ist. Ich habe den Source
entsprechend angepasst - aber wäre vielleicht
generell ganz nützlich ?

-
Kommentare und FAQ

Es sollte eine Option geben, automatisch bestimmte
Kommentare mit in die eigentlich FAQ aufzunehmen.
Auf die Art und Weise könnten relevante Kommentare
gleichzeitig Antworten sein, die in der FAQ
angezeigt werden.

-
News

Es sollte eine Möglichkeit geben, ein Preview
der News anzuzeigen.
-
Kategorien & Offene Fragen

Als Admin sollte man dazu in der Lage sein, problemlos
die gewählte Kategorie von "offenen Fragen" zu
ändern - ohne automatisch gleich die Frage von
"faqfragen" nach "faqdata" verschieben zu müssen.

Außerdem sollte es als Admin möglich sein, textuelle
Veränderungen an geposteten (offenen= Fragen vorzunehmen-
z.B. um Korrekturen vorzunehmen. Und das ohne gleich
die Frage beantworten zu müssen.

-
Fragen/Einträge und EINE Kategorie

Es wäre wünschenswert, wenn es möglich wäre,
bestimmte Einträge in mehreren Kategorien
parallel erscheinen zu lassen. Eine Restriktion
auf nur eine einzige Kategorie ist eher hinderlich.
Ebenso wäre es ganz schön, wenn man etwas intuitiver
die FAQ untereinander verlinken könnte - z.B.
mittels Combo-Boxen die Kategorie bzw. den Eintrag
auswählen und so verlinken.
Diesbezüglich wären Anchors in den Einträgen
auch ganz nützlich.


-
Preview bei "Neueintrag"

Ein "back" auf der Preview-Seite setzt in vielen
Fällen das vorherige Formular vollständig zurück -
störend :-/

-
Attachment/File Storage

Auch wenn es meistens nicht unbedingt sinnvoll ist:
wie wäre es mit einer Option, Dateien INNERHAB
der mySQL-DB abzulegen ?
-

OFFENE Fragen anzeigen:

Offene Fragen sollten nach Kategorien sortiert werden können -
bzw. mit eine Checkbox nur bestimmte offene Fragen (bestimmte Kategorien/Stichworte)
angezeigt bekommen - denn sonst wird es bei mehr als 100 unbeantworteten Fragen
recht schnell unübersichtlich - und wenn ich als User weiß, dass ich z.B.
nur Fragen zum Thema "PHP" beantworten kann/will, dann brauche ich die ja
nicht unbedingt manuell raussuchen, sondern kann entweder spezifizieren,
nur offene Fragen der Kategorie "PHP" angezeigt zu bekommen - bzw. lediglich
offene Fragen wo das Stichwort "PHP" enthalten ist.


Ich kann jetzt nicht sagen, wieviele meiner Ideen sinnvoll sind -
einige Sachen habe ich selbst schon gefixt, damit es mit meinen
Anforderungen stimmt - falls jemand an den Änderungen interessiert
ist, einfach bescheid geben.


Keep the good work goin' !

[Thorsten]

Hi O.,

ich habe mir mal alle deine Vorschläge und Ideen notiert. Ein Großteil ist dabei sehr sinnvoll und wird demnächst in der 2.0er realisiert.

bye
Thorsten

[OcassionalUser]

So, guten Morgen !

Ich habe mir gerade gestern die aktuellste Version runtergeladen und auch mal installiert
und da sind mir noch ein paar Dinge aufgefallen die entweder "komisch" sind oder aber als
nützliche Erweiterung scheinen.

Als Admin wäre es ganz praktisch wenn man beim Einrichten von Benutzern bestimmte Benutzer
ggf. auch nur auf bestimmte Bereiche innerhalb der FAQ (Kategorien) beschränken könnte.
Wenn ich also zwei versch. Kategorien "Motorsport" und "Kochen" habe, dann braucht der
"Moderator" der "Motorsport"-FAQ ja nicht unbedingt auch Zugriff auf "Kochen" zu haben,
ist aber nur so eine Idee gewesen und was mich angeht nicht wirklich dringlich.


Beim Erstellen/Editieren von Beiträgen kann man als Admin ja Suchbegriffe/Keywords für
die Suchmaschine definieren, ich denke es wäre oft ganz nützlich wenn man nicht nur für
einzelne Beiträge bestimmte Suchbegriffe angebenen könnte, sondern tatsächlich auch
für einzelne Kategorien - sprich: so dass man "Default-Keywords" für die Gruppe
"Motorsport" hat, ohne dass diese Keywords explizit Erwähnung finden müssen in den
Beiträgen etc.
Insofern wäre es ganz praktisch wenn man zusätzlich zur herkömmlichen Keyword-Funktionalität
einfach "Keyword-Profile" erstellen könnte, wie jetzt z.B.

"Motorrad, Helm, Bekleidung"

und dieses "Keyword-Profil" dann entweder einer bestimmten Kategorie INSGESAMT -
also z.B. der Kategorie "Motorsport"- zuordnen könnte ODER ABER auch einfach diese
Profile mittels Option-Boxes verfügbar hat wenn man neue Beiträge editiert/erstellt,
so kann man vordefinierte Themen-Bereiche mit Keywords erfassen und parallel verschiedenen
Beiträgen dieselben Keywords zuordnen ohne das alles manuell machen zu müssen.



Was ich mir zwischendurch gebastelt habe für die Admin-Seite ist einfach ein "Quick-Jump" mittels
einer Combo-Box um bei Kategorien die mehrere Seiten umfassen, schnell zu einer bestimmten
Kategorie mit ihren Beiträgen springen zu können

Ist beim Erstellen von Beiträgen eigentlich schon ein einfacher Weg vorgesehen, Bilder
hochzuladen und mit dem Beitrag zu verlinken ?


Die Benutzersprache sollte nicht fest im Menu bestimmt werden sondern vielmehr eine Art
Default-Sprache, die man als User dann einfach mittels Combo-Box dann noch wechseln kann.

Genauso wäre es praktisch wenn man auf der Seite mit den Offenen Fragen die Fragen nach
Kriterien sortiert ausgeben könnte, also nicht nur wie ich weiter oben schon schrieb
nach den Kategorien sortiert, sondern ggf. auch nach dem Kriterium "nur neueste Beiträge anzeigen"
bzw. "Nur Beiträge in Sprache XYZ"

Benutzersprache sollte auch für brwoser wählbar sein
Und Ansicht nach Sprachen beiträgen

Wenn die Angabe einer eMail-Adresse optional ist, sollten die Ausgabe-Scripte nicht automatisch
leere Mailto: Links zusammen setzen


Wenn man eine Kategorie gelöscht hat, tauchen die Beiträge dann ja "kategorie-los" auf und
nur mit ihrer ID - Es wäre praktisch wenn man als Admin sich direkt die "nicht zugeordneten Beiträge"
ansehen könnte ohne sich erst durch mehrere Seiten klicken zu müssen. Eine Kleinigkeit ist
dann sicher auch "Nicht zugeordnete Beiträge" statt nur "ID" für diese Beiträge anzuzeigen :-)


Bei meine FAQ ist es so, dass es vorkommt, dass Beiträge vorgeschlagen werden, die bis zu
dem Zeitpunkt in keine der vorhandenen Kategorien passen, ich habe mir da eine Kleinigkeit
gebastelt um in der Select-Box dann auch auswählen zu können "Neue Kategorie für diesen Beitrag vorschlagen",
werde das noch koppeln an eine weitere Box mit "Als Sub-Kategorie von ..."
Vielleicht ist das generell keine schlechte Idee ? Keine Ahnung wer das sonst noch gebrauchen
könnte, aber falls ein User keine passende Kategorie für seinen Beitrag findet sollte es
eine Default-Kategorie für diese Beiträge geben, die dann auch dem Admin gesondert angezeigt werden
können. Natürlich ist es einfach, sich einfach eine entsprechende Kategorie namens "[Keine Kategorie]"
zu erzeugen, aber wenn man das etwas ausbaut und tatsächlich wie oben beschrieben an ein
"Neue Kategorie vorschlagen" koppelt, dann kann der Admin so auf einer eigenen Seite die Beiträge
einsehen die in keine der herkömmlichen Kategorien passen, für die es aber Kategorie-Vorschläge gibt,
mit einem einfachen "Approve"-Link auf den Vorschlag könnte der Admin mit einem einzigen Handgriff
die entsprechende Kategorie erzeugen und den Beitrag dorthin verschieben.


Gibt es eine einfache Möglichkeit,die PDF-Tempates anzupassen ? Man könnte ja wenigstens 3-5
Kriterien für die PDF-Erzeugung und das Layout im Admin-Interface zur Verfügung stellen, so
dass man problemlos darauf Einluss nehmen kann. Auch wäre es praktisch, Optionen wie die
PDF-Erzeugung deaktivieren zu können bzw. zu parameterisieren, so dass z.B. bei mehr als
xx MB erzeugter PDFs die am wenigsten abgefragten PDFs gelöscht werden damit nicht unnötig
Platz verschwendet wird.
Es wäre auch praktisch wenn man als Admin/Mod den XML-Export entweder global oder aber für bestimmte
Beiträge deaktivieren könnte.

Und für die Leute die überhaupt keinen Peil von HTML & Co haben, wäre es vielleicht ganz
nett wenn man auf ein paar basics die Auswirkungen auf das Layout haben, über das Admin-Interface
Einfluss nehmen könnte. Eine Sache die mir z.B. gleich am Anfang aufgefallen ist: die
Spaltenbreite für das Menu links sollte entweder dynamisch wachsen mit der Länge der Strings oder
aber einfach aus dem Menu einstellbar sein. Ggf. könnte sich aber tatsächlich die Breite der
Spalte in Maßen mit den Anforderungen anpassen, wenn ich drei Haupt-Kategorien

- ABC
- DEF
- HIJ

habe, brauche ich ja meistens keine besonders breiten Spalten, wenn ich nun aber eine
Kategorie öffne

- ABC
=> Eine laaange Unterkategorie

Dann wäre es praktisch wenn man angeben könnte ob die Unterkategorie umgebrochen werden soll
in der schmalen Spalte oder aber die Spalte mit der Länge der Kategorienbezeichung
wachsen soll.
Denn das Umbrechen sieht teilweise nicht nur nicht gut aus, sondern sorgt auch für Unordnung
und einen Mangel an Ãœbersicht.


Das wäre wirklich ganz praktisch denke ich, abgesehen davon könnte man natürlich wirklich
auf die eine oder andere Sache im Layout recht einfach Einfluss nehmen, wenn Dinge wie die
Hintergrundfarben bzw, das CSS nicht fest im Template stünden sondern dynamisch aus der DB
gelesen werden würden und somit vom Admin leicht veränderbar wären.

Auf die Art und Weise könnte man auch einfache Format-Regeln für die Strings im Menu bzw.
die Unterkategorien definieren.

Hmm, irgendwo hatte ich NOCH einen kleinen Zettel mit Notizen, ich erinnere mich da jetzt nur an
eine Sache: da scheint ein Problem beim Parser zu sein wenn man einen Beitrag erstellt, wo ein
QUOTE Tag auf ein URL Tag folgt, dann wird der quote-tag einfach angezeigt statt richtig umgesetzt?

Ich hatte schon ein paar kleinere Anpassungen für mich privat an der alten Version vorgenommen,
ich werde diese nun die nächsten Tage mal in die neue Version einarbeiten. Gibt es eigentlich
irgendwo "Richtlinien", also bezogen auf naming conventions etc. ?
Weil ich könnte mir vorstellen, dass Ihr die eine oder Sache so übernehmen könntet - schlussendlich
wär's ja nur eine weitere Option, die im Menu deaktivierbar ist und die niemanden nervt wenn
sie deaktiviert ist. Nur ist das ja alles Euer Source und der sieht mit Sicherheit nicht mehr
so elegant aus, wenn ich drin rumgepfuscht habe ;-)
Darauf bezogen, wäre es natürlich super genial, wenn man langfristig gesehen tatsächlich
eine Art "Plugin-Interface" benutzen würde, um 3rd Party Module einbinden zu können: dann
braucht auch niemand mehr direkt im Source rumzumachen.


Also dann ein schönes Wochenende !

Und noch mal besten Dank für dieses wirklich geniale FAQ-System !!

[OcassionalUser]

Guten Abend !

Sorry, dass ich schon wieder schreibe ;-)

Was mir gerade beim PDF-Export aufgefallen ist: HTML-Entitäten aus einem Beitrag der FAQ scheinen bei der Umwandlung nach PDF nicht korrekt in ihre ASCII-Äquivalente konvertiert zu werden.

Und nachdem ja sowieso jede Seite einen grauen Kasten um die Überschrift hat, wäre es vielleicht nicht schlecht wenn die Quote-Tags aus den Beiträgen ebenso im PDF-Pendant mit einem grauen Kasten gezeigt werden. Sonst steht da einfach nur "quote" und man weiß nicht,wo das Quote aufhört. Man könnte ja einen Kasten mit entsprechend dünnerer Linienstärke ziehen.


Beim Löschen einer offenen Frage als Admin sollte es vielleicht noch vorher eine Abfrage geben, ob man WIRKLICH löschen will - ggf. sogar mit Anzeige der Beiträge, die dann "frei" hängen und keiner Kategorie mehr zugeordnet wären- vielleicht sogar gleichzeitig mit Möglichkeit, diese Beiträge dann anderen/neuen Kategorien zuzuordnen.

Als User, wenigstens aber als Admin wäre es praktisch wenn man die Möglichkeit hätte, optional die Anzahl der Beiträge in einer Kategorie und ihren Unterkategorien mit anzuzeigen, könnte man ja optional immer in Klammern dahinter packen.

Wie wäre es wenn man Kategorien nicht nur löschen könnte sondern auch "unsichtbar" bzw. "deaktivieren" könnte ? Keine Ahnung, ob sonst noch jemand sowas sinnvoll findet ?
Aber so könnte man schon mit Kategorien arbeiten und welche erstellen, ohne dass diese direkt für jeden User sichtbar sind. Erst wenn die Arbeite abgeschlossen sind, würde man die entsprechenden Kategorien "freischalten".

Ich habe mir den Source für das tag-parsing jetzt nicht weiter angesehen, fände es aber ganz praktisch wenn man ein paar simple table-tags zur Verfügung hätte. Einfach um auf die Formatierung etwas stärkeren Einfluss nehmen zu können.
Werde das gleich mal ausprobieren, es würden ja wirklich schon ein paar ganz einfache Funktionen vollkommen ausreichen, man bräuchte ja wirklich nicht die gesamte Funktionalität von <table> umzusetzen.


Beim Durchsuchen meiner FAQ habe ich festgestellt, dass hin und wieder die Link-Beschriftungen ziwschen den url tags scheinbar nicht berücksichtigt werden ? Nach welchen Kriterien läuft das ab ?

Beim Löschen einer Kategorie wäre es vielleicht ganz sinnvoll wenn man dann sicherheitshalber auch noch mal den Namen der Kategorie angezeigt bekäme, die gelöscht werden soll.

Wie wäre es außerdem wenn man optional beim Erstellen von Kategorien einen String abfragen würde, der die entsprechende Kategorie beschreibt ?
Ich könnte mir vorstellen, das wäre ganz nützlich vor allem wenn man mehrere Unterkategorien mit derselben oder einer ähnlichen Beschriftung hat, so könnte eine Beschreibung ergänzend unter/neben der Kategorie angzeigt werden.
Je nachdem ob das Menu nachher noch dynamisch mit JavaScript erweitert wird, könnte man diese Kurzbeschreibungen dann auch als ToolTips anzeigen.

Für Leute die die FAQ mehrsprachig halten wollen, wäre es ganz nützlich wenn man nicht nur wie weiter oben beschrieben eine Auswahlbox für die Sprache hätte, sondern auch die Möglichkeit alle Kategorien in eine andere Sprache zu übersetzen, so dass bei Auswahl von "english" die Übersetzungen angezeigt werden.


Gut gefallen hat mir auch, dass die Hyperlinks aus der FAQ im PDF-Export ebenfalls umgesetzt werden - es wäre da auch schön wenn innerhalb der PDF-Datei Hyperlinks benutzt werden könnten - vielleicht sogar mit einem Index auf Basis der tatsächlichen Struktur aller Kategorien ? Dann hätte man tatsächlich eine 1:1 Kopie inklusive der Struktur.

Bei den nach PDF exportierten Beiträgen ist mir aufgefallen, dass Bilder in Beiträgen die nicht lokal verlinkt sind sondern auf externe Quellen verweisen, nicht umgewandelt werden - vermutlich weil sie vom Script nicht vorher runtergeladen werden. Insofern müsste man die IMG-Tags nur parsen und alle Images in ein temporäres Verzeichnis runterladen und dann mit diesen Bildern die PDF-Datei(en) erzeugen, anschliessend können diese ja wieder gelöscht werden.
Das sollte aber dann wahrscheinlich an eine definierbare Maximalgröße der Bilder gebunden werden, damit das Script nicht im Hintergrund versucht, ein 2 MB Bild runterzuladen ;-)

wäre vielleicht langfristig auch ganz nett wenn die Font-Formatierungen bzw. BB-Codes ansatzweise auch in das PDF-Pendant der FAQ konvertiert werden würden.... aber das ist kosmetisch.
Mit einem entsprechenden PDF-Template könnte man solche Dinge ja größtenteils selbst regeln.



Sind jetzt alles nur ein paar Ideen - und mehr zu statistischen Zwecken, für den Fall, dass auch andere User ähnliche Features vorgeschlagen haben und die tatsächliche Umsetzung davon abhängig gemacht wird ...

Kleinigkeiten, die ich selbst für sinnvoll erachte habe ich selbst schon umgesetzt: nur leider wird jedes Update zu einem echten Problem wenn man schon selbst überall die Finger drin hatte ;-)

Schönes WE !

[Thorsten]

Hi,

ich schreibe mir die nächsten Tage das alles mal zusammen und setze sinnvolles in meine TODO-Liste.

bye
Thorsten

[OcassionalUser]

Hi !

Ich habe inzwischen die meisten Änderungen aus meiner alten Version auch auf die neueste
übertragen, und auch wenn wahrscheinlich nicht jeder jedes Feature braucht, wollte ich mal
ganz generell fragen, wie es mit der Chance steht, dass ich den Source hier poste und ihr
den vielleicht offiziell einbaut ? Wäre natürlich wirklich praktikabler, wenn man das irgendwie
auf Plugin-Basis machen könnte ... Mir ist schon klar, dass meine Veränderungen an der DB-Struktur
wahrscheinlich nicht sehr beliebt sind, aber die eine oder andere Sache könnt ihr ja vielleicht dennoch gebrauchen ?

Hier ein paar der Änderungen, die ich vorgenommen habe:

• Im Admin-Interface die Verwaltungsseite umgestellt auf combo-boxes (select/option),
  ist nun etwas übersichtlicher, zusätzlich mit den Features "verschieben nach"/"verstecken".
• In der Tabelle faqrubrik habe ich zusätzlich ein Feld namens "lang" hinzugefügt, das
  dazu dienen soll, dass man als Benutzer zwischen den Sprachen umschalten kann und sich
  damit auch die Beschriftung der Kategorien ändert. Außerdem habe ich in derselben Tabelle
  ein Feld "description" hinzugefügt, das mittels eines Textfeldes auf der Admin-Seite
  "categories.php" mit Inhalten gefüllt werden kann. Diese Beschreibungen für die Kategorien
  werden jetzt als Tooltips mittels "title" im Link bzw. mit einem <div> ausgegeben.
  Das ist ganz praktisch: vor allem bei längeren Beschriftungen oder auch um ggf.zusätzliche
  Details bei gleichnamigen Unterkategorien anzuzeigen.
• Außerdem habe ich der Tabelle faqrubrik ein Feld "visible" hinzugefügt (SET y/n), um
  so ggf. im Admin-Menu Kategorien mitsamt ihren Beiträgen für normale User unsichtbar
  machen/deaktiveren zu können. In der categories.php habe ich zudem eine Möglichkeit
  vorgesehen, optional den Visible-Status alle Unterkategorien einer (un-)sichtbaren
  Kategorie ebenfalls zu ändern: so muss man bei einer gesperrten Hauptkategorie nicht
  alle Unterkategorien einzeln sichtbar/unsichtbar machen wenn der Status Hauptkategorie
  geändert wird.
• Alle relevanten SQL-Statements im Source habe ich ebenfalls erweitert um ein
  "WHERE faqrubrik.visible='y'" damit nur sichtbare Kategorien/Beiträge angezeigt werden.
• Außerdem habe ich das Betrachten der offenen Fragen so erweitert, dass jetzt mittels eines
  Auswahlmenüs die Kategorie ausgewählt werden kann, deren Unterkategorien/Beiträge angezeigt
  werden sollen - hier ebenfalls mit Überprüfung auf visible='y'.
• Die eigentliche Ausgabe der Such-Ergebnisse in den offfenen Fragen habe ich jetzt so verlinkt,
  dass jede Unterkategorie einen eigenen Anchor verpasst kriegt, der identisch mit dem Zahlenwert
  aus faqrubrik.rubrik ist: oberhalb der Suchergebnisse wird dann eine Tabelle mit
  beschrifteten Links aus faqrubrik.titel ausgegeben die zu den Anchors auf der Seite verlinkt,
  an der Stelle wo der Anchor eingebaut ist, befindet sich dann eine Zeile in der noch mal
  faqrubrik.titel und mein zusätzliches Feld faqrubrik.description ausgelesen werden.
  (will die nächsten Tage das noch so ändern, dass man eine Anzahl von max. Treffern/Seite
  beim Suchen angeben kann)
• Außerdem habe ich "Offene Fragen" so erweitert, dass man sich ggf. nur Fragen in einer bestimmten
  Sprache anzeigen lassen kann, dazu hat faqfragen noch das Feld "lang" bekommen.
• Nachdem es ja schon eine Top10-Themen und Top5-Neueste Themen gibt, habe ich zusätzlich noch
  eine kleine Funktion eingebaut, die parametrisiert die x neuesten Fragen in einer Tabelle
  ausgibt. So kann man wenn man auf die Seite kommt sofort sehen,ob es neue Fragen gibt und wie sie
  lauten. Die Tabellenspalte habe ich mit einem div unterlegt, so dass auch alle Ober-Kategorien
  der Frage angezeigt werden. Wenn man mit der Maus über das Tabellenfeld geht, so sieht man im
  ToolTip also automatisch, in welcher Unter-Kategorie die Frage gestellt wurde. Dazu habe ich
  eine Funktion getTopLevelCats geschrieben, die mittels SQL-Abfrage in einer Schleife jeweils die
  Oberkategorien einer Kategorie raussucht und dann nachher alle Oberkategorien als Array
  zurückgibt.

  Code: Select all

  function GetTopLevels($rubrik)
  {
  for ($counter=strlen($rubrik);
  	$counter>=0;
  	$counter=$counter-3)
  	{
  	$sql="	SELECT  ".$sqltblpre."faqrubrik.titel 
  		FROM 	".$sqltblpre."faqrubrik, ".$sqltblpre."faqfragen
  		WHERE ".$sqltblpre."faqrubrik.visible =  'y' AND
  		".$sqltblpre."faqrubrik.rubrik=	LEFT ('".$rubrik."','".$counter."')";
  
  	$topid=$db->query($sql);
  	$toplevel[]= $db->fetch_row($topid);
  
  }
  return $toplevel;
  }

• Die eigentliche Frage hast du ja mit "makeShortText" abgekürzt, ich habe die Funktionen für die Ausgabe der Top5/10/..
  so erweitert, dasss zusätzlich zu der gekürzten Version der Frage/des Themas auch noch die
  vollständige Frage mittels "title" bzw. div-text eingeblendet wird wenn man über die gekürzte
  Version fährt.
  So braucht man gar nicht erst auf die Frage zu klicken um sie komplett lesen zu können.Müsste man vielleicht noch auf 1 kbyte oder so begrenzen ...
• "Frage stellen" habe ich so erweitert, dass man schon beim Stellen einer Frage angeben kann,
  in welcher Sprache sie gestellt wird, so dass die Suchfunktion dann ggf. auch nach Sprache
  sortiert die offenen Fragen ausgeben kann.
• Im Administrationsinterface habe ich wie gesagt auch die Kategorienverwaltung etwas überarbeitet,
  eine Kleinigkeit die ich persönlich ganz nützlich fand ist die Erweiterung, dass ein kleines
  "NEW"-Logo angezeigt wird wenn es neue zu genehmigende Fragen gibt die noch nicht aktiviert
  oder vom Admin betrachtet worden sind. Um feststellen zu können, ob ein Admin/Moderator sich
  den Vorschlag für die FAQ schon angesehen hat, habe ich außerdem der Tabelle faqdata ein Feld
  "viewed_by_admin" mit set y/n hinzugefügt.
  So sieht man als Admin/Mod immer gleich, ob es neue Beiträge gibt die beantwortet werden müssen.
  Zusätzlich habe ich in der Verlinkung auf die Kategorienverwaltung noch die Anzahl der auf
  Genehmigung wartenden Vorschläge ausgelesen und angezeigt.
• Dann habe ich die Kommentar-Funktionalität noch dahingehend erweitert, dass jeder User
  möglicherweise unpassende Kommentare an den Admin/Moderator melden kann, so dass diese
  dann im Administrationsinterface auftauchen und ggf. gleich gelöscht ODER editiert(zensiert) werden
  können.
  Zu diesem Zwecke hat die Tabelle faqcomments auch noch von mir das Feld "inform_admin" set y/n
  verpasst bekommen.
  In Funktion generateComments habe ich entsprechend einen kleinen Image-Link hinzugefügt, der
  es ermöglicht, einen Kommentar dem Admin zu melden. Auf der folgenden Seite reportcomment.php
  kann man dann 2/3 Gründe auswählen, weshalb ein Kommentar gemeldet wurde-optional noch eine
  kurze Bemerkung und natürlich Benutzername/eMail-Adresse.
  Bei einer der drei zur Auswahl stehenden Gründe für die Benachrichtigung an den Admin
  habe ich "unpassender Kommentar" stehen, wenn dieser ausgewählt wird, dann wird das zusätzlich
  in der Tabelle erzeugte Feld "visible" (set y/n) automatisch auf 'n' gesetzt, damit möglicherweise
  beleidigende Kommentare gesperrt werden und nicht länger sichtbar sind.
  Im Admin-Menu unter "Kommentarverwaltung" steht dieser Eintrag dann als gesperrter Kommentar.
• Außerdem habe ich Volltextsuche dahingehend erweitert, dass man sich optional auch offene Fragen
  mit den entsprechenden Stichworten anzeigen lassen kann. Ein Auswahlmenu mit den Sprachen die
  in faqdata Verwendung finden, zeigt zudem an, wenn Beiträge in mehr als einer Sprache vorhanden
  sind, so kann man gezielt nach Beiträgen in einer bestimmten Sprache suchen. Eine Checkbox
  ermöglicht es, zusätzlich auch Kommentare aus faqcomments nach den Stichworten aus der Suchmaske
  zu durchsuchen. Man kann jetzt auch auswählen, ob man alphabetisch nach Thema/Unterkategorie oder
  Eintragsdatum sortieren möchte.
• Bei der Suchmaske für "offene Fragen" habe ich zudem eine Checkbox eingebaut, die es ermöglicht,
  nur solche offenen Fragen anzuzeigen für die es noch keine Beantwortungsvorschläge beim Admin
  gibt: so kann man ggf. doppelte Antworten vermeiden.
• Eine größere Änderung, die ich vorgenommen habe, bezieht sich auf die Möglichkeit, dass User
  untereinander sich gegenseitig um Übersetzung eines Themas/einer Frage bitten können,aber auch
  selbständig eine Frage übersetzen können. Dazu wird im Grunde nur eine abgeänderte Version der
  add.php mitsamt template ausgegeben, wo der Originalbeitrag als 'readonly' in einer textarea
  eingetragen ist und ein User somit auf Basis des Originalbeitrags eine Ãœbersetzung in einer
  Sprache anfertigen kann, die er selbst auswählt. Die Übersetzungen landen dann erstmal ganz
  normal in der "zu genehmigende Beiträge" beim Admin. Ausserdem können in diesem Zusammenhang
  auch die Kategorie-Bezeichnungen übersetzt werden, so dass in der faqrubrik dann eine neue
  Kategorie mit demselben Feldwerten faqrubrik.rubrik erzeugt wird,wo aber dann entsprechend
  faqrubrik.titel und faqrubrik.lang angepasst werden.
  In der artikel.php habe ich Änderungen dahingehend vorgenommen, dass mittels zwei Flaggen-Symbolen
  ein Artikel entweder wie gerade beschrieben wurde, direkt übersetzt werden kann von einem User,
  oder aber dass ein User einen Ãœbersetzungs-Request abgeben kann, dazu gibt's jetzt in meiner
  Tabelle faqdata ausserdem noch das Feld 'request_translation', das vorerst vom Typ varchar(64) ist,
  und wo dann die Sprachrequests komma-separiert wie bei CSVs reinkommen.
  Wenn ein User nun einen Artikel aufruft, für den es Übersetzungs-Anfragen/Bitten gibt, so wird
  darauf direkt unter der Ãœberschrift hingewiesen und so verlinkt, dass dieser User den Beitrag
  übersetzen kann.

Das waren jetzt erstmal nur ein paar der größeren oder auch nur praktischen Änderungen, die
ich vorgenommen habe. Ich plane noch ein paar andere Erweiterungen: aber so bald werde ich dann
wohl erst mal nicht wieder updaten ;-)


Vielleicht könnt ihr ja mit der einen oder anderen Zeile Code etwas anfangen, weiß natürlich
nicht,inwiefern das praktikabel ist wenn die Development-Version sowieso schon stark vom
aktuellen Release abweicht: aber ich habe auch kein Problem damit, wenn mein Code bei mir
bleibt und die eine oder Sache hier nur als Anregung dient.
Wer dennoch gerne meinen Code in seine Version einbauen möchte,dem kann ich auf Anfrage gerne
einen diff-patch (auf das aktuelle Release bezogen) der jeweiligen Datei schicken.

[Thorsten]

Hi,

es wäre genial, wenn du mir deinen Code zur Verfügung stellen könntest. Ich würde deinen Code dann in die 1.4.0 einfließen lassen. Deine Änderungen klingen alle sehr praktikabel!

bye
Thorsten

[OcassionalUser]

Hi,

es wäre genial, wenn du mir deinen Code zur Verfügung stellen könntest. Ich würde deinen Code dann in die 1.4.0 einfließen lassen. Deine Änderungen klingen alle sehr praktikabel!

Okay, dann werde ich mich am besten mal daran machen, zu dokumentieren,
was ich genau gemacht habe und welche Felder ich in welcher Datenbank
hinzugefügt habe.
Ich habe momentan noch nicht alles als Funktion ausgelagert, von daher
werde ich mich erstmal darum kümmern, dass ich das meiste als
Funktion in die /inc/functions.php auslagere.
Und dann kannst Du ja mal sagen wie ich Dir den Code zukommen lassen
soll. Vorstellbar wäre, dass ich dann alle Folder packe und Dir per eMail
zukommen lasse.
Oder aber ich schreibe genauer auf, was ich wo verändert habe...
Müssen wir dann mal gucken. Was den Vorschlag mit dem Release 1.40
angeht: für wann ist das genau geplant ? Weil ich weiß nicht, ob ich die
nächsten Tage dazu komme, das alles ein wenig "sauberer" zu gestalten
und ausreichend zu dokumentieren.
Falls also das 1.40er Release innerhalb der nächsten 1-2 Wochen ansteht,
dann würde ich das lieber noch etwas verschieben, damit Du da nicht nur
Kauderwelsch von mir bekommst.

[Thorsten]

Hi,

schick mir einfach alles per Mail als gezippte Datei. Bitte auch mit deiner E-Mailadresse und deinem richtigen Namen, damit ich deine Urheberrechte an deinem Code nicht verletze.

Die 1.4er plane ich derzeit für April, im Februar und März sollen mehrere Testversionen rauskommen.

bye
Thorsten

[OcassionalUser]

Okay, dann habe ich ja noch etwas Zeit, sollte also klappen !
Noch eine Frage in eigener Sache: weißt Du, ob es sowas wie eine PlugIn-Library
für PHP gibt ?
Ich dachte da an eine ganz einfache Library, die es ermöglicht PlugIns
zu schreiben, die dann auch nachgeladen werden. Muss ja nichts
Grosses sein. Einfach nur um die Möglichkeit zu haben, Erweiterungen
zu schreiben, ohne gleich im Code rumzupfuschen ...
Mir ist schon klar, dass phpMyFAQ momentan gar nicht darauf ausgelegt
ist, extern erweitert zu werden - aber das könnte man ja mit der Zeit
ändern.
Ich hatte mir schon ein paar Kleinigkeiten überlegt, speziell um dem
Admin-Menu ganz einfach Funktionalität hinzufügen zu können indem
man einfach nur ein Modul in einen Folder packt. Ich würde mir ansonsten
einen kleinen Workaround mit Funktionszeigern basteln. Aber vielleicht hast
Du ja bessere Ideen-oder vielleicht gibt's ja schon eine entsprechende
Library ? Wie stehst Du denn zu der Idee, phpMyFAQ PlugIn-fähig zu
machen ?

[Thorsten]

Hi,

das mit einer Plugin-Schnittstelle ist schon länger angedacht. Da müsste ich mir halt mal eine API ausdenken, die diese Funktionalität bereitstellt. Derzeit ist der Code allerdings noch so vom Umfang her, dass ich eigentlich alle Hacks, die ich so zugeschickt bekomme, auch mit einbaue, da sie bisher immer sehr sinnvoll sind.

bye
Thorsten

[OcassionalUser]

Ja, klar eine API ausdenken müsste man sich dann schon - aber Du
weißt auch nicht, ob es entsprechende Libraries bereits fertig/einsatzbereit
gibt ? Also so, dass man sich das ganze Drumherum sparen kann und sich
nur noch auf d. API konzentrieren kann ? Ich hatte mich neulich mal
umgeguckt, es gibt einige PlugIn-Ideen für PHP - aber meist spezifisch für
CMS und nicht wirklich allgemein.
Ich hätte es schon ganz praktisch gefunden wenn man einzelne Funktionen
auslagern könnte - unabhängig davon, ob sie sowieso sinnvoll sind.
Denn man könnte so auch gleich ein Funktions-Management betreiben und
jede zusätzliche Funktion über das Admin-Menu aktivieren/deaktivieren
oder auch nur einstellen. Auf die Art und Weise könnte der PlugIn-Host auch
gleich eine direkte Verbindung zu einer Tabelle mit Einstellungen in der SQL DB bereitstellen und jedes PlugIn könnte dann nur direkt über einen
Pointer auf das PlugIn-Host Objekt seine Einstellungen auslesen/speichern,
ohne dass der PlugIn-Autor selbst solche Dinge in die Hand nehmen müsste.
Und so könnte man eine ganze Menge vom PlugIn-Host abnehmen lassen,
halt die üblichsten Sachen die man normalerweise machen muss.

Ach, es wäre auch ganz nett wenn man langfristig dazu übergehen könnte, auch für die Administration Templates zu verwenden.

Was die Sache mit den PlugIns angeht: man könnte ja mal einen separaten
Thread zu dem Thema starten und sehen, was sich so an Vorschlägen und
Ideen sammelt - auch bezogen auf die Schnittstelle, so könnte man
Architekturvorschläge gleich von Anfang an berücksichtigen.
Ich für meinen Teil würde erstmal in zwei versch. PlugIn-Kategorien
unterteilen: solche für den Admin und allgemein PlugIns für die Users.
Entsprechend müsste man sich dann ein paar Kleinigkeiten ausdenken,
wie speziell die User-Plugins auf das Template für die jeweilige Seite
zugreifen bzw. wo sie eingebaut werden.

[Thorsten]

Hi,

also allgemein nutzbare Plugin-Schnittstellen habe ich auch sch gesucht, aber bisher nicht gefunden. Das Problem ist aber auch, dass das Ganze schnell sehr kompliziert und umfangreich werden kann: Man stelle sich vor, die TopTen wäre ein Plugin. Das müsste nicht nur die FAQ programmiertechnisch "merken", sondern auch in den Templates mit hinzugefügt werden. Evtl würde da dann helfen, wenn man die Templates von der FAQ selber generieren lassen würde. Aber da kommt man dann in Dimensionen, die schon sehr abstrakt sind.

bye
Thorsten

[OcassionalUser]

Ja, da hast Du schon recht-notfalls müsste man im einfachsten Falle halt Platzhalter für bestimmte Positionen innerhalb des Templates für die PlugIns bereitstellen. Das wäre aber mit Abstand am wenigstens elegant.
Alternativ könnte man im Admin-Menu einstellen, WO ein PlugIn eingebaut wird. Das hieße, das jedes PlugIn praktisch erst installiert/eingerichtet werden müsste.
Aber zumindest wäre die notwendige Logik dann gering gehalten, weil die
Einrichtung des PlugIns vom Admin übernommen wird. Der würde dann
nur noch sagen "Top10.plugin.php" in Tabelle XYZ auf der main-Seite anzeigen - ggf. unter Benutzung des CSS bla.css und die ganze Tabelle in einen Div-Layer packen,
der ggf. dynamisch positioniert wird.
Das wäre eine der Möglichkeiten, kein Beinbruch was die Einrichtung angeht
und trotzdem hätte man sein PlugIn an der richtigen Stelle.
Das PlugIn könnte ja auch default-Werte mit bringen/vorgeben, wo es
positioniert werden soll.
Beispielsweise

1) VOLLTEXTSUCH-SEITE
2) Im Formular namens "suche"
3) hinter der Tabellenzeile die das Control-Element "checkbox" namens "all" enthält

- Ich würde also das Template der VOLLTEXTSUCH-SEITE öffnen,
alles in eine Variablen einlesen.

- Nach dem Formular namens "suche" gucken
- Das gesamte Formular bis einschliesslich </form> einlesen
- Dann nach einer Tabelle suchen in der es eine Zeile mit einer Spalte
gibt in der <input type="checkbox"> und "name="all" vorhanden ist.
- nach dem schliessenden </tr>-Tag suchen und schon hat man die Position wo das PlugIn eingefügt werden soll.

Das könnte man also mit regex noch wirklich ziemlich leicht umsetzen.
Und ggf. halt noch an andere Parameter koppeln: <table name="formular">
man bräuchte also nicht mal mit besonderen Kommentaren zu
arbeiten.


Die genaue Positions-Definition könnte man entweder dynamisch mit
Pseudo-Code in einem String festlegen - oder aber mit einem entsprechenden Objekt
regeln.

Pseudo-Code:

$pos = position;
$pos-> templatefile['filename']="search.html";
$pos-> where['table']="name";
$pos-> where['table']->where['form']="suche";
$pos-> where['table']->form->where['input_type']="checkbox";

halt irgendas deskriptives in der Art.
Könnte man ja ggf. alles in einen String wie eine Pfad-Angabe packen,
natürlich mit Parametern und AND/OR Funktionalität.

Ich stelle mir das jetzt noch nicht allzu schwierig vor und es würde definitiv
schon mal ein paar gute Vorteile bieten und obwohl es noch überschaubar
ist und noch nicht zu abstrakt, könnte man schon eine Menge damit
umsetzen.

[Thorsten]

Hi,

stimmt. Allerdings ist das sinnvoller in die 2.0 zu integrieren, weil diese Version mit einem neuen DB-Modell kommen soll. Die 1.4er baut ja noch großteils auf einem inzwischen fast 3 Jahre alten Modell auf, dass nicht wirklich sinnvoll ist.

Man solllte zunächst deine sinnvollen Änderungen implementieren und während der 1.4er Phase der FAQ eine Plugin-Schnittstelle definieren und hinzufügen.

bye
Thorsten