WBCE Home | WBCE Hilfe | WBCE Addon Repository | Impressum | Datenschutz

WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

You are not logged in.

#1 09.03.2020 11:51:30

boeseroeser
Guest

Frontend-Edit - Benutzerrechte Abfrage

Einige Module haben in der view.php eine Abfrage, ob der aktuell angemeldete User Bearbeitungsrechte hat, um dann einen Edit-Button anzubieten.
Da gibt es einige historisch gewachsene Varianten, ich würde gerne wissen, was die beste Methode ist, bzw ob das überhaupt anders besser wäre.

Zur Klarstellung: So ein Button bedeutet noch lange nicht, dass man dann auch tatsächlich etwas ändern kann - er ist nur ein Link ins Backend, sonst nichts. Sollte jemand unberechtigterweise den Button sehen und drauf klicken, muss er sich trotzdem erst anmelden.
Das ist also nicht so sicherheits-kritisch, jeder kann ja den Link auch direkt aufrufen.

Wichtig ist vielmehr, dass nicht allzuviel dazu geladen wird, dass die Abfrage also flott funktioniert.


Die Variante aus Itemz:

$makeeditlink = false;
if ($frontendeditclass != '' AND $wb->is_authenticated() ) { //$frontendeditclass gibt an, ob überhaupt ein Editschalter gewuenscht ist
	$user_id = (int) $wb->get_user_id();
	$groups = $wb->get_groups_id();
	if (in_array(1, $groups)) {
		//ist Admin	
		$makeeditlink = true; 
	} else {
		$module_permissions = $wb->get_session('MODULE_PERMISSIONS');
		if (!in_array($mod_dir, $module_permissions)) {
			$makeeditlink = true; 
		}		
	}					
}

In Topics funktioniert es so ähnlich, ich stelle das hier aber nicht rein, weil da noch weiteres Gewusel drin ist.

in der rFG ebenfalls so ähnlich. Hier wird nur zuerst einmal gefragt, obs User #1 ist (was es zu 96% wohl auch ist)
Gleiches auch in Teasers, Wunderblock.

[== PHP ==]
$rfg_frontendedit = false;
if ($wb->is_authenticated() ) { 
	$user_id = (int) $wb->get_user_id();
	if ($user_id == 1) {
		//ist SuperAdmin
		$rfg_frontendedit = true; 
	} else {
		$groups = $wb->get_groups_id();
		if (in_array(1, $groups)) {
			//ist Admin	
			$rfg_frontendedit = true; 
		} else {
		
			//Hat Berechtigung "pages"
			$system_permissions = $wb->get_session('SYSTEM_PERMISSIONS');						
			if (in_array('pages',$system_permissions) AND in_array('pages_modify',$system_permissions) ) { 
				//Hat Berechtigung dieses Modul:
				$module_permissions = $wb->get_session('MODULE_PERMISSIONS');
				if (!in_array($mod_dir, $module_permissions)) {
					$rfg_frontendedit = true; 
				}
			}		
		}
	}					
}

In Wunderblock wird eine Konstante WUB_EDIT_LINK gesetzt und die Berechtigung bei einem weiteren Modulaufruf nicht mehr überprüft. Weil: Wer einmal die Rechte hat, hat sie wohl immer und Wunderblock wird häufig mehrmals pro Seite aufgerufen.

In GlobalComments wird nur so gefragt:

.....
$system_permissions = $wb->get_session('SYSTEM_PERMISSIONS');
		if (in_array('admintools', $system_permissions)) {  //admintools generell
			$gc_frontend_edit = true; 
		}
.....

Gurufrage:
Kann man das so lassen?

