New module: Hints

mrbaseman · 21.12.2018 23:53:53

(German version see below)

I have written a new module to create hints, tutorials, or documentation in the backend. It always makes sense where people with different levels of skills and therefore different privileges in the backend work together.

An admin user installs modules and delegates tasks to one or more editors. They help feeding the web page with content, but they might not be that much familiar with IT. They need some hints how to use the modules in the backend. This new module allows the admin to provide such hints etc.. Another use case is a team of collaborators who have to coordinate their work and need a place to insert additional information about what has been done, how and why...

The module does not produce any frontend output. In the backend there is a text area where one can insert some text. html tags are allowed, newlines are converted to html line breaks.
The module supports several modes: shared/unshared, and hidden/visible. Each section is assigned to an owner. Members of the administrator group have special privileges. If they have permissions on the Hints module they can do everything the owner can do and also change the ownership.

Unshared sections can be modified (or deleted) only by the owner and administrators.
Shared sections can be modified by all users with Hints permissions and permissions to modify the page.
Hidden sections can be seen/modified only by the owner and administrators.
Sections that are not hidden can be seen by everyone with permissions to use the Hints module.

The background color can be selected which can be used to mark some hints as important, others as regular hints, or visually assign hints to to specific tasks or user groups.

German version:

Ich habe ein neues Modul erstellt, mit dem man Hinweise, Anleitungen und Dokumentation im Backend erstellen kann. Das ist immer dann sinnvoll, wenn Menschen mit unterschiedlich tiefen Kenntnissen im Backend zusammenarbeiten und entsprechend unterschiedliche Privilegien zugewiesen bekommen.

Ein Admin user installiert Module und delegiert Aufgaben an einen oder mehrere Redakteure. Diese helfen ihm die Webeseite mit Inhalten zu füllen, aber sie sind eventuell nicht so vertraut mit IT. Sie brauchen ein paar Hinweise, wie die Module im Backend zu bedienen sind. Dieses neue Modul erlaubt es dem Admin gerade solche Hinweise etc. zu erstellen. Ein weiterer Answendungsbereich ist ein Team, dessen Mitarbeiter ihre Arbeit untereinander abstimmen müssen und sie brauchen eine Platrorm um Begleitinformationen zu hinterlegen, z.B. was erledigt ist, wie und warum...

Das Modul erzeugt im Frontend keine Ausgabe. Im Backend stellt es eine Textarea bereit in die Text eingegeben werden kann. html tags sind dort erlaubt, Zeilenumbrüche werden in html line breaks umgewandelt.
Das Modul unterstützt mehrere Modi: freigegeben/nicht freigegeben sowie verersteckt/sichtbar. Jede Section wird einem Besitzer zugeordnet. Mitglieder der Administratorgruppe haben besondere Rechte. Wenn sie Zugriff auf das Hints Modul haben, können sie alles tun, was der jeweilige Besitzer einer Section tun kann und darüber hinaus die Section einem neuen Besitzer zuweisen.

Nicht freigegebene Sections können nur durch den Besistzer und durch Administratoren geändert oder gelöscht werden.
Freigegebene Abschnitte können von allen Benutzern mit Berechtiung für das Hints Modul und zum Ändern der jeweiligen Seite geändert werden.
Versteckte Sections können nur vom Besitzer und von Administratoren betrachtet oder geändert werden.
Sections die nicht versteckt sind, können von allen mit der Berechtigung das Hints Modul im Backend zu verwenden gesehen werden.

Die Hintergrundfarbe kann ausgewählt werden, was dazu benutzt werden kann, bestimmte Hinweise als wichtig und andere als normal zu kennzeichnen, oder visuell Hinweise mit bestimmten Aufgaben zu verknüpfen oder sie bestimmten Nutzergruppen zuzuweisen.

Thanks to Franky for testing and providing input to this work

florian · 23.12.2018 09:42:25

Danke schon mal, folgende Anmerkungen:
a) ich habe das Modul auf einer Testwebsite installiert. Es hat sich dabei selbst automatisch als Ablaufdatum den Zeitpunkt der Installation gesetzt.

