WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => Modules => Topic started by: Martin Hecht on December 21, 2018, 10:51:24 PM
-
(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 Begleitinformatione n 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 for providing input to this work
-
Hello Martin, very useful module. Thanks for that. (Y)
The colorchooser works good.
The owner dropdown maybe should better without login name (user name is enough).
One notice is there (WB 2.12.1, PHP 7.2):
[E_NOTICE] /framework/SecureTokensInterface.php:[133] from /modules/hints/save.php:[74] bin\SecureTokensInterface->checkIDKEY "Undefined index: bfc97d24236068a5"
-
Super Idee das Modul, da ich als "Nur-Anwender" auch immer gerne Bilder in einem Hinweis-Text habe, ist es denkbar das Modul noch auf zu bohren?.
Zur Info
Die Fehlermeldung von dbs erscheint auch bei php5.6 mit WB 2.12.1
-
@Martin: nur den Namen der POST-Variable übergeben, diese wird dann automatisch auf den POST-Array bezogen (siehe public function checkIDKEY() ). Die Schreibweise oben würde ausgeschrieben bedeuten
$_POST[$_POST['owner']]
Zeile 74 in der save.php
dein original
$owner = $admin->checkIDKEY($_POST['owner']);
ändern auf
$owner = $admin->checkIDKEY('owner'); oder (falls mehrere übergebene IDKEY's mit GET oder POST unterschieden werden müssen)
$owner = $admin->checkIDKEY('owner',false,'POST');
-
Hallo zusammen,
hier ist auch schon die nächste Version. Danke @jacobi22 für den HInweis. Ich dachte es hätte daran gelegen, dass ich checkIDKEY ursprünglich erst nach der Ausgabe des Headers verwendet hatte, aber das war's dann wohl doch nicht. Deine vorgeschlagene Änderung habe ich in 0.3.1 übernommen.
@dbs: thanks for the hint not to expose login names. I have changed that in the latest version. Only if the display name is empty (I don't know if that can happen at all) I use the login name as a fallback now.
@hgs: Bilder sind jetzt schon möglich. Du kannst html tags <img src="...."> im normalen Text mit eingeben. Wenn der Hint nicht freigegeben ist, sehen die anderen User, die nicht in der Administrator-Gruppe sind, das eingebundene Bild. Um es als Besitzer oder Admin angezeigt zu bekommen, denke ich darüber nach, auch in diesem Fall die Ansicht darzustellen, die andere Benutzer sehen, und zusätzlich einen "Edit"-Button einzublenden, um zu der Bearbeitungsansicht umzuschalten. Ich habe daran schon mal gedacht, hatte dann aber den Anwendungsfall mit Bildern noch nicht im Hinterkopf. Gibt's ein Modul, bei dem man sich abschauen kann, wie man am besten einen Browser für den Medien-Ordner integriert?
-
Schau mal in das BE der aktuellen WB Version
In" Allgemeine Optionen"
da gibt es die Möglichkeit für Kopfz- und Fusseile den Editor ein- und auszublenden
https://gyazo.com/3934e50a091dffbdbdc3fe89805595f4
-
Gibt's ein Modul, bei dem man sich abschauen kann, wie man am besten einen Browser für den Medien-Ordner integriert?
eigentlich nicht, zumindest kein Browser in dem Sinne, wie es in der Media-Verwaltung oder im CKEditor möglich ist, also nix Zentrales
Es gilt meines Wissens überall noch das gleiche Grundprinzip, das auf den alten Grundregeln beruht, die besagen, das jedes Modul, das Bilder nutzt, diese in einem separaten Ordner unter /media abspeichern soll
- Modul legt beim install oder beim 1. Speichern eines Beitragsbildes einen versteckten oder freien Ordner unter /media an (z.b. News - Gruppenbild)
- Modul hat in der modify.php oder über diese einen Hochlade-Button zur Dateiauswahl auf dem Rechner, die save.php speichert das Bild dann in diesem module-eigenem Ordner unter /media
- willst du keine große Rechteverwaltung, beschränkst du dich auf diesen modul-eigenen Ordner, die darin enthaltenen Bilder kann man einlesen und darstellen (z.b. in Ruud's Minigallery), hier gäbe es dann nur zwei Rechte abzufragen, Zugriff auf das hints-Modul selbst, Zugriff auf /media-Rechte
Die Benutzung eines Editors bzw von HTML bringt m.E. nur Vorteile, wenn das Modul zwei Modi hat, einen Readonly (out of the Textarea) und einen Editor-Modul, der extra vom Berechtigten angeschaltet werden muß. Keine Ahnung, vielleicht bediene ich es falsch, aber meine Ausgabe von HTML-Code mit z.b. Bildern drin, ist am Ende nach dem Speichern wieder eine Textbox mit diesem Source-Code drin.
Von daher bin ich bei der Funktion, die mir bisher auch das Code²-Modul geboten hat. Soweit korrekt?
Wie gesagt, vielleicht bediene ich falsch und bitte korrigiert mich, aber nur so als Idee in den Raum geworfen: wie wäre es denn mit einem Switch? Der oder die editorenberechtigte n bekommen einen Button oder Link zu Öffnen eines Textfeldes / Editors. Jeder (? - ggf einstellbar, welche Gruppen) sieht aber zuerst ein DIV mit dem Ergebnis und der gewählten HG-Farbe. Ein extra wären noch passende Schriftfarben wie im ProCalendar, dunkler Hintergrund, helle Schrift und umgekehrt
Zum Thema ckeditor (Post von Harald) - ich nutze diese Technik mit integriertem schaltbarem Editor in jedem Modul, das ich hier die letzten zwei Jahre für mich gebaut habe. Hat man es heraus gefunden, wie das läuft, ist es auch leicht zu integrieren. Und mittlerweile braucht es auch in TWIG keinen Spagat mehr, diesen Editor zu öffnen. Nachteil ist aber eindeutig die "harte" Verdrahtung. Verwende ich nicht den CKeditor, sondern einen anderen, funktioniert diese Lösung nicht mehr, dann bleibt wieder ein simples Textfeld. Es muß ja auch kein anderer Editor sein, würde WB jetzt z.b. die 5er Version des CK nutzen (was ich persönlich die nächsten 3-5 Jahren nicht empfehlen würde, zumindest nicht als alleiniger Haupt-Editor), würde diese Lösung in den WB-Optionen auch nicht mehr funktionieren ohne sie umzubauen. Ein anderer Nachteil, aber gleichzeitig auch Vorteil: diese Art der Einbindung arbeitet nicht mehr mit der Einbindung individueller Konfigurationsdatei en wie wb_ckconfig.js im Template, bietet aber die Möglichkeit, jedes Modul für sich getrennt zu konfigurieren.
Für Martin kommt dazu, das er zweigleisig fahren möchte, also WB + WBCE, da nützt die schönste zentrale Lösung nix, wenn es im jeweils anderem CMS nicht funktioniert. Ich persönlich bin von der cmd-Variante in unseren neueren Modulen überzeugt, habe mich da mittlerweile recht gut eingearbeitet, das schließt aber die Nutzer von WBCE aus. Da in WB integriert, würde ich auch ausschließlich auf TWIG setzen, keine Ahnung, wie es damit bei WBCE ausschaut und wenn vorhanden, ob die Art der Integration in einem Modul gleich ist. Es macht aber vieles leichter
-
Hallo,
die Integration von WYSIWYG ist in Arbeit, in meiner aktuellsten Version noch nicht drin, aber es gibt eine Vorschau, mit der man als Besitzer oder Admin sehen kann, wie andere Benutzer, die den Hint nicht bearbeiten können, ihn sehen würden. Uwe: Damit siehst du auch den gerenderten HTML-Code. Ein anderer User, der nicht Admin ist und dem der Hint nicht gehört, sieht ihn gleich in dieser Form (und nicht die Textarea) - es sei denn der Hint ist zur Bearbeitung freigegeben, dann sehen alle die Textbox um Bearbeitungen vornehmen zu können. Da hilft dann in künftigen Versionen der Ckeditor, wenn er dann mal im Modul mit drin ist (Damit ist dann auch die Mediafolder-Thematik erschlagen, denn im ckeditor ist ja schon ein Browser mit drin, der es erlaubt Bilder auszusuchen und einzubinden)
viele Grüße,
Martin
-
Hello Martin, works fine, also with PHP7.3.
I'm already curious about Wysiwyg, although that would be enough.
DE: Hallo Martin, funktioniert prima, auch unter PHP7.3.
Bin schon auf Wysiwyg gespannt, obwohl das bisherige reichen würde.
-
Hi, 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 ;-)
I hope it works fine on all platforms. As usual: reports about any problems are welcome and I'll try to provide a bug fix.
Martin
-
da ist leider noch einiges drin, das Probleme bereitet :oops:
Ausgangslage: Modul war in Version 0.3.4 installiert, eine Section an Position 1 von 6 Sectionen war angelegt und mit HTML-Code befüllt. Teil des HTML-Codes war u.a. auch ein Bild im media-Ordner. Mit der Einstellung "Zeige Wysiwyg-Editor" nachfolgender Fehler mit Scriptabbruch
PHP Fatal error: Cannot redeclare show_wysiwyg_editor() (previously declared in F:\xxxxxxxxxxx\modules\ckeditor\include.php:29) in F:\xxxxxxxxxxx\modules\ckeditor\include.php on line 373
nachfolgende Sectionen werden logischerweise nicht mehr dargestellt.
Das Problem ist leider nur direkt in der Datenbank korrigierbar, weil der Klick auf Einstellungen des hints-Moduls eine Sicherheitsverletzu ng erzeugt.
Redirekt nach dieser Sicherheitsverletzu ng ist offensichtlich fehlerhaft, man landet auf der WB_URL, meist ein Zeichen, einer fehlender Page- und Section-ID im Rückleitungslink
-
Diese Fehlermeldung kann ich leider bestätigen.
Eine zweite Sache ist mir aufgefallen.
Wenn ich als Admin einen Hint mit dem Editor anlege, wird er als angemeldeter Admin auch immer so angezeigt. (Einstellung verwende einen WYSIWYG Editor)
Wenn sich jetzt ein USER mit "nur Autorenrechten" anmeldet, wird diesem nur die Textausgabe angezeigt und nicht die "schöne Ansicht" wie ich diese als Admin erstellt habe.
Ansicht als Admin
https://gyazo.com/14685a67cdf346e13339a2f136f74f2e
Anzeige als Autor
https://gyazo.com/037f0dac074f6aff43ff08b153b8fcd8
-
Hallo zusammen,
zu den wysiwyg-Problemen... nun, was soll ich sagen? irgendwie scheint in 2.12 wohl ein require_once nicht mehr auszureichen um Mehrfachdefinitione n auszuschließen. Ich habe mal Anleihe beim WYSIWYG-Modul aus 2.12 genommen und einen ähnlichen Mechanismus ins Hints-Modul eingebaut.
Damit sollte hoffentlich der Konflikt mit anderen wysiwyg-Abschnitten behoben sein. Dass html-Inhalt, der im wysiwyg-Modus bearbeitet werden sollte, zu den beschriebenen Problem führt, wage ich zu bezweifeln.
@Uwe: Mit der Sicherheitsverletzu ng nehme ich an, dass das der Versuch war, über Inhalte aus dem Browser-Cache doch noch irgendwie auf die Modul-Einstellungen zugreifen zu können. Genau sowas soll der FTAN-Mechanismus ja unterbinden. Wenn die FTAN einmal aufgebraucht ist, sollte sie ihre Gültigkeit verlieren.
@Harald: Die Links zu den Screenshots funktionieren bei mir leider nicht, aber das beschriebene Verhalten ist eigentlich was ich erwarten würde: Jeder User kann für sich selbst festelegen ob er lieber wie bisher mit Textareas arbeiten oder den wysiwyg-Editor nutzen möchte, und das kann sogar jeder user für jede Section separat definieren. Dein User mit Autorenrechten müsste erst in die Einstellungen gehen und dort den wysiwyg-Editor auswählen (in der aktuellen Seciion und am besten auch gleich in den globalen Einstellungen, damit er die Änderung bei anderen Hints nicht nochmal machen muss). Vielleicht wäre auch die Variante mit der Preview in Kombination mit WYSIWYG in dem Fall auch genau das Wünschenswerte?
-
@Uwe: Mit der Sicherheitsverletzu ng nehme ich an, dass das der Versuch war, über Inhalte aus dem Browser-Cache doch noch irgendwie auf die Modul-Einstellungen zugreifen zu können. Genau sowas soll der FTAN-Mechanismus ja unterbinden. Wenn die FTAN einmal aufgebraucht ist, sollte sie ihre Gültigkeit verlieren.
Martin... bitte....
einfach mal selbst probieren, es sollte dann allerdings schon eine WB-Version sein
-
Hallo Martin
Danke dass du das Modul immer sofort anpasst.
Zu Meinem "Problem"
Ich bin ein "Nur-Anwender" und als solcher als Webmaster für 5 Webseiten einer Kirchengemeinde verantwortlich.
Mein Ansatz wäre also "meinen Autoren" ein solchen Hinweis auf einigen Seiten zu hinterlassen, die diese mit Inhalt zu versorgen haben.
Deshalb hätte ich erwartet, das der Inhalt dem Autor so als Hinweis präsentiert wird, wie ich ihn abspeichere.
Ein selbsständiges "Umschalten der USER" und ein bearbeiten der Autoren ist m.E. eher hinderlich.
Ich habe es ja schon nicht hinbekommen, wie es für Coder überhaupt kein Problem wäre, da mit html zu arbeiten.
Deshalb ja meine Frage nach der Editorbearbeitung
Wenn dann also meine "AutorenDAUs" einen html-Text zu sehen bekommt anstelle des selbserklärenden Bildes, wird es nicht Anwenderfreundlich für mich und meine DAUs
Hoffe das hat meine Erwartung an das Modil besser erklärt. :-)
-
@Harald: genau das ist eigentlich der Use case dieses Moduls. Den Autoren, die die Anleitung benötigen, solltest du dann lediglich nicht die Berechtigung geben, den Hinweis zu bearbeiten. Mach mal das Häkchen bei "zum Bearbeiten freigeben" weg - ich geh davon aus, dass sich das Modul dann so verhält wie du dir das wünschst. Das ist in der aktuellen Version vielleicht noch nicht ganz verständlich, da die Freigaben momentan noch generell sind. Ich bin aber dabei, sowohl die Sichtbarkeit als auch die Freigabe fürs Bearbeiten auf Basis der Gruppen einstellen zu können.
Den Editor-Modus einstellen müssen dann lediglich diejenigen, die die Berechtigung bekommen sollen, an dem Hinweis Änderungen vorzunehmen. In der momentanen Version wärst das lediglich du selbst als Besitzer oder andere Admins (ich hoffe nicht dass du deine "AutorenDAUs" in der Administratorgruppe aufgenommen hast).
@Uwe: Unter WB 2.8.3 + diversen Patches hat Hints 0.4.0 bei mir auch problemlos funktioniert. Mit 2.12.1 konnte ich das Problem (inclusive Sicherheitsverletzu ng) nachstellen und mit Hints 0.4.1 scheint beides bei mir zumindest behoben zu sein. Falls diese Version bei dir immer noch nicht funktioniert, müsste man eventuell die anderen Sections noch in Augenschein nehmen und sehen ob noch andere Module (außer wysiwyg) einen weiteren Mechanismus zur Einbindung von ckeditor enthalten, der eine weitere Inkompatibilität mit ins Spiel bringt.
-
Die Einstellung wars, Jetzt bekommt der Autor die Anzeige, so wie ich sie wollte.
Die Fehlermeldungen bleiben aber bestehen, Wobei die 2. Section jetzt aber im BE angezeigt wird und im FE ist diese auch zu sehen
[07-Jan-2019 09:47:42 UTC] PHP Fatal error: Cannot redeclare show_wysiwyg_editor() (previously declared in /www/xxxxx/xxxxxxxx/WB_Testbereich/WB_2.12.1/php7.2/modules/ckeditor/include.php:29) in /www/xxxxxx/xxxxxxxx/WB_Testbereich/WB_2.12.1/php7.2/modules/ckeditor/include.php on line 373
-
Die Fehlermeldungen bleiben aber bestehen, Wobei die 2. Section jetzt aber im BE angezeigt wird und im FE ist diese auch zu sehen
[07-Jan-2019 09:47:42 UTC] PHP Fatal error: Cannot redeclare show_wysiwyg_editor() (previously declared in /www/xxxxx/xxxxxxxx/WB_Testbereich/WB_2.12.1/php7.2/modules/ckeditor/include.php:29) in /www/xxxxxx/xxxxxxxx/WB_Testbereich/WB_2.12.1/php7.2/modules/ckeditor/include.php on line 373
mit Hints 0.4.1 immer noch?
-
Gerade noch mal mit einer WB 2.12.1 incl. Fix zu Rev.191 getestet.
Vorgehensweise
Anlegen
1. Section (Hints)
2. + 3. Section (WYSIWYG)
Die Fehlermeldung erscheint bei mir nicht mehr und es wird alles wie gewünscht für die Gruppe Autoren angezeigt ohne den "Hinweis" ändern zu können.
Für mich also jetzt alles i.O.
Danke
-
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).
@Harald, falls du in die Verlegenheit kommen solltest, Hints zu erstellen, die andere auch bearbeiten könnnen sollen, kannst du so vorgeben, welche Art Editor die User ohne eigenes Zutun angezeigt bekommen sollen.
Martin
-
Hello Martin, looks good, will be more and more complex.
A little typo in title "section visisble for Groups ".
Maybe the preview can be opened under the buttons instead of at the top?
So the buttons stay in place to quickly close the preview.
-
(Y)
Ich bin begeistern, läuft super.
Danke Martin
-
Hi Frank,
Hello Martin, looks good, will be more and more complex.
A little typo in title "section visisble for Groups ".
thanks, fixed in 0.5.1
Maybe the preview can be opened under the buttons instead of at the top?
So the buttons stay in place to quickly close the preview.
Good idea. It's in the latest version, too.
Martin
-
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