Etwas problematisch erscheint mit die Abfrage:
//Hat Berechtigung "pages"
if (in_array('pages',$system_permissions) AND in_array('pages_modify',$system_permissions) ) { ...

Könnte es andere Fälle geben?

Last edited by boeseroeser (09.03.2020 11:53:33)

#2 09.03.2020 12:17:11

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

Der Edit-Link:
In Itemz wird er nur dargestellt, wenn der Platzhalter [EDITLINK] in den Einstellungen vorhanden ist.
In Topics heißt er ebenfalls [EDITLINK], es wird aber nicht überprüft, ob der Platzhalter vorhanden ist. Sollte ich machen, erspart ggf. die Abfrage des Cookies. if ($wb->is_authenticated() ) { ...
In anderen Modulen wird der Button fix gesetzt, ist also per Settings nicht abschaltbar.

Dann ist da noch die Sache, wie der Frontend-Edit geöffnet wird: Per Colorbox oder anders:

In Topics - und auch in einigen anderen Modulen - hat der EditButton die Class "tp_editlink", was per Default einen relativ großen iFrame mit dem Backend ohne Header/Footer öffnet. Das ist OK, setzt aber voraus, dass das immer so bleibt und die Colorbox installiert ist. Sonst geht einfach ein neuer Tab auf, was irritierend ist ("Was ist das jetzt?")
Was etwas stört, ist dass der iFrame geschlossen wird, wenn man "ins Graue" klickt. Änderungen gehen dann verloren.

Itemz kocht ein eigenes Süppchen mit jQuery-ui


Wären hier Änderungen sinnvoll?

#3 15.03.2020 12:47:36

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

OK, dann dröseln wir das mal auf:

Es geht hier nur darum, ob der EDIT-Link gezeigt werden soll, das bedeutet nicht, dass man mit diesem Link auch etwas tun kann.
Mit Klick auf den Link erscheint eine Backend-Seite, die nur deswegen nicht so aussieht, weil das Backend-Theme weggelassen wurde.
Das Backend ist nicht zeitkritisch, aber im Frontend sollte die Überprüfung nicht jeden  Seitenaufruf verlangsamen.


Schritt 1:
Zuerst einmal belege ich eine Variable mit false vor, damit sie mir nicht später in irgendwelchen ELSE-Zweigen verloren geht:
$makeeditlink = false;

Schritt 2a: Ist ein Edit-Schalter überhaupt gewünscht? Das kann irgendwo einstellbar sein, zb in den Modul-Settings. In Topics oder Itemz wäre das das Vorhandensein des Platzhalters [EDITLINK] und müsste schon im Vorfeld überprüft werden. Bei anderen Modulen muss man das einfach mal als gewünscht annehmen.

Schritt 2b: Ist der aktuelle Nutzer überhaupt angemeldet? Hier verlasse ich mich auf die Core-Funktion $wb->is_authenticated(), die sowohl in WB als auch in WBCE vorhanden ist. Es ist mir wichtig, dass Module da wie dort funktionieren, weil ich sonst bei einer Migration heftige Probleme habe, wenn mir ein Modul nur eine weiße Seite zeigt. $wb->is_authenticated() ist ein Urgestein und wird wohl nicht entfernt werden.

Zusammengefasst also:
if ($wb->is_authenticated() ) { ... }
oder (zb)
if ($frontendeditclass != '' AND $wb->is_authenticated() ) { //$frontendeditclass gibt an, ob überhaupt ein Editschalter gewuenscht ist...}


Schritt 3:
Wenn der Nutzer angemeldet ist, dann hat er auch eine User-ID. Diese kann ich abfragen:
$user_id = (int) $wb->get_user_id();
Zu 95% Wahrscheinlichkeit wird das der User #1 sein, also der Superadmin. Der darf alles und ich muss nichts weiter überprüfen:
if ($user_id == 1) { $makeeditlink = true; }

Else: Schritt 4:
Der User ist nicht User #1, aber wahrscheinlich trotzdem Administrator. Er gehört also der Gruppe #1 an. Es ist unerheblich, ob er noch einer anderen Gruppe angehört. Ein Administrator darf so oder so alles.
Ich frage also, zu welchen Gruppen der aktuelle Nutzer gehört, das Ergebnis ist ein Array, weil es ja mehrere sein können:
$groups = $wb->get_groups_id();
if (in_array(1, $groups)) {
$makeeditlink = true; }


Else: Schritt 5
Jetzt wirds haarig: Der Nutzer ist NICHT Admin und hat daher eingeschränkte Rechte. Diese frage ich direkt mit  $wb->get_session('SYSTEM_PERMISSIONS') ab und verlasse mich darauf, dass etwas formal brauchbares zurückbekomme, also ein Array.
$system_permissions = $wb->get_session('SYSTEM_PERMISSIONS');

Was für Rechte MUSS der Nutzer haben? Also: Was müsste er im Backend zur Verfügung haben, um zu dem zu kommen, was der Edit-Link angibt.
Er muss zunächst einmal den Seitenbaum sehen, sich zur aktuellen Seite hinklicken können und dort den Abschnitt bearbeiten können, den er gerade im Frontend vor sich hat.
Er braucht also Pages und das grundsätzliche Recht, diese auch bearbeiten zu können. Eigentlich braucht er nur letzteres, weil ersteres dazu ohnehin Voraussetzung ist:
if (in_array('pages_modify',$system_permissions) ) { ... }
Braucht er auch andere Berechtigungen, wie zb Medien, wenn er ein Bild hochladen kann? Zunächst einmal nicht, das wäre im Modul selbst zu klären.

AND: Schritt 6
Darf der Nutzer dieses Modul verwenden? Also: Hat er auch die Berechtigung, zb das Modul Itemz zu verwenden?
$module_permissions = $wb->get_session('MODULE_PERMISSIONS');
Hier gibt es eine Besonderheit:
$module_permissions enthält jetzt die Namen der Module, die der User NICHT verwenden darf. Das klingt seltsam und wird wohl historische Gründe haben: WB/WBCE ist ursprünglich ein Admin-CMS: wer angemeldet ist, darf alles. Spätere Änderungen schränkten das "Alles" ein, es wird also die Abweichung vom Alles notiert. $module_permissions ist also eine Blacklist.
Das ist deswegen haarig, weil ich genau beachten muss, wonach ich suche: Es muss die Bezeichnung in info.php > $module_directory sein, also der Verzeichnisname. Das muss aber nicht zwangsläufig übereinstimmen, man könnte den Modulordner auch nachträglich umbenannt haben.
Wir gehen hier trotzdem davon aus, dass $mod_dir den exakten Namen des Verzeichnisses enthält.
Daher:
if (!in_array($mod_dir, $module_permissions)) { $makeeditlink = true;  }

Weiteres:
Es stellt sich noch die Frage: Darf der Nutzer diese Seite bearbeiten? Was, wenn die Seite privat ist - und die Gruppe des Nutzers keine Berechtigung dafür hat?
Hier wirds kompliziert: Wenn eine Seite privat ist und der Nutzer darf sie nicht sehen, kann er den EDIT-Schalter gar nicht sehen. Also: kein Problem.
Der Fall, dass man eine private Seite zwar sehen, aber nicht bearbeiten darf, wird wohl bereits an anderen Gruppen-Berechtigungen scheitern, ist aber trotzdem konstruierbar. In diesem Fall wäre der Edit-Schalter zwar da, man würde nach Klick aber eine Meldung "Fehlende Berechtigung" sehen. Das ist unschön, aber verschmerzbar.

Brauche ich die Abfrage if ($wb->is_authenticated() ) { ... } überhaupt - kann ich nicht gleich nach $user_id = (int) $wb->get_user_id(); fragen?
Sowohl WBCE als auch WB liefert bei get_user_id() eine klare 0 zurück, wenn der Nutzer nicht angemeldet ist. Das könnte in früheren Version anders gewesen sein. In der Annahme, dass bei alten WB/WBCE-Versionen nicht einzelne Module erneuert werden, könnte man die Abfrage 2b weglassen.

Last edited by boeseroeser (15.03.2020 14:57:21)

#4 15.03.2020 15:31:55

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

Und weiter:

Muss das alles so abgefragt werden? Kann ich mit weniger auskommen?

Gibt es eine Mach-Alles-Funktion im Core? Nein, nicht sicher und (versionsübergreifend) einheitlich. Selbst wenn es eine gäbe, müsste ich eine Fallback-Lösung haben - dann kann ich überhaupt gleich diese Fallback-Lösung verwenden.

Kann ich auch auskommen mit:
$user_id = (int) $wb->get_user_id();....
$system_permissions = $wb->get_session('SYSTEM_PERMISSIONS'); ....
und
$module_permissions = $wb->get_session('MODULE_PERMISSIONS'); ....
?
Nein: Ein Zugriff auf $wb->get_session() führt zu einem Fehler, wenn der User nicht angemeldet ist. Vorher muss  $wb->get_user_id() abgefragt werden.

Muss ich die Zugehörigkeit zur Gruppe 1 überprüfen? Eigentlich nicht, weil auch ein Admin Berechtigungen hat, die sich ja bereits aus der Gruppe ergeben.
Den Superadmin $user_id==1 abzufragen macht aber durchaus Sinn, weil ich die Zahl ja schon da habe.

Zusammen also (Itemz):

$makeeditlink = false;
if ($frontendeditclass != '') { 
	$user_id = (int) $wb->get_user_id();
	if ($user_id > 0) {
		if ($user_id === 1) {
			$makeeditlink = true; 
		} else {
			$system_permissions = $wb->get_session('SYSTEM_PERMISSIONS');
			if (in_array('pages_modify',$system_permissions) ) {
				$module_permissions = $wb->get_session('MODULE_PERMISSIONS');
				if (!in_array($mod_dir, $module_permissions)) {
					$makeeditlink = true; 
				}
			}		
		}
	}					
}

Bei Modulen, die mehrmals pro Seite vorkommen - zB "Wunderblock" - ist es sinnvoll, nach der erstmaligen Überprüfung eine Konstante zu definieren, die eine weitere Überprüfung in einem weiteren Abschnitt erspart. Wichtig: Es muss eine Konstante sein, eine Variable reicht nicht. Diese Konstante muss den Namen des Moduls enthalten, um Konflikte zu verhindern.

Ein Nachtrag zur Überprüfung auf Gruppe 1 - Administratoren:
$groups = $wb->get_groups_id();
if (in_array(1, $groups)) { $makeeditlink = true; }

Das ist wohl nicht nötig, aber: Ein angemeldeter Nutzer mit entsprechenden Berechtigungen ist sehr wahrscheinlich der Superadmin - und wenn nicht zumindest Admin. Mit der Überprüfung auf die Gruppe 1 erspare ich mir in den meisten Fällen die 2 mal weitergehende Überprüfung durch $wb->get_session()...
Da es passieren könnte, dass die Handhabung von $wb->get_session geändert wird, würde diese Überprüfung vor großflächigem Schaden bewahren.

Last edited by boeseroeser (15.03.2020 15:57:56)

#5 15.03.2020 22:43:30

stefanek
Developer

Re: Frontend-Edit - Benutzerrechte Abfrage

Wenn Du Dir die Klasse Wb im framework anschaust, wirst Du sehen, dass die ganzen Methoden eigentlich (wenn auch auf Umwegen) hauptsächlich die $_SESSION zur Rate ziehen (abfragen).
Deswegen würde eine eigene Funktion (noch besser eine eigene Klasse) für Dich am besten geeignet sein, statt das Objekt $wb abzufragen.

Diese eigens erstellten Funktionen bzw. Methoden (wenn Du auf eine Klasse setzt) kannst Du dann in Deinen Modulen mit im Paket haben und Dir ist egal ob sich der Core verändert oder auch nicht.

Im Modul einfach per require_once die Funktionen reinladen oder die Funktionen je mit if(!function_exists()) absichern.

Und Dein Modul-Code bleibt übersichtlich und klein.

als Beispiel (sicher gäbe es bessere Namen für die Funktionen):

if(show_edit_link($section_id) == true){
    echo draw_edit_link($section_id);
}

Und die jeweiligen Funktionen machen die Arbeit im Hintergrund, in der externen Datei.
Und diese Funktionen brauchen gar nicht die Core Klassen-Objekte verwenden. Einfach die Session auslesen und gut ist.

Christian

Last edited by stefanek (15.03.2020 23:08:22)


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#6 16.03.2020 10:59:58

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

Eigene Funktion oder Methoden für so grundsätzliche Sachen halte ich nicht für sinnvoll, man sollte so weit wie möglich Core-Funktionen verwenden. Es könnte sich ja auch mal was ändern im Handling der Session und dann hat man Stress. Da bleibe ich lieber bei meinem gewohnten $wb->dingens();

Code auslagern in externe Funktionen:
Das ist so eine Sache: Wenn ich etwas nur genau 1x brauche, an genau einem Ort, ist eine Function technisch nicht sinnvoll. Schon gar nicht, wenn ich die ganzen Variablen später nochmal brauche; da hab ich dann mehr Overhead als würde ich alles in einer Wurst haben.
Ist vielleicht nicht sehr schön, aber hält.

Ich weiß schon: Viele machen lieber einen knappen Hauptstrang und lagern alles aus. Aber der Code ist ja nicht wirklich weg, er ist nur verräumt. Das Problem mit dem verräumten Code ist, dass er schnell mal aus den Augen, aus dem Sinn ist. Da hinten, in der überquellenden functions.php beginnen die Leichen dann zu stinken.

Ich code mit dem alten Dreamweaver MX, der bietet wenig Unterstützung bei verzweigten Code-Flüssen. Ich muss selbst im Kopf haben, wo was ist. Da ist mir eine lange Code-Wurst lieber als 40 verteilte Häppchen.
Andere verwenden andere Entwicklungsumgebungen, das ändert dann natürlich den Stil und Herangehensweise. Danach kann ich mich aber nicht richten, _ich_ muss damit zurecht kommen.

#7 16.03.2020 12:32:32

stefanek
Developer

Re: Frontend-Edit - Benutzerrechte Abfrage

Ja gut, wenn Du keine Tipps haben magst, was fragst Du dann rum?
Der Core bietet keine Methoden für das was Du brauchst. Und hätte der Core Methoden, die Du brauchst, wären sie für Dich nicht gut genug, weil sie nicht kompatibel zu Wurst CMS sind.

Last edited by stefanek (16.03.2020 13:10:33)


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#8 16.03.2020 14:23:32

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

stefanek wrote:

Ja gut, wenn Du keine Tipps haben magst, was fragst Du dann rum?
Der Core bietet keine Methoden für das was Du brauchst. Und hätte der Core Methoden, die Du brauchst, wären sie für Dich nicht gut genug, weil sie nicht kompatibel zu Wurst CMS sind.

Naja: Der Tipp, eine Function() draus zu machen?
Und welche Methoden bietet mir der Core denn nicht? Das war ja nie die Frage, ist eh alles da. Die Feinheiten waren mir eben nicht so klar und eine 2. Meinung schadet ja nicht.

Wenn du jetzt irgendwelche Methoden in den Core packst, dauert es 3 Jahre, bis ich mich - als Modulautor - darauf verlassen kann. Bis dahin brauche ich eine Fallback-Lösung. Und wenn ich die schon mal habe, brauche ich auch keine neuen Methoden. Vielleicht ein Henne/Ei-Problem, aber wenn ich genug Eier habe, brauche ich die Henne gar nicht. Die allermeisten Leute haben keine Henne ;-)

#9 16.03.2020 15:20:28

stefanek
Developer

Re: Frontend-Edit - Benutzerrechte Abfrage

Sei ehrlich.
Das hat nichts damit zu tun was ich irgendwo reinpacke oder was bei WBCE im Core ist, sondern dass Du nichts anfassen willst, was nicht mit den anderen Systemen kompatibel ist.

Und deswegen kann ich Dir nochmal (zum letzten Mal) den Tipp geben, bau eigene Funktionen dafür.


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#10 16.03.2020 16:33:15

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

stefanek wrote:

...Und deswegen kann ich Dir nochmal (zum letzten Mal) den Tipp geben, bau eigene Funktionen dafür.

Uiui, das klingt ja schon wie: Geh und kauf dir 20 Packungen Klopapier und 10 Flaschen 90%igen
monkey

SInd in den oben erwähnten Funktionen/Methoden Änderungen geplant? wird $wb umbenannt zu $wbce ?
Das wäre natürlich auch ein Teil meiner Frage gewesen.

#11 16.03.2020 16:47:03

stefanek
Developer

Re: Frontend-Edit - Benutzerrechte Abfrage

Mach wie Du willst. Wenn Würste ans Spaghetti dran kleben Dich erfüllt, mach es zu einer Tugend.
Schau ab und zu auf GitHub. Dann erübrigen sich viele Fragen.


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#12 16.03.2020 17:35:28

webbird
Administrator

Re: Frontend-Edit - Benutzerrechte Abfrage

BC2 hat dafür Dwoo-Erweiterungen, die man als Markups z.B. in Templates benutzen kann. Für WBCE wäre die einfachste Lösung vermutlich ein Droplet. (EditThisPage gibt es übrigens schon.)


Ich habe eine Amazon-Wishlist. wink
Erfolgreich vom eigentlichen Problem ablenken kann auch eine Lösung sein.

Offline

#13 17.03.2020 11:30:13

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

Es geht hier NICHT darum, dass man im Frontend einen Link ins Backend hat, um die Seite zu bearbeiten. Das haben viele Templates eingebaut und zur Not gibt es auch Droplets dafür.


Es geht um die Frage: Darf ich dieses Modul direkt im Frontend bearbeiten.

Folgende Module können in einem Overlay im Frontend bearbeitet werden:
Topics, Itemz, (noch was?)
Das ist kein Hexenwerk und ließe sich auch leicht in OFA, NWI oder sonstwas einbauen. Es muss aber immer auf das Modul abgestimmt sein - sprich: Diese Möglichkeit muss in das Modul eingebaut sein.
EDIT: In Tiny Newsletter ist die Option schon vorbereitet.

Diese Module haben (teilweise) direkte Bearbeitungsmöglichkeit im Frontend:
rFG, Teasers, Global Comments, Wunderblock
Wunderblock und rFG sind Mischformen; teils Overlay, teils direkte EIngabe. Teasers - ja: Das ist experimentell.

Und in der Folge - in vielleicht nicht allzu ferner Zukunft geht es um:
WYSIWYG und ein eventuell zu schaffendes Customize Center.

WYSIWYG im Overlay wäre einfach gemacht, aber da wäre es vielleicht überhaupt sinnvoll, den Editor direkt ins Frontend zu integrieren. Wenn das möglich und handhabbar ist.
Ein Customize Center (Farben, Schrift, Logo, Header usw) muss vollständig im Frontend laufen, weil Änderungen sofort zu sehen sein sollen.

Last edited by boeseroeser (17.03.2020 11:51:28)

#14 17.03.2020 13:12:31

webbird
Administrator

Re: Frontend-Edit - Benutzerrechte Abfrage

Ahso. Dann hatte ich das hier mißverstanden: "So ein Button bedeutet noch lange nicht, dass man dann auch tatsächlich etwas ändern kann - er ist nur ein Link ins Backend, sonst nichts." --- "Es geht hier nur darum, ob der EDIT-Link gezeigt werden soll, das bedeutet nicht, dass man mit diesem Link auch etwas tun kann." (Edit: Das mag auch daran liegen, dass ich keines der Module so genau kenne und somit auch nicht die verschiedenen Techniken, die dort angewendet wurden. Ist ja nicht weiter schlimm, ist ja jetzt geklärt.)

Frontend Edit ist nach meiner Erinnerung ein lang diskutiertes Thema, ich glaube, kein WB-Fork (einschließlich WB Classic selbst) hat dafür bereits eine fertige Lösung. Die Dwoo-Plugins in BC2 können sowohl prüfen, ob ein Benutzer angemeldet ist, als auch, ob er auf genau DIESES Modul auf genau DIESER Seite Rechte besitzt. Das Modul kann das dann in seinen eigenen Templates dafür benutzen, um bestimmte Blöcke eben nur dann anzuzeigen, wenn der Benutzer die entsprechenden Rechte hat. Das Berechtigungssystem in BC2 ist aber komplett neu und anders als das in WBCE.

Prinzipiell stimme ich Dir zu, es sollte allgemein verwendbare Core-Methoden hierfür geben; dass jedes Modul sein eigenes Süppchen kochen muß, ist unschön und fehleranfällig. Zudem müßte man X Module anpassen, wenn sich am Berechtigungssystem was Grundlegendes ändert. Eine saubere API kann das abfangen.

Soweit ich Stefanek verstanden habe, gibt es diese Methoden nicht und es sind wohl auch noch keine in Planung.

Insofern sehe ich jetzt zwei Möglichkeiten:

1. Du hast die Antwort auf die Frage bekommen, ob es sowas gibt. (Nein.)
---> Du bist damit zufrieden und bei der weiteren Diskussion geht es Dir um einen Lösungsweg, den Du dann einheitlich in Deine Module einbaust. Du möchtest dann also quasi eine Hilfe zur Selbsthilfe. Natürlich kann der so erarbeitete Lösungsweg auch für weitere Module als Vorlage dienen, sofern die jeweiligen Modulautoren daran interessiert sind.

2. Du möchtest eine Spezifikation für Core-Methoden erarbeiten und evtl. auch mit umsetzen.
---> In diesem Fall müßte Florian eine Aussage darüber treffen, ob und wann er das im Core haben will, und es müßte sich mindestens ein Entwickler finden, der bereit ist, das umzusetzen. Für eine Spezifikation sind obige Beiträge aber schon etwas zu weit in der Technik. Eine Basis für ein allgemein verfügbares Frontend Editing sehe ich persönlich nicht in einem 1.4.x Strang, das ist schon eine größere Nummer. Aber das ist nur meine Meinung, ich bestimme das nicht.

Eine dritte Möglichkeit wäre natürlich, Du möchtest nur die Debatte über Möglichkeit 2 anstoßen, Dich ansonsten aber raushalten.

Vielleicht hilft es, wenn wir Deine Intention nochmal genau spezifizieren, denn wenn die Erwartungshaltung klar ist, ist es auch einfacher, darauf zu antworten. Man redet dann auch nicht so schnell aneinander vorbei, was am Ende alle mehr oder weniger nervt. wink


Ich habe eine Amazon-Wishlist. wink
Erfolgreich vom eigentlichen Problem ablenken kann auch eine Lösung sein.

Offline

Liked by:

florian

#15 17.03.2020 13:35:41

webbird
Administrator

Re: Frontend-Edit - Benutzerrechte Abfrage

boeseroeser wrote:

Ist der aktuelle Nutzer überhaupt angemeldet? Hier verlasse ich mich auf die Core-Funktion $wb->is_authenticated(), die sowohl in WB als auch in WBCE vorhanden ist. Es ist mir wichtig, dass Module da wie dort funktionieren, weil ich sonst bei einer Migration heftige Probleme habe, wenn mir ein Modul nur eine weiße Seite zeigt. $wb->is_authenticated() ist ein Urgestein und wird wohl nicht entfernt werden.

Vielleicht hierzu mal gesondert... Ich schreibe ja auch Hybrid-Module, nur in meinem Fall halt für WBCE und BC1. Ein ziemlich guter Weg ist, die CMS-Methoden in eigenen Klassen zu kapseln, so dass man sich eben nicht auf eine stabile API verlassen muß. Ralf Hertsch hat das z.B. gelöst, indem er in seinen Modulen ein lib-Modul vorausgesetzt hat, in dem sich die Abstraktionsebene befand. Ich weiß, dass manche Modulautoren prinzipiell keine Module voraussetzen mögen, ich will darüber auch keine Grundsatzdebatte lostreten, aber es ist halt durchaus ein eleganter Weg, weil man keinen doppelten Code hat und immer nur eine einzige Stelle pflegen muß.

Egal ob Du nun Deine Abstraktionsklassen pro Modul mitlieferst, oder ob Du sie in ein eigenes Modul steckst und dieses dann voraussetzt, das weitere Vorgehen ist das gleiche. In obigem Beispiel willst Du die CMS-Methode is_authenticated() kapseln. Also baust Du Dir eine Klasse, nennen wir sie (bzw. den Handler) mal $chio, und definierst in dieser Klasse eine Methode is_autheticated(). Derzeit ist der Code simpel:

[== PHP ==]
public function is_authenticated() {
    global $wb;
    return $wb->is_authenticated();
}

In Deinem Modul verwendest Du dann $chio->is_authenticated() statt $wb->is_authenticated().

Klingt nach Overhead und ist es im Prinzip auch, jedenfalls so lange es das Objekt $wb und dort die Methode is_authenticated() gibt. Nun aber mal angenommen, das WBCE Team würde sich entscheiden, alle Methodenamen künftig in Camel Case Schreibweise zu ändern. Dann würde aus is_autheticated() zum Beispiel isAuthenticated(). Dann müßtest Du in Deiner Abstraktionsklasse nur die Methode anpassen:

[== PHP ==]
public function is_authenticated() {
    global $wb;
    if(defined('WBCE_VERSION')) {
        return $wb->isAuthenticated();
    }
    return $wb->is_authenticated();
}

Ob es die Konstante WBCE_VERSION gibt, weiß ich nicht, bei meinen Klassen wäre es CAT_PATH oder CAT_VERSION, auf die ich prüfe, um die CMS zu unterscheiden. Man braucht halt irgendein Kriterium, welches, ist letztlich egal. Im aktuellen Beispiel könnte man genausogut auf is_callable() prüfen statt auf die Konstante. (Oder auf method_exists(), je nach Bedarf.)

Ähnlich wäre es, wenn das WBCE Team entscheidet, künftig statt $wb $wbce zu verwenden. (Ohne jetzt auch die Methoden anders zu nennen.) Dann gäbe es keine Globale $wb mehr. Auch kein Problem:

[== PHP ==]
public function is_authenticated() {
    global $wb, $wbce;
    if(is_object($wbce)) {
        return $wbce->is_authenticated();
    }
    return $wb->is_authenticated();
}

Das kannst Du jetzt beliebig weiter spinnen. Du kannst jetzt Änderungen in der API des jeweiligen CMS begegnen, ohne auch nur eine Zeile Modul-Code zu ändern, indem Du immer nur Deine Abstraktionsklasse(n) anpaßt. Das geht dann natürlich auch, wenn es Änderungen innerhalb des CMS-Derivats gibt (also wenn sich eine API zwischen WBCE 1.4 und WBCE 2.0 ändert). Dann prüfst Du halt auf die aktuelle Version des CMS und handhabst die Änderungen entsprechend.

Das ist IMHO das, was Stefanek weiter oben meinte.


Ich habe eine Amazon-Wishlist. wink
Erfolgreich vom eigentlichen Problem ablenken kann auch eine Lösung sein.

Offline

Liked by:

florian

#16 17.03.2020 13:54:57

webbird
Administrator

Re: Frontend-Edit - Benutzerrechte Abfrage

P.S.: Das alles in ein eigenes Lib-Modul zu packen, das von den anderen Modulen vorausgesetzt und eingebunden wird, wäre ein durchaus praktikable Lösung, weil:

  1. schneller verfügbar als eine vollständige Frontend Editing Lösung

  2. Unabhängig vom CMS, also eben auch in WB Classic verfügbar - was nützt Dir eine Core-Erweiterung in WBCE, wenn Du sie dann in WB nicht nutzen kannst?

  3. Unabhängig von der CMS-Version, dadurch auch in "älteren" CMS-Versionen nachrüstbar

  4. Unabhängig von der Verfügbarkeit von Core-Entwicklern

Einziger Haken ist IMHO, daß man bereit sein muß, ein Lib-Modul vorauszusetzen. Das ist allerdings kein technisches Problem, sondern eins der persönlichen Sichtweise. Andererseits kann es das Lib-Modul ja auch in den Core schaffen, so wie NWI. Dann ist die Voraussetzung in zukünftigen Versionen automatisch erfüllt, kann für ältere Versionen aber auch problemlos nachgerüstet werden.


Ich habe eine Amazon-Wishlist. wink
Erfolgreich vom eigentlichen Problem ablenken kann auch eine Lösung sein.

Offline

Liked by:

stefanek, florian

#17 17.03.2020 14:18:58

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

So irgendwie versteh ich das nicht...
Warum? Warum sollte ich das tun?

Warum sollte ich meinen handelsüblichen Staubsauger über einen ziemlich komplizierten Adapter an eine handelsübliche Steckdose anschließen?
Ist eine Änderung des Staubsaugers geplant? Nein!
Ist eine Änderung der Steckdose geplant? Da bin ich mir mittlerweile nicht mehr so sicher.  yikes

Wenn zb eine Änderung der Klasse $wb auf zb $wbce geplant ist, dann funktioniert kein einziges Modul mehr, und die Hälfte der Templates. Dann muss ich mir um meine paar Module keine Sorgen mehr machen, weil dann geht GAR nichts mehr.

#18 17.03.2020 14:45:26

stefanek
Developer

Re: Frontend-Edit - Benutzerrechte Abfrage

So sehe ich das auch, Bianka.


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#19 17.03.2020 16:05:32

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

Also - Warum?

Warum sollte ich für die Beantwortung einer banalen Frage ein eigenes Framework als Adapter zu WBCE machen?

Zur Erinnerung: Die Frage lautet: Wie stelle ich in der view.php eines Modules fest, ob der aktuelle Nutzer Bearbeitungsrechte für dieses Modul hat.

Und dazu soll ich ein eigenes Lib-Modul machen? Dort soll dann von zb Itemz aus per DB-Abfrage herausgefunden werden, wie das Modul in Section 34 heißt (Antwort: Itemz - klar).

Warum so kompliziert? Gibt es da etwas, was ich bis jetzt nicht kapiert habe?

#20 17.03.2020 16:09:04

webbird
Administrator

Re: Frontend-Edit - Benutzerrechte Abfrage

Chio, Du hast gefragt, das war mein Lösungsvorschlag. Den kannst Du nehmen und für alle zukünftigen Herausforderungen Deiner Cross-CMS-Module gewappnet sein, oder Du machst es wie bisher in jedem Deiner Module anders und frickelst dann bei Änderungen im jeweiligen CMS entsprechend aufwendig zigfach hinterher. Das ist ganz allein Deine Entscheidung. Du hast oben selber beschrieben, dass Du quasi jedes Mal das Rad neu erfindest, insofern dachte ich, es sei Dir daran gelegen, das ein für alle Mal zu konsolidieren und Dir damit die Arbeit künftig wesentlich einfacher zu machen. Habe ich mißverstanden, sorry.

Ich wage zu behaupten, dass die API bei WBCE stabiler ist als bei WB Classic, weil Florian da ein Auge drauf hat und allzu forsche Entwickler auch mal einfängt (mich eingeschlossen), insofern ist das Risiko hier vergleichsweise gering. Für WB Classic wage ich da aus Erfahrung keine Aussage zu treffen - das ist auch mit ein Grund, warum meine Module nur WBCE und BC1 kompatibel sind, nicht WB Classic kompatibel. Wenn sie dort laufen, schön, wenn nicht - na dann halt nicht.

Ich habe bewußt sehr einfache Beispiele gewählt, um den Sinn und Zweck einer Abstraktionsschicht zu verdeutlichen. Du hast z.B. selbst die Frage gestellt, ob ein Umbenennen von $wb in $wbce geplant ist oder nicht. Hättest Du eine Abstraktionsschicht, wie ich sie beschrieben habe, könnte Dir das egal sein. Es könnte Dir auch total egal sein, ob irgendwann das Rechtesystem komplett auf links gedreht wird.

Du hast einen ebenso komfortablen wie simplen (sowie auch üblichen) Lösungsweg, den ich bewußt ausführlich erklärt habe, ebenso bewußt ins Lächerliche gezogen. Kann man machen, wenn man zukünftig keine Hilfestellung und konstruktiven Antworten mehr bekommen will. Ich kann in diesem Fall nur dasselbe sagen, was Stefanek auch schon sagte: Wenn Du keine Lösung willst, dann frag auch nicht danach. Wenn Du zwar eine Lösung willst, aber nicht DIESE, sag höflich: Danke für den Vorschlag, ich glaube aber, für mich paßt das nicht. Dann fühlt man sich wenigstens nicht von Dir für seine Mühen in den A... getreten.

Zumindest kannst Du Dir sicher sein, von mir zukünftig keinerlei Lösungsvorschläge mehr zu bekommen. Ich kann meine Zeit sehr viel sinnvoller verwenden.


Ich habe eine Amazon-Wishlist. wink
Erfolgreich vom eigentlichen Problem ablenken kann auch eine Lösung sein.

Offline

Liked by:

stefanek, florian

#21 17.03.2020 16:48:30

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

webbird wrote:

Du hast oben selber beschrieben, dass Du quasi jedes Mal das Rad neu erfindest, insofern dachte ich, es sei Dir daran gelegen, das ein für alle Mal zu konsolidieren und Dir damit die Arbeit künftig wesentlich einfacher zu machen.

Ja, genau darum geht es: Weil es eine gewisse Unsicherheit gab, wie das am besten zu handhaben ist. Was muss sein, was ist überflüssig, woran sollte man denken. Und: hab ich was übersehen.
Diese Unsicherheit ist jetzt SICHER nicht weniger geworden. Es gab keinen auf dieser Sache bezogenen Vorschlag, sondern nur, dass ich das sowieso alles ganz anders machen muss.

webbird wrote:

Wenn Du keine Lösung willst, dann frag auch nicht danach. Wenn Du zwar eine Lösung willst, aber nicht DIESE, sag höflich: Danke für den Vorschlag, ich glaube aber, für mich paßt das nicht. Dann fühlt man sich wenigstens nicht von Dir für seine Mühen in den A... getreten.

Zumindest kannst Du Dir sicher sein, von mir zukünftig keinerlei Lösungsvorschläge mehr zu bekommen. Ich kann meine Zeit sehr viel sinnvoller verwenden.

Wie lautet nun diese von euch vorgeschlagene Lösung? Ich habe nur beispielhafte Aufrufe von Methoden gesehen, nicht die Methoden selbst.
Also: WAS sollte ich besser machen als die 10 Zeilen Code oben?

Das hier zB als Lösungsvorschlag? Für welches Problem? Dass Stefanek einfach so die Methoden umbenennt?

[== PHP ==]
public function is_authenticated() {
    global $wb;
    if(defined('WBCE_VERSION')) {
        return $wb->isAuthenticated();
    }
    return $wb->is_authenticated();
}

Ist das gemeint, wenn ihr sagt, ich nehme ohnehin keinen Lösungsvorschlag an? Sieht so aus.

#22 17.03.2020 16:55:07

boeseroeser
Guest

Re: Frontend-Edit - Benutzerrechte Abfrage

So, noch was für Stefanek zum löschen:

Ihr habt schlichtweg die Frage nicht verstanden. Die ist ganz einfach und wurde hier schon mehrmals wiederholt.

Stefanek sieht das alles aber nur mehr durch eine speziell getönte Brille, und ich hab so langsam die Schnauze voll davon.
Du - Bianka - hast dich da mit reinziehen lassen, in der Annahme, dass Stefanek da irgendwas weiß dazu. Nein, er hats nicht kapiert, von anfang an nicht.

Wird das hier immer so weiter gehen? Nein. Das wird es nicht.

#23 17.03.2020 16:59:56

stefanek
Developer

Re: Frontend-Edit - Benutzerrechte Abfrage

Der Chio kann nicht lesen.
Und hat stefanek schon am Wochenende in ein unnützes Gespräch verwickelt.
Der raubt Zeit und ist undankbar.


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#24 17.03.2020 17:02:38

florian
Administrator

Re: Frontend-Edit - Benutzerrechte Abfrage

Chio, gelöscht hatte ich, weil Du stefanek persönlich beleidigt hast.
Ich denke, hier ist dann jetzt auch alles gesagt und ich schließe das Thema.

Offline

Board footer

Powered by FluxBB

up