Ist das beabsichtigt, und wenn ja, warum?
b) Ich hadere etwas mit dem Wording freigegeben / versteckt, die ja nun im WBCE-Kontext eine zentrale Bedeutung haben und den Zustand von Seiten in der Frontend-Ansicht beschreiben. Vom Standpunkt der Usability her ist es m.E. suboptimal, diese hier in einem anderen Zusammenhang zu verwenden, gerade weil das Modul ja im Frontend keine Ausgabe hat, und eine freigegebene Seite im Frontend natürlich noch lange nicht von allen Besuchern/Benutzern bearbeitet werden kann. Ich würde daher empfehlen, statt der "vorbelasteten" Begriffe beim Hints-Modul die Checkboxen freigegeben/versteckt anders zu beschriften ([ ] gesperrt [ ] vertraulich o.ä.)

Anmerkung: Es ist systembedingt so, dass ein Benutzer, vor dem der Hints-Abschnitt versteckt wird, im Backend trotzdem "versteckt" sieht. Das könnte für Verwirrung oder auch Frustration aufgrund wahrgenommener Zurücksetzung / mangelnder Privilegien o.ä. sorgen.
Versucht der Benutzer, vor dem der Inhalt des Hints versteckt wird, den Hint-Abschnitt zu löschen, erscheint die Meldung "Sicherheitsverletzung" und der Benutzer wird aus dem Backend gekickt (bleibt aber angemeldet). Dieses etwas rüde Verhalten lässt sich vermutlich aufgrund begrenzter Gestaltungsmöglichkeiten der WBCE-Rechteverwaltung wohl nicht eleganter gestalten.
Diese Phänomene bei Hints-Abschnitten, die für bestimmte Benutzer nicht angezeigt werden sollen, können durch die Nutzung der normalen WBCE-Benutzer-/Gruppenverwaltung umgangen werden. Bei den Gruppen kann festgelegt werden, welche Module die Gruppenmitglieder sehen und bearbeiten dürfen. Wird hier eine Gruppe angelegt, die zwar die betr. Seite bearbeiten darf, nicht jedoch das Hints-Modul,kann so ohne Konflikte erreicht werden, dass das Modul nur für bestimmte Nutzer sichtbar ist.
Gruppenrechte

Beitrag geändert von florian (23.12.2018 09:43:49)

mrbaseman · 23.12.2018 16:37:18

Hallo Florian,

danke für deine Anmerkungen.

florian schrieb:

Danke schon mal, folgende Anmerkungen:
a) ich habe das Modul auf einer Testwebsite installiert. Es hat sich dabei selbst automatisch als Ablaufdatum den Zeitpunkt der Installation gesetzt.
https://forum.wbce.org/attachment.php?i … download=1
Ist das beabsichtigt, und wenn ja, warum?

Selbst wenn kein Inhalt ausgegeben wird, wird im Frontend ein Section Anchor erzeugt. Um diesen zu vermeiden, kann man die Section als abgelaufen markieren. Da bei diesem Modul ohnehin nie eine Ausgabe im Frontend vorgesehen ist, habe ich diesen Automatismus gleich beim Hinzufügen der Section eingebaut.

florian schrieb:

b) Ich hadere etwas mit dem Wording freigegeben / versteckt, die ja nun im WBCE-Kontext eine zentrale Bedeutung haben und den Zustand von Seiten in der Frontend-Ansicht beschreiben. Vom Standpunkt der Usability her ist es m.E. suboptimal, diese hier in einem anderen Zusammenhang zu verwenden, gerade weil das Modul ja im Frontend keine Ausgabe hat, und eine freigegebene Seite im Frontend natürlich noch lange nicht von allen Besuchern/Benutzern bearbeitet werden kann. Ich würde daher empfehlen, statt der "vorbelasteten" Begriffe beim Hints-Modul die Checkboxen freigegeben/versteckt anders zu beschriften ([ ] gesperrt [ ] vertraulich o.ä.)

Ich hatte auch zunächst die englischen Begriffe "shared" und "hidden" und nach passenden Übersetzungen gesucht. Das in sozialen Medien üblich gewordene "teilen" gefällt mir persönlich nicht und trifft es auch nicht wirklich. Vielleicht wären etwas längere Beschriftungen "zum Bearbeiten freigeben" und "Abschnitt verstecken" denkbar? Etwas Platz hat es ja noch, auch wenn die Beschriftungen dann etwas mehr Platz in Anspruch nehmen.

