WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: Waldschwein on July 31, 2010, 02:10:03 PM
-
Hallo!
Wahrscheinlich habe ich sämtliche Scheuklappen aufgesetzt und das Problem ist eher mangelndes PHP-/SQL-Verständnis als WB, aber ich möchte trotzdem einmal fragen.
Ich will im Frontend mit den Section_IDs und dazugehörigen Blöcken arbeiten. Das ganze erst einmal in PHP, HTML / JS kommt später.
Die Page_ID bekommt man ja recht leicht über eine Konstante, doch Blöcke und Section IDs sind nicht zuverlässig vorhanden (man könnte zwar jQuery herumbiegen und es über die Section-Anchor auslesen, aber nun gut, das ist ziemlich unzuverlässig, gerade weil die Optionen eine Änderung des Prefix bieten...)
Folgender Code ist schon einmal da:
<?php $sql = 'SELECT `section_id`, `block`, `module` FROM `'.TABLE_PREFIX.'sections` WHERE `page_id` = '.$page_id;
$sect_set = $database->query($sql);
$section_id = $sect_set->fetchRow(); ?>Die Array-Ausgabe (unter print_r) sieht dann so aus
Array ( - => 8 [section_id] => 8 [1] => 1 [block] => 1 [2] => wysiwyg [module] => wysiwyg )
Soweit so gut, gäbe es nicht mehrere Sections auf dieser Seite...
Warum so viel Aufwand?
Ganz einfach, es soll ein Frontend Edit Modul werden, und leider macht hier jedes Modul was es soll. WYSIWYG kann manchmal so aussehen, Topics anders, Form ganz anders. Daher muss man sowohl wissen, welcher Modul-Typ der jeweiligen Section zugeordnet ist, den Block (wäre sinnvoll, einfach dass man diesen hat) und eben auch die Section selbst für URL-Links usw.
Was meine Frage einfach ist:
Wie bekomme ich die Section_ID im Frontend (natürlich nur, wenn jemand eingeloggt ist & Rechte hat) so erhalten, dass ich mehrere Links auf einer Seite setzen kann, wo die jeweils richtige Section_ID ermittelt wird?
Ich habe einen Screenshot angehängt der erklären soll, wie es gemeint ist.
Dass das Form-Modul so etwas "spezielles" braucht ist klar, aber das kann später evtl. auch einmal das Modul selbst ansteuern.
Die URLs / Buttons werden dann mit jQuery an die richtige Stelle platziert, das ist nicht das Problem. Ebenso ist es kein Problem, dass später ja "eigentlich" das ganze Backend geladen wird - es wird einfach alles ausgeblendet, was nicht gebraucht wird in einem Overlay.
Gruß Michael
[gelöscht durch Administrator]
-
Du meinst auf dem Server oder auf dem Client soll die Abfrage laufen?
Server ist ja einfach, in der DB die Tabelle sections where page_id = aktuelle Seite abfragen?
-
Ja, das soll auf dem Server sein - auf dem Client ginge es ja mit jQuery, wenn einige Bedingungen zutreffen (Anker gesetzt & nicht verändert usw.).
Wenn ich aber per select `section_id`FROM `sections`WHERE `page_id`=$page_id anrufe wird zwar (s.o.) eine Section der Seite richtig aufgelistet, aber eben nicht die restlichen.
Habe ich da evtl. einen Denkfehler in den PHP-Arrays? Ich gehe halt aus, wenn eine Seite sagen wir 3 Sections hat, dass die auch dann alle übergeben werden, und man (s.o.) letztendlich ansteuern kann.
Gruß Michael
-
erst mal nachdenken:
Was ist eine Tabelle?
Was liefert eine SQL-Abfrage?
Was liefert fetchROW? (mit Betonung auf Row) ?
beantworte Dir die 3 Fragen und Du hast die Lösung.
-
Dein Code
select `section_id`FROM `sections`WHERE `page_id`=$page_idsollte eigentlich immer alle sections der Seite liefern.
Hast du noch ein limit drin oder gehst du das Ergebnis nicht in einer Schleife durch?
-
Hallo!
Jaja, der Anfänger. :oops: Hat die while Schleife vergessen und nicht richtig geschaut, wo das return innerhalb der Funktion steht... Sorry für die Aufregung, und danke für die Hilfe. Jetzt ist alles im Array, was da reingehört.
Gruß Michael
-
Mir ist nicht recht klar, warum das Pferd von dieser Seite her aufzäumst. Was bringt dir das?
Jegliches Frontend-Edit muss vom Modul her kommen, es muss dafür vorbereitet sein. Über das Abfragen der Sections kommst du gerade dahin, dass du ein Modul zwar im Frontend aufrufen kannst, aber spätestens beim Speichern landest du (derzeit) ganz normal im Backend. Von vielen "Besonderheiten" der Module abgesehen.
-
Mir ist nicht recht klar, warum das Pferd von dieser Seite her aufzäumst. Was bringt dir das?
Jegliches Frontend-Edit muss vom Modul her kommen, es muss dafür vorbereitet sein. Über das Abfragen der Sections kommst du gerade dahin, dass du ein Modul zwar im Frontend aufrufen kannst, aber spätestens beim Speichern landest du (derzeit) ganz normal im Backend. Von vielen "Besonderheiten" der Module abgesehen.
Es gibt eigentlich ein Totschlagargument, und das ist WYSIWYG in Verbindung mit Abwärtskompatibilit ät.
Was bringt Frontend-Edit, wenn es beim meist verwendeten (und bei allen Edits immer bevorzugten) Modul nicht klappt?
Dass das Frontend-Edit vom Modul her kommen muss ist klar, aber zum Beispiel Topics 0.6 hat ja auch ein Frontend-Edit, ohne auf ein externes Modul zurück greifen zu müssen.
Beim Speichern lande ich übrigens nicht im Backend - dafür gibt's ja jQuery - oder sagen wir lieber JavaScript mit dem Modewort AJAX. http://api.jquery.com/category/ajax/
Gruß Michael
-
Beim WYSIWYG-Modul wären die nötigen Änderungen in einer halben Stunde gemacht. Es sind ja nur wenige Dateien betroffen. Vorausgesetzt: Es ist klar, WIE man das machen soll. Da habe ich schon Möglichkeiten aufgezeigt, aber ich kenne die WB-Pläne zuwenig, um hier absolut sattelfest zu sein. Sonst hätte ich es eh schon gemacht ;-)
Außerdem würde ich hier sowieso mehr mit Thorns WYSIWYG-History als "Vorzeige-Kandidaten" liebäugeln, weil Core-Modul-Eingriffe normalerweise Jahre dauern.
Die 2. Sache ist der Behälter, in dem das Ganze dann laufen soll. Der ist unabhängig davon, welches Modul darin läuft.
Da ich wenig jQuery-Erfahrung habe, will ich mir das gar nicht anfangen.
-
Hallo!
Das WYSIWYG Modul kann man natürlich schnell verändern, aber das Problem ist dann einfach, dass man zu viel braucht.
Momentan sage ich, das höchste der Gefühle ein "anständiges" Frontend-Edit zu machen ist das Einbinden von jQuery im Frontend (logisch, sonst geht wenig) und einem PHP-Schnippsel - wohl oder übel auch das manuelle Aktivieren von EDIT_ONE_SECTION, das leider über eine Konstante definiert ist und man hier leider auch nichts mit einem Modul machen kann. Sehr schade - aber gut, ist halt so.
Wenn man jetzt Modulabhängig alles gestaltet, wird das Ganze meiner Meinung nach ein Schuss in den Ofen - wem will man erklären "Um Frontend Edit zu nutzen musst du Modul X aktualisieren, und dann noch Modul Y, usw."
Das ändert nichts an der Tatsache, dass es sinnvoll ist, eine Möglichkeit bereitzustellen "Wenn das Modul bereit ist für Frontend Edit, benutze das auch gefälligst" - aber eben auch "Wenn nicht, nimm Krückenlösung XY".
Das Ganze funktioniert momentan schon ein bißchen - siehe Screenshot. Zwar unschön mit iframe (wegen Rumgebastel kommt der Overlay erstmal später dran) und sonst etwas, aber es funktioniert.
Alternativ könnte man jetzt einfach ein anderes WYSIWYG Modul reinpacken, und das einfach anstatt dem integrierten aufrufen (nein, es betrifft keine Formatierungen, weil die abhängig vom Editor sind, aber nicht vom Modul).
An WB selbst möchte ich nichts ändern, weil mir das zu heiß gestrickt ist. Um das ganze wirklich richtig zu machen, müsste man von Anfang bis Ende das ganze Konzept von WB (aus technischer Sicht) umschmeißen und - mit Verlaub - daran glaube ich nicht. Man könnte natürlich sich den "account" als Vorbild nehmen und einfach alles mal eben doppelt für's Frontend programmieren - aber auch das finde ich viel zu heiß.
Nein, ich denke momentan ist folgendes einfach am Besten:
1.) Frontend Edit Modul wird installiert (ein Admin-Tool) - zeitgleich wird automatisch ein Snippet mitinstalliert - der Benutzer / Admin merkt davon aber nichts (außer er sieht in der Modulliste nach).
2.) Ins Frontend Template muss das Snippet registiert werden (einfach ein <?php frontend_edit(); ?>). Zudem muss entweder WB 2.8.1 unverändert vorhanden sein oder (mit WB 2.8.0 oder folgendem WB 2.8.2) die Konstante "EDIT_ONE_SECTION" in der framework/initialize.php auf true sein. (Leider ist das ganze so verstrickt, dass ich heute noch drüber rätsel, was eigentlich das ganze macht - ist schade, aber nun gut. Wäre viel sinnvoller, dass man auch "extern" die Möglichkeit hat, es zu überschreiben). Natürlich muss "irgendwie" jQuery auch im Frontend vorhanden sein.
3.) Im Admin-Tool (tool.php) kann ich ein paar Funktionen an und ausknipsen. Das ganze wird in der Datenbank gespeichert und an die fedit_functions.php übergeben.
4.) Die fedit_functions.php besteht aus ein paar Funktionen. Die eine holt sich die Werte aus der Datenbank, eine andere
stellt jQuery zur Verfügung (ja, eine Krücke, aber erstmal bleibt es so, kann man später evtl. auslagern), eine andere rödelt durch die aktuelle Seite und stellt die ganzen Sections zur Verfügung (mal gucken, wie das alles noch mit Sicherheit aussieht, WB 2.8.2 hat hier auch ein paar interessante Funktionen wie "section_is_active", die schon Einzug halten sollten). Die eigentliche Funktion dann holt sich die Page_ID, und spuckt alles der Reihe nach aus. Die Section_ID wird als Link an die URL drangehängt.
5.) Noch bin ich nicht soweit - aber gibt es eine "frontend_edit.php" (o.ä.) eines Moduls wird die anstatt der Backend-URL aufgerufen.
Gibt's ja wieder ein Problem - wie weiß das Frontend-Edit welche Section welches Modul hat und ob das Modul die frontend_edit.php überhaupt hat? "Einfach so" geht das nicht - auch hier muss es in der Datenbank herumwälzen. Ich wüsste zumindest keine gescheite, andere Sache. Außer halt wie bei Topics, dass der Edit-Button irgendwie abgefangen wird. Aber ohne eine PHP-Schnittstelle (API) geht das alles ja nicht.
Um die Buttons zu stylen gibt's eine frontend.css, zudem sollte später natürlich alles auch in eine frontend.js reingeschrieben werden, damit keiner in den PHP-Dateien herumpfuschen braucht.
Natürlich - Feinheiten und auch einige "Grobheiten" müssen unbedingt noch fertig werden, evtl. muss man sogar im Backend-Theme eine JavaScript Datei einbinden.
Gruß Michael
[gelöscht durch Administrator]
-
Hallo!
Ich hänge jetzt einmal die aller erste Alpha Version an meiner (naja...) Künste.
Was nicht funktioniert
- Leider wird die Section-ID bei mehreren Sections auf einer Seite nicht nacheinander ausgegeben. Ich habe mit foreach() um mich geschmissen, aber irgendwie nimmt er egal was ich mache entweder das erste oder letzte Element - oder alle, nur dann bei jeder Section alle, aber nicht nacheinander.
- Die Pop-Ups passen sich je nach Browser nicht immer ganz korrekt an. Firefox sollte gehen.
- Die Pop-Ups wandeln sich nach einer Aktion (z.B. speichern) in ein Vollbild um, und das Frontend verschwindet. Daher ist es erst einmal per Standard deaktiviert - in dem Admin-Tool kann man anknipsen. Das ganze scheint wohl doch ein bißchen die höhere Kunst zu sein von JavaScript - wenn sich einer auskennt damit wäre super. Momentan geht es per AJAX, nicht per iframe. Es hat alles seine Vor-und Nachteile, die Methoden sind unglaublich vielfältig wie man es machen kann, aber wenn man gescheit die Overlay Funktion machen will reicht ein einfaches Tutorial irgendwo im Netz einfach nicht aus.
- Es gibt noch keine Schnittstelle für Add-ons - ich weiß momentan einfach nicht, wie man eine Verbindung zustande bringen sollte. Frontend-Edit müsste erst mühsam in der Datenbank das jeweilige Add-on zur Section suchen, dann nachfragen. Oder das Add-on stellt selbst die Verbindung her, aber da müsste dann jemand sagen was er davon hält.
- Noch keine "richtigen" Abfragen, wer welche Section bearbeiten kann und welche aktiv ist (muss noch kommen).
Was man braucht
- WB ab Version 2.8.0 (es kann auch drunter gehen, aber nicht getestet)
- jQuery im Frontend, register_modfiles js/css.
- Aktiverten Anker bei jedem Abschnitt im Frontend (mit class="section_anchor")
- Einen PHP-Code irgendwo <?php frontend_edit(); ?>
- Viel Geduld, Augenzudrücken und Einfühlvermögen für Programmier Coder Buchstabenaneinande rreiher
Was klappt
Einfach selber gucken - wurde genug gesagt.
Gruß Michael
-
Ändert das Teil irgendwas an WB?
Ich habe hier sehr seltsame Effekte - auch nachdem ich das Modul wieder entfert habe.
-
Ändert das Teil irgendwas an WB?
Ich habe hier sehr seltsame Effekte - auch nachdem ich das Modul wieder entfert habe.
Eh, nein... Was macht es denn?
-
Habs gefunden: Es hängt ein "nyroModal.css" rein, das die class="header" auf display:none" setzt.
Da mein Template _auch_ eine Klasse "header" hat, gift es hier Wickel.
-
So, jetzt hab ich soweit reinhehängt.
Sollte da etwas in einem Fensterchen aufgehen? Ich habe einfach nur Links direkt ins Backend.
Was genau muss da jetzt eigentlich im Header stehen? register_frontend_m odfiles('jquery'); auch? Noch was?
-
Ein Fensterchen geht nur auf, wenn in den Admin-Tools (Verwaltungsprogramm e » Frontend Edit) "Ändern jeden Abschnitts:" und "Pop-ups oder Overlays:" auf Anzeigen steht - per Standard ist das einmal deaktiviert.
register_frontend_m odfiles('jquery'); sollte da stehen, wenn man (seit WB 2.8.1) eben auf die WB eigene Lösung setzen will. Das war es dann auch - halt noch <?php frontend_edit(); ?> in der index.php vom Template, aber das steht auch schon mal in den Admin-Tools.
Gruß Michael
-
Ich kanns drehen und wenden, wie ich will: Es geht kein Fenster auf. Ich komme immer nur direkt ins Backend.
Hast du mal ein template, bei dem es funktionieren sollte?
-
Aber so nebenbei:
Dass das Fenster nach Aktionen verschwindet und man im Backend landet hat einen banalen Grund: Target="_top".
Das steckt im Admin-Template so drin. success.htt
Und ein paar andere Stellen, je nach Modul.
-
Hmm - da könnte man jetzt herumrätseln, ich habe es extra noch auf einer anderen Seite (anderer Server, anderes PHP, andere WB Version, anderes Template...) installiert. Die eine verwendet andreas00 Template (aber stark angepasst), die andere das round aus der aktuellen SVN.
Es sollte aber grundsätzlich nichts mit dem Template zu tun haben. Hast du denn bei jeder Section einen Button oder nur oben in einer Reihe?
Wenn nicht wäre es sinnvoll, dass du einmal im Seitenquelltext nachguckst.
- Führt die Suche nach "nyromodal" zu Ergebnissen? Sie sollten in einem JavaScript Code stehen.
- Gibt es einen Link wie "admin/pages/modify.php?page_id=1&wysiwyg=51" im jQuery / JavaScript Code?
Das mit dem target="_top" muss ich mir mal angucken. Soweit hab ich dann doch nicht gedacht. Solche Sachen kann man aber mit jQuery abschalten - nyromodal (das Overlay-Modul) hat so viele Funktionen, ich muss mich hier erst einmal halbwegs durchbeißen.
Dass das .header ausgeschaltet wird, war ein Denkfehler meinerseits. Das Komma schließt ja alles ab. Kann man umgehen, in dem man aus
div#nyroModalWrapper .menu, .header { display: none; }
eben
div#nyroModalWrapper .menu, div#nyroModalWrapper .header { display: none; }
macht.
Das ganze bewirkt, dass im neuen Fenster eben das Menu & der ganze Header aus dem WB-Backend verschwindet, und so wesentlich weniger Probleme auftreten (sollten), und - wenn Edit_One_Section eben auf "true" gesetzt ist im WB-Framework man sogar erstmal einen Eindruck bekommt, wie "echtes" Frontend-Edit aussehen könnte. Die CSS für das Fenster wird übrigens aus dem Frontend - nicht aus dem Backend hierfür genommen.
Gruß Michael
-
Naja, natürlich hat es was mit dem Template zu tun, wenns nicht funktioniert. Hängt ja davon ab, wie der ganze jQuery-Krempel eingebunden ist.
Wenns einfach nicht funktioniert, sucht man sich da zum Krüppel.
-
Gut.
Sektion-Anker (WB Optionen!) ist auf Standard "wb_" eingestellt.
Meine round index.php:
<?php
// prevent this file from being accessed directly
if (!defined('WB_PATH')) die(header('Location: ../../../index.php'));
// TEMPLATE CODE STARTS BELOW
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=<?php
echo defined('DEFAULT_CHARSET') ? DEFAULT_CHARSET : 'utf-8'; ?>" />
<meta name="description" content="<?php page_description(); ?>" />
<meta name="keywords" content="<?php page_keywords(); ?>" />
<?php
// automatically include optional WB module files (frontend.css, frontend.js)
if (function_exists('register_frontend_modfiles')) {
register_frontend_modfiles('css');
register_frontend_modfiles('jquery');
register_frontend_modfiles('js');
} ?>
<link rel="stylesheet" type="text/css" href="<?php
echo TEMPLATE_DIR; ?>/template.css" media="screen,projection" />
<link rel="stylesheet" type="text/css" href="<?php
echo TEMPLATE_DIR; ?>/print.css" media="print" />
<title><?php page_title('', '[WEBSITE_TITLE]'); ?></title>
</head>
<body>
<table cellpadding="0" cellspacing="0" border="0" align="center" class="main" width="750">
<tr>
[...]
<td class="content" width="600" rowspan="2">
<?php frontend_edit();
page_content(); ?>
</td>
</tr>
</table>
</body>
</html>
Meine andreas00 index.php:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="description" content="<?php page_description(); ?>" />
<meta name="keywords" content="<?php page_keywords(); ?>" />
<link rel="stylesheet" type="text/css" href="<?php echo TEMPLATE_DIR; ?>/andreas00.css" media="screen,projection" />
<link rel="stylesheet" type="text/css" href="<?php echo WB_URL; ?>/include/jquery/plugins/jquery-ui.css" media="screen,projection" />
<?php
if(function_exists('register_frontend_modfiles')) {
register_frontend_modfiles('css');
} ?>
<title><?php page_title(); ?></title>
<script language="JavaScript" type="text/javascript">
//<![CDATA[
var URL = '<?php print WB_URL ?>';
var WB_URL = '<?php print WB_URL ?>';
var TEMPLATE_DIR = '<?php print TEMPLATE_DIR ?>';
//]]>
</script>
<script type="text/javascript" src="<?php echo WB_URL;?>/include/jquery/jquery-min.js"></script>
<script type="text/javascript" src="<?php echo WB_URL;?>/include/jquery/jquery-ui-min.js"></script>
<script type="text/javascript" src="<?php echo WB_URL;?>/include/jquery/jquery-insert.js"></script>
<?php
if(function_exists('register_frontend_modfiles')) {
register_frontend_modfiles('js');
} ?>
</head>
<body>
<div id="wrap">
[...]
<?php ob_start(); // start output buffer
frontend_edit();
page_content(2); // call content
$foo=ob_get_contents(); // put outputbuffer in $foo
ob_end_clean(); // clear outputbuffer
[...]
?>
</div>
</body>
</html>
Die zweite ist die "kein register_modfiles.j query Lösung, da WB 2.8.0.
Die erste ist die komfortable >= WB 2.8.1er.
Wichtig ist die Reihenfolge im <head>
1.) Alles CSS
2.) Alles jQuery
3.) Alles JavaScript
Gruß Michael
-
Hallo Michael,
ziemlich cooler Ansatz.
Ich habe nicht viel Zeit zum Testen, aber ansatzweise funktioniert es.
Einfach als Feedback:
Die Sections lassen sich eineln in einem "Modal" aufmachen und editieren. Beim Klick auf "Abbruch", komme ich zurück auf die Seite - Beim Klick auf "Speichern", komme ich (leider) ins Backend, nachdem die Modal-Box verschwunden ist.
Leider wird auch nicht ALLES aus dem Backend_Theme in der Modal-Box Ansicht rausgefiltert (siehe ScreenShot).
Das gefällt mir aber sehr vom Ansatz her!
//EDIT: bei mehreren Sections wird für die Links jeweils die letzte im Array genommen (?)
Gruß,
Stefek
[gelöscht durch Administrator]
-
Hallo Stefek,
danke für das Feedback.
Das mit dem letzten Link im Array ist bekannt - leider hat es bisher an meinen bescheidenen Programmier-Kenntnissen gelegen, dass ich keine Lösung hierfür gefunden habe.
Ich stelle einfach mal einen Codeauszug hier rein, evtl. kennt jemand die Lösung dazu.
<?php
if (!function_exists('sections_on_page'))
{
function sections_on_page()
{
global $wb, $database, $HEADING;
if ($wb->is_authenticated())
{
$is_admin=false;
$page_id =PAGE_ID == 0 ? $wb->default_page_id : PAGE_ID;
$sql ='SELECT `section_id`, `block`, `module` FROM `' . TABLE_PREFIX . 'sections`';
$sql .='WHERE `page_id` = ' . $page_id . ' ORDER BY `position`';
$sect_set=$database->query($sql);
while ($sections=$sect_set->fetchRow())
{
$section_array[]=$sections['section_id'];
}
return $section_array;
}
}
}
if (!function_exists('fedit_jq_section_edit'))
{
function fedit_jq_section_edit()
[...]
{
$fedit_jq=WB_PATH . '/modules/frontend_edit/frontend_snippet/fedit_jq_overlay.js';
}
[...]
if (file_exists($fedit_jq))
{
$get_jq_file =get_fedit_file($fedit_jq);
$feditget_section='<script type="text/javascript">' . $get_jq_file . '</script>';
$section_array =sections_on_page();
$fedit_section =$feditget_section;
$store_modify ='';
foreach ($section_array as &$value)
{
$store_modify
= '<a href="' . ADMIN_URL . '/pages/modify.php?page_id=' . $page_id . '&wysiwyg=' . $value
. '" class="fbox" title="' . $HEADING['MODIFY_PAGE'] . ': ' . $value . '"><img src="' . WB_URL
. '/modules/frontend_edit/images/edit_16.png" alt="' . $HEADING['MODIFY_PAGE'] . '" /></a>';
unset ($value);
}
foreach ($section_array as &$value)
{
$fedit_replace = str_replace('replace', $store_modify, $fedit_section);
return $fedit_replace;
}
}
}
}
}
?>
In der fedit_jq_overlay.js ist folgener jQ-Code:
if (jQuery) {
jQuery(document).ready(function() {
if($(".section_anchor").length) {
$(".section_anchor").after('replace');
// ++++ Das ist das Replace in der PHP Datei, das per str_replace ersetzt wird ++++
};
[...]
});
};
Der Klick auf das Speichern ist noch ein kleines Problem - ich werde auf jeden Fall rumbasteln, in der Priorität 1.) Backend-Theme unabhängig -> wenn es nicht geht 2.) Einbinden von einer kleinen Datei in das Backend-Header oder in den jQuery Ordner des Backend-Themes. Auf jeden Fall mal den Tipp von chio ausprobieren mit dem target.
Gruß Michael
-
$sql ='SELECT `section_id`, `block`, `module` FROM `' . TABLE_PREFIX . 'sections`';
$sql .='WHERE `page_id` = ' . $page_id . ' ORDER BY `position`';Meine rudimentären SQL Kenntnisse sagen mir, dass nach SELECT auch position stehen muss und dass bei ORDER BY `position` die Gänsefüßchen weg müssen.
-
Zur Info!
Meine rudimentären SQL Kenntnisse sagen mir, dass nach SELECT auch position stehen muss und dass bei ORDER BY `position` die Gänsefüßchen weg müssen.
Sind keine Gänsefüsschen sondern sogannte Backticks. (identifier quote character)
zum Nachlesen
http://dev.mysql.com/doc/refman/5.0/en/identifiers.html (http://dev.mysql.com/doc/refman/5.0/en/identifiers.html)
Dietmar
-
Hallo!
Danke dafür. Ich habe dann wohl einen Fehler gemacht. Was ich bezwecken wollte ist eigentlich, dass die Section_IDs nach der Position der SQL-Spalte "position" ordnen. Ich meine, das funktioniert auch - oder habe ich irgendwo doch einen Denkfehler?
Eigentlich habe ich mich hier an die Aufrufe wie sie auch im WB-Core vorhanden sind gehalten, und das wird hier auch nach demselben Schema gehandhabt - und die funktionieren ja eigentlich immer problemlos (z.B. admin/pages/sections.php Zeile 210 ff.).
So, ich schaffe es jetzt, das Fenster aufzurufen und "abzuschießen", ohne dass man irgendwas vom Backend sieht. Dazwischen gibt's noch das klitzekleine Problem, dass keine Daten übertragen werden. Das Problem ist AJAX.
Ja, man könnte iframe nehmen - nur da muss man leider wirklich an WB Core herumfurwerken, und genau das möchte ich vermeiden.
Da stand mal was mit AJAX - isse schwerer als gedacht.
Sicherheitskonzept von WB wird natürlich nicht umgangen dabei - ist ja gar nicht möglich, mit JavaScript PHP zu umgehen.
Und da finde ich das von der aktuellen SVN auch wirklich gut, drum ist es ja auch schon dabei als Klassen-Erweiterung.
Gruß Michael
-
Hallo!
Ok, jetzt bin ich an dem Punkt angelangt, wo ich schon vor einigen Monaten hinwollte / angedacht habe: Eine externe Schnittstelle muss her für etwas wie AJAX (JSON, REST, ...)
Ich meine, das Modul würde auch so gut funktionieren - muss halt nur noch die Section_ID richtig durchlaufen & ausgegeben werden. Dann gibt's einen Link zum Backend (wenn die Overlay-Funktion abgeschaltet ist im Admin-Tool) und fertig.
Doch mit richtigem Overlay gibt es einfach ein paar Probleme, und über normale Wege kommt man (oder bloß ich?) nicht weiter.
Vor allem:
Wie wird nach korrektem Übermitteln das Fenster abgeschossen? Irgendwo ist da der Haken drin - entweder wird korrekt übermittelt (dann ist man im Backend) oder es wird korrekt geschlossen (dann wird aber nicht übermittelt), aber beides geht (ohne große Verrenkungen) nicht.
Daher muss wohl oder übel das ganze über - bisher komplettes Neuland für WB - GUI-unabhängige Sachen laufen. Also eben AJAX.
"Hole Feld X, Feld Y, Textfeld ABC, sende alles weiter". Irgendwie geht das wohl mit der safe.php vom WYSIWYG Modul schon ein bißchen, doch wie es scheint fehlt einfach etwas.
Aussehen im JavaScript tut's so:
$(":input").submit(function() {
var form_page_id = $('input[name=page_id]').val();
var form_section_id = $('input[name=section_id]').val();
var textcontent = $('textarea[name=content'+form_section_id+']');
var data = textcontent.val();
var url = "save.php";
// Mit http:, www. oder WB_URL / WB_PATH kommt man nicht weiter - externes geht mit AJAX nicht - Sicherheit!
$.ajax({
url: url,
type: "POST",
data: data,
success: function (reqCode) {
// Wenn die safe.php des Moduls einen korrekten (1) Code bekommen hat tue dies, wenn nicht -> Fehlermeldung
if (reqCode==1) {
alert(url + data + ' _____ klappt');
$.nyroModalRemove(); // Damit verschwindet das Fenster
} else {
alert(url + data + ' ______ klappt ...... nicht ...... ');
}
}
});
return false; // Damit wird dem Browser gesagt, er soll nichts tun / nicht weitergehen
});
Hier sollte man sehen, wie in etwa alles abläuft.
Gruß Michael
-
Ich will nicht rechthaberisch wirken...
Dass du zu diesem Punkt kommst, war absehbar. Frontend-Edit muss vom Modul selbst sinnvoll gestaltet sein - unter Benutzung eines bereitgestellten Frameworks.
95% aller Inhalte kommen in typischen WB-Sites aus dem WYSIWYG Modul. Statt dich mit einem biegbaren Besen zwischen den Beinen durch am Kopf zu kratzen, kannst du das auch einfacher haben: Du machst ein paar kleine Änderungen am WYSIWYG-Modul und mit einem 2. Modul stellst du das Framework zur Verfügung.
Und was ist mit weiteren Modulen? Willst du die IDs abfragen, um etwa direkt auf ein Topic zu verlinken? Nur "Topics" selbst kann einen Link zur Verfügung stellen, um etwa direkt einen Kommentar zu bearbeiten. Bakery - das selbe.
Abgesehen davon ist es keine gute Idee, den Admin-Header nur mit display-none auszublenden, weil es trügerisch ist. Jeder Trottel kann ihn einblenden.
-
Frontend-Edit muss vom Modul selbst sinnvoll gestaltet sein - unter Benutzung eines bereitgestellten Frameworks.
Ja, das muss es natürlich. Im Prinzip muss es so einfach gehen wie auch mit dem momentanen WYSIWYG Modul.
Baue ich einen alternativen Editor, rufe ich nur die PHP-Schnittstelle (ja, eine echte API) des Moduls auf, füttere sie mit ein paar Werten, und schon wird aus FCKEditor ein anderer.
Wenn ich jetzt Änderungen am WYSIWYG Modul mache, habe ich ein Problem - was ist mit thorns WYSIWG history, was ist mit Leuten, die aus Prinzip ihr eigenes / das von der SVN haben?
Ich gehe von mir aus - wenn ein Modul so und so viele Änderungen am Core braucht, nutze ich es nicht. WYSIWYG ist (leider) unbestreitbar teilweise im WB Core integriert.
Dann ist nach wie vor die Frage, wie eine gescheite Verbindung zwischen Topics / Bakery und Frontend-Edit zustande kommt. Ich kann genau genommen nicht einmal jeden Abschnitt einzeln ansteuern - selbst das ist schon eine Krücke mit dem Modul. Eine sinnvolle Verbindung geht aber nur mit PHP. Also muss sich ja ein Modul irgendwie "registrieren" bei Frontend Edit und schreien "Hey ich bin da, nimm mich". Ich habe nur eben mich nie grundsätzlich mit den ganzen Themen beschäftigt, aber werde einmal versuchen, Topics & Bakery zu begutachten, zu vergleichen wie man einen Mittelweg findet, um es dem Modulautoren einfach und dem Anwender ohne eine Aktion zu verlangen ermöglicht.
Dass der Admin-Header ausgeblendet wird ist eher ein Leckerli, als ein "Must-Have". Naja, im Grunde ist es schon ein "Must-Have", weil es einfach inkonsequent wäre, mit einem Pop-Up das ganze Backend einfliegen zu lassen, wo die Hälfte des Fensters erstmal mit Zeug vollsteht, das nicht da sein muss. Wer sich jetzt ein Script baut oder die JS-Dateien ändert kann das ja tun - es umgeht ja nichts an WB, wenn jemand Mediencenter nicht sehen soll, kommt er auch mit "display_block" nicht rein...
Edit: Im Grunde wird (bei mir zumindest) gewinnen, was ich a.) irgendwie realisieren kann und was b.) am einfachsten für den Benutzer und am nachvollziehbarsten für einen Modulautoren ist. Zudem soll es halt nichts von WB untergraben. wenn es jetzt wirklich nicht geht, ohne ein Modul zu verändern - dann ist es eben so.
Gruß Michael
-
Den Header auszublenden ist ein MUST:
Erstens braucht er oft mehr Platz als das aufgerufene Formular (zb Kommentare) und zweitens kommt man damit leicht mal wohin, wo der Spaß aufhört. (Nicht wegen Sicherheits-Aspekten, sondern rein vom Handling her)
Und es sieht einfach "uncool" aus, wenn man da offen das Backend sieht.
Es muss eine "genormte" Schnittstelle geben, das habe ich da schon mal angesprochen:
https://forum.WebsiteBaker.org/index.php/topic,18853.0.html
Und in Topics 0.6 ist das an sich schon mal von Modulseite her eingebaut:
https://forum.WebsiteBaker.org/index.php/topic,18792.0.html
--> inc/headcheck.php, der obere Teil.
Aber: Ich schaff das nicht allein - und habe auch keine Lust, irgendwas zu machen und es mir nachher zerfetzen zu lassen. ("Na mach mal, keiner Trottel..")
So schauts aus.
-
Ok, ich hab mal ein Video gedreht, was momentan geht:
http://www.youtube.com/watch?v=UyQjuy-Pykc
Also praktisch alles, nur eben das wichtigste nicht - es wird nichts gespeichert. Da bin ich dran.
Aber so von der Idee her finde ich passt es momentan. Natürlich alles noch in Debug-Modus usw.
Achja, Schnittstelle: Möglichkeiten gibt's viele. Letztendlich wird es wohl darauf hinauslaufen, dass man dem Element im Overlay eine ID / Class geben muss (sagen wir "ajax_overlay") und eben abfragen, ob die API-Datei vorhanden ist.
Wird aber wenn ich soweit bin, dass man was erkennt auf jeden Fall eine Dokumentation dazu geben - und bevor es im Detail verfeinert wird, dass man noch Feedback einholt und evtl. das eine oder andere umbaut.
Gruß Michael
-
Hi Michael,
Also das Video sieht schon mal ganz gut aus.
Mir persönlich würde sogar die "Einstellung" mit Link ins Backend zu der jeweiligen Section ausreichen.
(Zumindest oft, es würde ja schon enorm helfen sich zu orientieren für manche "Editoren-User".)
Abgesehen davon ist es keine gute Idee, den Admin-Header nur mit display-none auszublenden, weil es trügerisch ist. Jeder Trottel kann ihn einblenden
Das finde ich mal nicht so schlimm.
Der wird ja auch im Backend durch die für ihn gesetzten Rechte eingeschränkt - also wird er ohnehin nicht mehr sehen, als wenn er einfach übers Backend reinginge, stimmts?
Gruß,
Stefek
-
Hallo!
Jo, das mit den Links ist halt noch etwas "heiß" - erstmal muss ich die richtige Schleife erwischen, dann gibt's ein weiteres Problem, nämlich Buttons auszublenden, wo der Benutzer keine Rechte hat zu editieren, aber trotzdem die richtige Reihe abzufragen (also auslassen, nicht überspringen).
Wenn man wirklich richtig mit Hand und Fuß rangehen möchte führt natürlich ein Weg im Framework etwas zu ändern nicht herum. Doch das will ich nicht machen - schon gar nicht als Voraussetzung, dass ein Modul funktioniert.
Das Backend wird nicht angetastet, ebenso nicht wie das Rechtesystem. In Zukunft wird es eh den anderen Weg rum gehen - mit entsprechender AJAX-Schnittstelle wird nur das Div angezeigt und nicht mehr ausgeblendet. Da müssen allerdings dann wirklich alle Module angepasst werden. Nur hier sollte es wie immer eine "Krückenlösung" geben, dass es mit normalem, unangetastetem WB funktioniert.
Gruß Michael
-
Ok, kleiner Nachtrag - das mit den richtigen Links ist jetzt erkannt.
Das Problem ist nicht PHP, sondern jQuery. Dem muss man ebenso erklären, durch eine Schleife zu laufen.
Modulberechtigung kann etwas heikel werden, aber natürlich sollte (alleine aus Usability-Gründen) der Editieren-Button ausgeblendet werden, wenn der Editor keine Berechtigung hat, das Modul zu benutzen.
So, momentan stürzt Frontend-Edit ab mit einem Fatal Error, wenn man kein Seitenadmin ist. Wird in der nächsten Alpha-Version behoben sein. (Zudem sollte ich mal vorher lieber gucken, was eine function_exists eigentlich ist :roll: ).
Gruß Michael
-
Hallo Michael,
Modulberechtigung kann etwas heikel werden, aber natürlich sollte (alleine aus Usability-Gründen) der Editieren-Button ausgeblendet werden, wenn der Editor keine Berechtigung hat, das Modul zu benutzen.
Vielleicht kann Dir dieser Link und dieses Snippet etwas helfen:
https://forum.WebsiteBaker.org/index.php?topic=18796.0
Schau mal rein.
(Zudem sollte ich mal vorher lieber gucken, was eine function_exists eigentlich ist :roll:)
:-)
Das ist eine Funktion, die überprüfen soll, ob eine Funktion existiert.
Man verwendet es, um zu verhindern, Funktionen aufzurufen, die möglicherweise nicht existieren.
Es wird auch verwendet, indem man schaut, ob eine Funktion bereits existiert, BEVOR man sie kreiert - das soll verhindern, dass Funktionen doppelt und dreifach kreiert werden.
Ist so ähnlich wie defined(), nur dass dieses sich auf Konstanten bezieht.
Oder war das jetzt ein Joke? :-P
Gruß,
Stefek
-
Oder war das jetzt ein Joke? :-P
Das war ein Joke, weil ich es falsch übernommen habe, und es sinnlos ist, mit function_exists Funktionen einer Klasse aufrufen, weil das gar keine Funktionen, sondern Methoden sind.
Das Snippet guck ich mir mal an, danke.
Gruß Michael
-
Michael goes OOP 8-)
Respekt.
:-)
Stefek
-
Michael goes OOP 8-)
Respekt.
Nö, nicht wirklich - nur fieses OOP-Hacking vom WB-Framework.
Gruß Michael
-
Na, dann pass auf, dass Werner Dich nicht aufspürt :evil:
BTW, finde cool, wie Du Dich da reinfummelst.
Nach CKE wird das ein neuer richtig guter Beitrag zum CMS werden. (Wenn auch nur über einen Simplen Link ins Backend, das allein ist schon sehr viel Wert für die Leuts, denen man die Contents anvertraut).
*thumbsup*
Stefek
-
Im Grunde mache ich nichts anderes, als zwei Methoden, die nur in der aktuellen SVN in der class.wb vorhanden sind bereitzustellen. Also "wenn die Methoden nicht da sind, nimm einfach class.wb282, die die class.wb eben um nicht vorhandenen erweitert". Eben
eines der Grundprinzipien von OOP - Mehrfachvererbung. (Nein, das nicht...)
Jetzt eben noch das reinfummeln, dass es nicht aussieht wie im Screenshot, und dann hat man es. Wobei, hier geht es um wirkliches JavaScript, da muss wohl einiges noch umgeflochten werden. Ich weiß zwar nichts über ob_start() ob das überhaupt hier etwas bringt usw., aber ich mache das mal lieber ohne, sonst gibt's bestimmt bloß Konflikte.
Gruß Michael
[gelöscht durch Administrator]
-
Hallo!
Ich möchte nur sagen, dass mir momentan die Zeit fehlt, das Modul wirklich fertig zu machen - das betrifft leider auch die Section-Links zur jeweiligen Section. Das ganze ist wohl doch größeres JavaScript Geheimnis, ich bin da nicht tief genug drin und hab momentan genug anderes zu tun bei und mit WB.
Der mehr oder weniger letzte Stand der Dinge ist angehängt - war in einem Beitrag mal zuvor.
Ich gehe da von mehreren Wochen aus, die es also noch brauchen könnte - außer natürlich jemand hat bessere Ideen und kann sie einbringen.
Gruß Michael
[gelöscht durch Administrator]