florian schrieb:

Anmerkung: Es ist systembedingt so, dass ein Benutzer, vor dem der Hints-Abschnitt versteckt wird, im Backend trotzdem "versteckt" sieht. Das könnte für Verwirrung oder auch Frustration aufgrund wahrgenommener Zurücksetzung / mangelnder Privilegien o.ä. sorgen.

Ja, die Überschrift der Section lässt sich nicht verstecken. Da erschien es mir die bessere Lösung, wenigstens einen Hinweis mit auszugeben - immer noch besser als eine Überschrift, die ganz ohne zugehöriges Modul zwischen anderen Sections herumhängt smile

florian schrieb:

Versucht der Benutzer, vor dem der Inhalt des Hints versteckt wird, den Hint-Abschnitt zu löschen, erscheint die Meldung "Sicherheitsverletzung" und der Benutzer wird aus dem Backend gekickt (bleibt aber angemeldet). Dieses etwas rüde Verhalten lässt sich vermutlich aufgrund begrenzter Gestaltungsmöglichkeiten der WBCE-Rechteverwaltung wohl nicht eleganter gestalten.

Hmm... stimmt. In dem Fall ist es besser, den Benutzer zurück zum Bearbeiten der Abschnitte zu schicken. Ist in der aktuellsten Version schon geändert.

florian schrieb:

Diese Phänomene bei Hints-Abschnitten, die für bestimmte Benutzer nicht angezeigt werden sollen, können durch die Nutzung der normalen WBCE-Benutzer-/Gruppenverwaltung umgangen werden. Bei den Gruppen kann festgelegt werden, welche Module die Gruppenmitglieder sehen und bearbeiten dürfen. Wird hier eine Gruppe angelegt, die zwar die betr. Seite bearbeiten darf, nicht jedoch das Hints-Modul,kann so ohne Konflikte erreicht werden, dass das Modul nur für bestimmte Nutzer sichtbar ist.

Damit bin ich leider nicht weit genug gekommen. Um den Inhalt im Backend überhaupt angezeigt zu bekommen, muss man Berechtigung für das Hints-Modul haben. Damit kann man den Inhalt auch bearbeiten. Und diese Einstellungen sind global, nicht auf einzelne Sections bezogen. Grundsätzlich könnte man solche Aufgaben auch im Core einbauen. Man könnte zum Beispiel in der Kopfzeile der Module die Möglichkeit vorsehen, kurze, frei definierbare Erläuterungstexte zu hinterlegen. Auch die Berechtigungen könnte man grundsätzich feingranularer gestalten, was jedoch von den Modulen letztlich unterstützt werden muss (zumindest wenn man eine readonly-Berechtigung im Backend mit einführen möchte). Einzelne Sections für bestimmte Gruppen anders freizugeben als es die globalen Einstellungen vorsehen,wäre wohl ohne Änderung an den Modulen möglich, stellt aber einen ziemlich gravierenden Eingriff ins bisherige Rechtesystem dar. Manchmal wäre es geschickt, aber gerade die einfache Bedienbarkeit ist ja ein großes Plus von WBCE gegenüber komplexeren CMS Lösungen.

Anbei die aktualisierte 0.3.2

florian

florian · 24.12.2018 10:45:51

Danke für die Rückmeldungen.

Selbst wenn kein Inhalt ausgegeben wird, wird im Frontend ein Section Anchor erzeugt. Um diesen zu vermeiden, kann man die Section als abgelaufen markieren.

Ich fände es gut, wenn das automatische Setzen des Ablaufdatums optional wäre. In gefühlt 99 von 100 Fällen ist der Section-Anchor kein Problem, während die zeitgesteuerte Veröffentlichung von Abschnitten ja durchaus auch "richtig" zum Einsatz kommt und nicht unbedingt als Workaround verwendet werden sollte.

Vielleicht wären etwas längere Beschriftungen "zum Bearbeiten freigeben" und "Abschnitt verstecken" denkbar?

Ja, gute Idee. Die Checkboxen könnten ja auch untereinander stehen.

Zu Berechtigungsproblem und im bei den Kollegen™ geäußerten Ideen/Wünschen hinsichtlich WYSIWYG/Bildern:
Denkbar wäre eventuell - aber dann wird es so richtig aufwändig, fürchte ich, und ich weiß auch nicht, ob das technisch tatsächlich umsetzbar ist oder ich da zu blauäugig an die Sache herangehe - die Kombination aus einem (Backend-)Seitenmodul für die Anzeige der Hints und einem Admintool für das Erstellen der Hints.
Im Admintool würden dann mittels CKEditor die Hints verfasst - mit Textformatierungen, Bildern usw. - von denjenigen, die für die Admintools freigeschaltet sind (und später einmal: die für das Hints-Admintool freigeschaltet sind, noch ist das ja leider noch nicht möglich, Rechte nur für einzelne Admintools zu vergeben), und auf der/den jeweiligen Seiten im BE würde dann der Hint hübsch formatiert angezeigt werden.

mrbaseman · 25.12.2018 01:59:11

Hallo Florian,

florian schrieb:

Ich fände es gut, wenn das automatische Setzen des Ablaufdatums optional wäre. In gefühlt 99 von 100 Fällen ist der Section-Anchor kein Problem, während die äzeitgesteuerte Veröffentlichung von Abschnitten ja durchaus auch "richtig" zum Einsatz kommt und nicht unbedingt als Workaround verwendet werden sollte.

ja schon, nur dass bei diesem Modul (im Gegensatz zu Code2 zum Beispiel) niemals irgend ein Frontend output erzeugt wird, so dass die Einstellungen für zeitgesteuerte Veröffentlichung für dieses Modul, das ausschließlich der internen Dokumentation dient, keine echte Bedeutung haben. Man kann damit lediglich festlegen, in welchem Zeitraum ein Section-Anchor ohne zugehörigen Inhalt angezeigt werden soll.

Zu Berechtigungsproblem und im bei den Kollegen™ geäußerten Ideen/Wünschen hinsichtlich WYSIWYG/Bildern:
Denkbar wäre eventuell - aber dann wird es so richtig aufwändig, fürchte ich, und ich weiß auch nicht, ob das technisch tatsächlich umsetzbar ist oder ich da zu blauäugig an die Sache herangehe - die Kombination aus einem (Backend-)Seitenmodul für die Anzeige der Hints und einem Admintool für das Erstellen der Hints.

Ein zugehöriges Admintool wäre eine Idee, und während ich darüber nachgedacht habe, ist mir ein anderer Gedanke gekommen: Das Hints Modul selbst könnte Einstellungen haben. Diese können pro Section sein und Globale Werte enthalten, und jeder Benutzer könnte seine eigenen Einstellungen haben (ähnlich wie man es unter Linux für diverse Programme kennt, dass man im $HOME benutzerspezifisch die Eintellungen unter /etc überschreiben kann, die wiederum die ein-compillierten Defaults überschreiben).

So könnte ich mir 4 Arten der Ansicht festlegen:

WYSIWYG mittels ckeditor (was ich als Default für dieses Modul für zu wuchtig halte),
die Ansicht wie sie sie nicht-Änderungsberechtigte haben, plus einen Edit-Button, der zur momentanen Anssicht im Backend führt,
die momentane Ansicht ggf. noch ergänzt um einen Preview Button,
Übernehmen der Einstellungen von übergeordneter Stelle.

Im Admintool würden dann mittels CKEditor die Hints verfasst - mit Textformatierungen, Bildern usw. - von denjenigen, die für die Admintools freigeschaltet sind (und später einmal: die für das Hints-Admintool freigeschaltet sind, noch ist das ja leider noch nicht möglich, Rechte nur für einzelne Admintools zu vergeben), und auf der/den jeweiligen Seiten im BE würde dann der Hint hübsch formatiert angezeigt werden.

Im Fall von HInts würde man es wahrscheinlich noch feingranularer haben wollen, dass man pro section festlegen kann, wer den Inhalt bearbeiten kann und wer nicht. Die Nutzer, die die Berechtigung haben, eine bestimmte Seite zu überarbeiten, brauchen ja mutmaßlich Hinweise und Anleitungen, wie sie das tun sollen. Andererseits sind sie möglicherweise Teil eines Teams, das in einer anderen freigegebenen Hints section dokumentiert, wer was getan hat. Beim Überlegen, wie man das am besten löst, ist mir obiges Konzept mit verschiedenen Ansichten gekommen, die man auf verschiedenen Levels einstellen kann (auf der Section selbst, als User-Default, vom Owner einer Section für diese speziell und letztendlich Defaulteinstellungen falls nichts speziell eingestellt ist.

Das bräuchte keine Erweiterungen am Core, kein separates Admin-Modul, man könnte alles im Hints-Modul selbst implementieren. Man braucht nur eine entsprechende Settings-Tabelle und die Implementierung der entsprechenden Ansichten.

viele Grüße, Martin

florian

mrbaseman · 31.12.2018 01:49:31

in 0.3.4 sind die längeren Labels für die Checkboxen mit drin und eine Vorschaufunktion mit der Änderungsberechtigte (Besitzer, Admins) sehen können, wie der Hint für diejenigen angezeigt wird, die keine Editierberechtigung haben (bei nicht zum Editieren freigegebenen Hints).

Die Möglichkeit zur Umschaltung auf WYSIWYG-Editor ist noch nicht drin, ist aber in Vorbereitung.

florian, chap, thanks, bodo

chap · 31.12.2018 16:37:57

Oha... das ist ja ein sehr gutes Plugin. smile Das wird sicherlich bei uns zu nutze kommen. Bisher hab ich das mit einer Internen Seite und den Reviews gelöst. smile Aber so ist das noch besser und am ende übersichtlicher. smile Coole Sache. smile

mrbaseman · 04.01.2019 23:51:50

Hi,

@chap danke für das Feedback. Ich hab auch schon länger an so ein Modul gedacht aber selbst bisher auch diverse Workarounds eingesetzt. Nun gab es mal den Anlass, das doch mal anzupacken

@florian zu den obigen Überlegungen habe ich eine neue Version, in der die verschiedenen Ansichten realisiert sind. Bei den Kollegen habe ich dazu gerade folgendes gepostet:

mrbaseman schrieb:

here comes an updated version of my new hints module:
it comes with a button that allows to edit preferences for the hints.
Currently, there are only two preferences to choose: the display mode and the default display mode. The first one is for the current section and the other one is a global setting for the current user account which will be applied to all new hints sections.
The available values are:
- a text area for editing the hints (that's the previous behavior, and also the default value)
- show the hint as it would be seen by anyone who can see hints but who has no right to edit it BUT: additionally display an edit button to switch temporarily to the above mode (just like the already existing "preview" which can be shown on request)
- use a WYSIWYG editor to modify the hint (which is probably the most important new feature)
- combine the latter two modes, i.e. show a preview of the section, but the edit-button brings up a WYSIWYG editor
- for shared hints: use the preferences which the owner has adjusted for this section (perhaps a less important option, but it might be useful in some cases)
- and finally use the default settings which are applied to new sections (if you change your default preferences e.g. to wysiwyg so that all new hints sections use it, it makes sense to select this one for the current section in which you have called the preferences, because currently it is not supported to save the defaults in separate). You could use the same value as the default for the current section, too, but the difference is that when you change the default later on, this section has that value still assigned.
I admit it's a quite complicated mechanism - but if you need it simple: just forget about the last two options and select your preferred display mode as default and assign the same value to the current section. If you happen to want it different for some section, just edit the preferences for that section again.
Ah, and once more: These preferences are per user. For shared hints each user has his own preferences how he would like to edit that particular hint. I'm not sure how relevant this use case will be in which several people edit the same hint, but I can imagine that different views might lead to problems in communication, therefore double-check which view your colleague is talking about ;-)

Das Berechtigungskonzept ist hier nach wie vor das gleiche: Zum editieren freigegebene Hints können von allen Usern mit Berechtigung am Hints Modul bearbeitet werden. Dies feingranularer festlegen zu können ist dann das nächste auf der Agenda.

mrbaseman · 10.01.2019 00:53:19

Zeit für die nächste Version, jetzt mit feingranularer Berechtigungsverwaltung auf Gruppenbasis - gerade hab ich diese bei den Kollegen wie folgt angekündigt:

mrbaseman schrieb:

Hi,
here is the next update for the Hints module. In version 0.5.0 there are two improvements:
- First of all it supports groups now: Both cases, sharing the section for modification and the visibility of the hint, are possible based on particular groups. For example, the chief administrator might have a few colleagues (not necessarily in the admin group), who should be allowed to view and also edit a hint he gives to a larger team of editors who are in charge of filling the web page with content. The latter ones should only have the right to view the hint which contains a tutorial e.g. how to use the module used in the next section of that page.
The global sharing / hiding option that the module has provided in the previous versions still exist - you can just share it with all groups. As soon as you select a more specific audience, this general option will be disabled. Note that there is a difference between the "all groups" option (which includes groups not yet created) and selecting all (currently existing) groups. When you check / uncheck the "all groups" option however, the checkboxes of the existing groups will be updated as well in order to be consistent with the global option.
For consistency the logic of the visibility is inverted now. Earlier versions had a checkbox to make a hint "hidden", whereas you can make them "visible" to specific groups or to all groups now. Nothing changes in the visibility of existing sections - just the wording is different now in order to avoid having sections that are "hidden, but with some exceptions". New hints are by default visible to all groups and not shared for editing with any group. The only exception is the administrators group whose members are allowed to make any changes in the permissions anyway, so this special group is not displayed.
- A minor change concerns the preferences: The mechanism how settings on different levels are applied has been reworked. With this updated mechanism the owner of a Hint (usually the user who has created it) can determine, how other users with the permission to modify the hint see the backend. By default a textfield is used for editing hints, but users can change their default settings to a wysiwyg editor for instance. Sections they create from now on, and also sections for which they have not changed their preferences yet, are presented in a wysiwyg editor (provided that the user has the right to edit that particular hint). So far, so good, but if the owner of the section which he has just created would like to share it with others, and he would like them to see it immediately in a wysiwyg editor, he can change the preferences of that particular section to "use the settings adjusted by the owner". He is already the section owner - so it just points to his own default settings (just like "use the default settings as defined for new hints") - but this choice imposes his default preferences to the view other users have of this section (as long as they don't modify the preferences for that section under their account). [...]
Martin

PS: Ich weiß cross-postings sind nicht gern gesehen, aber ich geh davon aus, dass Ankündigungen von neuen Modulversionen davon ausgenommen sind wink

Edit: removed a personally addressed comment which doesn't provide additional information for the general audience

Beitrag geändert von mrbaseman (11.01.2019 22:26:58)

chap

mrbaseman · 11.01.2019 23:33:55

Here a minor update that fixes a typo and the preview is displayed below the buttons now to make switching it on and off easier.

I have implemented all features that I found useful. Maybe it can be added to the AOR now? It is also available on Github.

The separation of roles is implemented in the module itself, now, so no need for a separate admin-tool (as it was suggested by florian earlier in this thread). I believe having it all in one module is the better solution the following reasons: Two modules would bear the danger to have them on a different version level which might not be interoperable (depending on which features will be implemented in the future). The effort to maintain one module is less than maintaining two modules (because each module has some overhead like language files, template engine, style files...). Most importantly, however, with the current solution the right to edit hints can be granted to individual groups, which don't necessarily have permissions on admin tools, even on the basis of each section. Personally, I think the flexibility to specify these permissions separately for each section (and the owner of the section can choose this) is really a big plus of the module now.

We were discussing many of these aspects before and during development. Most things could be integrated in the core, making the hints module obsolete: One could implement permissions on the sections independent from the site-permissions (by default they would inherit the site permissions but could be changed on the section level). One could make frontend modules display their content in the backend (just include the frontend functions and call view.php instead of modify.php and one would have a huge variety of possibilities to render documentation in the backend - or at least as a starting point, each section could have "something" in the section header to enter a lengthy description. The section name could be abused for shorter hints, but the feature would have to be expanded e.g. in order to render lengthier html code parts. However, most of these ideas would require larger modifications of the core code.

Therefore, the most straight forward way of implementation was to put it into one module. First we only thought of extracting the comment feature from Code2 into a separate module so that one has the possibility to put text parts in the backend without having to grant access to code2 to untrusted (or less experienced) backend users, but more and more ideas around this topic have arisen until we ended up with the current version.

chap

mrbaseman · 01.03.2019 22:21:53

Hi,

please find attached version 0.6.0 of the Hints module. The most obvious change is that there are different display modes for the hints now. In the past there was only the standard display mode, in which users who are allowed to see the hint but who are no allowed to modify it, have seen the section just like other sections. They were simply not allowed to modify it, but it was just some block between other sections. Now, the owner of the hint has the choice between four different display modes

the standard mode (basically the same as it was in the past)
the hint floating up to the top of the backend, and depending on the WB version / backend theme it is displayed somewhere above the regular sections or even above, next to the menu bar
A popup hint which the user has to close explicitly (like everybody knows from the usual cookie hints on many web pages) - the user can either close it permanently for his current session by clicking the cross, or he clicks anywhere outside of the hint which closes it, but it will reappear the next time he loads that page
bottom hint: basically the same, but shown in a kind of status bar at the bottom of the page

There are a couple of minor improvements as well:

on dark background the font color is switched to light color now
background colors for the palette are chosen from values well supported by most browsers now
section headers are not displayed in Standard and Floating display mode anymore(in Popup and Bottom mode a button is shown in the regular Hints section which allows the user to show the hint again when he has closed it)
A Dutch language file has been added

Thanks a lot to Ruud for most of the ideas in this release, for large parts of their implementation, for intensive testing and fruitful discussions.

Martin

stefanek

Slugger · 22.07.2019 00:23:09

Hallo ,
erstmal vielen Dank für das hilfreiche Modul, genau das was ich für die Jenige/n brauche/n werde, damit sie damit arbeiten können.

Wäre es möglich die Hintz auch in einem eigenen Popup zu öffnen bzw. als "Slider" ein und auszublenden.

Bei wird es Hinweise geben die doch ein wenig mehr Notizen beinhalten und die Übersicht der bestehenden Seiten stören könnten?

bernd · 22.07.2019 00:52:52

Anzeigemodus "Popup" sollte doch genau das machen?!?

Slugger · 22.07.2019 01:12:25

Nee der ist genau im "Bild" wink

mrbaseman · 22.07.2019 11:37:09

Anzeigemodus als "Fußzeile"? Das ist so eine Art Popup, aber eben am unteren Bildschrimrand wo es nicht so viel verdeckt. Es gibt vier verschiedene Anzeigemodi:

"Standard" - zeigt den Hint wie eine normale Section an, nur eben nicht veränderbar für User die nur Leseberechtigung haben
"Aufsteigend" - verschiebt die Section ganz nach oben, aber eingebettet in die Backend-Seite
"Popup" - wie der Name schon sagt - ist etwas aufdringlicher, für diejenigen die oft nur das sehen was sie sehen wollen
"Fußzeile" - Ein Banner am unteren Rand, wie man es von den Cookie-Meldungen kennt

Ein Popup in einem separaten Browserfenster ist momentan nicht vorgesehen. Du könntest aber einen Link auf eine andere Seite im eigentlichen Hinweis hinterlegen, bei dem du target="_blank" angibst. Diese andere Seite kann zum Beispiel eine versteckte Seite sein oder eine mit Anmeldung und dann kannst du die Seite ganz normal wie andere Frontendseiten mit allen Modulen die du brauchst erstellen, und der Hint gibt lediglich den Hinweis z.B. "für Hilfe zur Bearbietung dieser Seite bitte hier klicken"

bodo · 11.10.2019 17:46:15

Super Modul! Habe bisher immer Code2 dafür benutzt. Gibt immer wieder Redakteure, die bei manchen Modulen den Umgang vergessen oder bestimmte Bildgrößen einhalten müssen. So ist das Modul HINTS sehr gut zum Beschreiben / Dokumentieren. Auch die Farbanpassung ist sehr gut, damit weiß man gleich, was nur zur Beschreibung des Modules gehört und nicht zur Website (Frontend). Meine Kunden freuen sich darüber, da es für Laien auch beim einfachen CMS immer etwas kompliziert ist, wenn nicht ständig darin gearbeitet wird. thumb_up

mrbaseman · 12.10.2019 00:26:01

Danke für die positive Rückmeldung. In der Tat ist das Modul aus einer Diskussion über Code2 heraus entstanden. Code2 hat ja auch Kommentare. Um die sehen zu können, braucht der Nutzer aber ja Zugriff auf das Code2 Modul.

Damit kann er auf Seiten, auf die er Zugriff hat, ja auch php-Code einfügen. Gerade mit diesem php-Code kann der Benutzer aber alles tun. Benutzer, denen man die Bedienung der Module erst noch erklären muss, stellen vermutlich nicht absichtlich Unfug an, können aber auch durch Unwissenheit mit den hohen Rechten innerhalb von Code2 versehentlich erheblichen Schaden anrichten.

Daher sollte ein Modul für Dokumentation her, das es dem Superadmin erlaubt, seinen Helfern Hints zu geben, aber genauso auch eine Platform darstellt, mit der Mitlglieder eines Teams im Backend z.B. Todo-Listen zu pflegen.

mrbaseman · 25.05.2020 22:00:21

Hi,

here is an updated version. Thanks to Bernd for the hint on how to fix a deprecated warning for php 7.4

Greetings, Martin

Slugger · 28.06.2020 14:07:03

Kurze Info:

Im AOR scheint zwar eine Version 0.6.1 zu sein jedoch steht in der info.php noch Version 0.6.0, so das ein Update verweigert wird!

florian · 28.06.2020 14:32:54

ist korrigiert, danke für den Hint

Slugger · 07.07.2021 16:31:24

Damit Hints unter PHP 8 wieder läuft:

[Exception] There was an unknown exception: Undefined constant "MYSQL_ASSOC" in line (51) of /modules/hints/modify.php
[Exception] There was an unknown exception: Undefined constant "MYSQL_ASSOC" in line (51) of /modules/hints/modify.php

Änderung der Zeile 51 von MYSQL_ASSOC in MYSQLI_ASSOC

Beitrag geändert von Slugger (07.07.2021 16:31:46)

mrbaseman · 11.07.2021 12:39:17

das ist in Version 0.6.2 eigentlich schon behoben.

Slugger

Slugger · 11.07.2021 12:58:17

Ich habe mich nach der Aktualität im AOR gerichtet. Da ist noch die Vorgängerversion drin wink

florian · 11.07.2021 17:20:43

Version 0.6.2 ist jetzt auch im AOR

hpzaun · 11.07.2021 23:04:21

Hallo,
im AOR wäre eine deutsche Beschreibung noch schön.
Schönen Sonntag
hpzaun

WBCE CMS Forum

#1 21.12.2018 23:53:53

New module: Hints

#2 23.12.2018 09:42:25

Re: New module: Hints

#3 23.12.2018 16:37:18

Re: New module: Hints

#4 24.12.2018 10:45:51

Re: New module: Hints

#5 25.12.2018 01:59:11

Re: New module: Hints

#6 31.12.2018 01:49:31

Re: New module: Hints

#7 31.12.2018 16:37:57

Re: New module: Hints

#8 04.01.2019 23:51:50

Re: New module: Hints

#9 10.01.2019 00:53:19

Re: New module: Hints

#10 11.01.2019 23:33:55

Re: New module: Hints

#11 01.03.2019 22:21:53

Re: New module: Hints

#12 22.07.2019 00:23:09

Re: New module: Hints

#13 22.07.2019 00:52:52

Re: New module: Hints

#14 22.07.2019 01:12:25

Re: New module: Hints

#15 22.07.2019 11:37:09

Re: New module: Hints

#16 11.10.2019 17:46:15

Re: New module: Hints

#17 12.10.2019 00:26:01

Re: New module: Hints

#18 25.05.2020 22:00:21

Re: New module: Hints

#19 28.06.2020 14:07:03

Re: New module: Hints

#20 28.06.2020 14:32:54

Re: New module: Hints

#21 07.07.2021 16:31:24

Re: New module: Hints

#22 11.07.2021 12:39:17

Re: New module: Hints

#23 11.07.2021 12:58:17

Re: New module: Hints

#24 11.07.2021 17:20:43

Re: New module: Hints

#25 11.07.2021 23:04:21

Re: New module: Hints

Fußzeile des Forums