Leaderboard

If I create a search engine in the future, I will call it Kongondo. (Kongondo, even better then Google.)

Thanks, that worked

No, he isn't dead, he is swooning. Help is on the way:

Hi there, well, a few days ago another project of mine went online. I did that homepage for a local voluntary firefighters' club with a friend of mine at the front. My job was to create the technical basement. I used the 960 Grid System framework to do the design and implemented the base templates, my friend created an interface to synchronize the homepage calendar with a firefighters' organizational software he programmed on his own and also did some optical tweaks, Piwik integration and content. http://www.feuerwehr-friedrichshofen.de/ Regards Seuche

I'm using this feature quite a lot. Here's an example of creating a indented list for using with checkboxes, selects. IT creates a new PageArray and modifies the "title" to indent, and here with a (count) used in the context of the categories to see how many products are under that category. $children = $pages->get("/shop/")->children(); $list = new PageArray(); function mylist($children, $ind='', $arr){ $ind .= "– "; foreach($children as $cat) { $countproducts = wire("pages")->find("template=product,categories=$cat")->count(); $cat->title = $ind . $cat->title . " ($countproducts)"; $arr->add($cat); if($cat->numChildren) { mylist($cat->children,$ind, $arr); } } return $arr; } return mylist($children, $ind='',$list); This will produce something like –– Gewürze (0) –– –– Kräuter (27) –– –– Kräutermischungen (7) –– –– Einzelgewürze (0) –– –– –– Anis (2) –– –– –– Blaumohnsaat (1) –– –– –– Bockshornsamen (2) –– –– –– Chili (16) –– –– –– Glutamat (1) –– –– –– Galgantwurzel (3) –– –– –– Ingwer (4) –– –– –– Kardamom (4) –– –– –– Knoblauch (5) –– –– –– Koriander (2) –– –– –– Kurkuma (2)

Diogo and Horst's suggestion to add that bit of code to a template file–temporary–is probably the fastest way to find out what the admin URL is: echo $pages->get(2)->url; Also, double check that you are using a trailing slash on your admin URL.

From the module interface /** * Method to initialize the module. * * While the method is required, if you don't need it, then just leave the implementation blank. * * This is called after ProcessWire's API is fully ready for use and hooks. It is called at the end of the * bootstrap process. This is before PW has started retrieving or rendering a page. If you need to have the * API ready with the $page ready as well, then see the ready() method below this one. * */ public function init();

I think you could modify that PageList label by hooking in after ProcessPageListRenderJSON::getPageLabel. Argument 0 to the method is the $page that you want to get the label from, and the method simply returns the label that will be printed. Here it is if you'd like to take a closer look.

You might want to start by reading these... http://www.flamingruby.com/blog/anatomy-of-fields-in-processwire/ http://wiki.processwire.com/index.php/Module_Creation http://processwire.com/talk/topic/4420-page-list-migrator/ - not directly related, but gives you some ideas about working with json in PW http://processwire.com/talk/topic/2394-how-to-present-your-module/ http://processwire.com/api/modules/ https://github.com/ryancramerdesign/ProcessHello https://github.com/ryancramerdesign/ProcessWire/blob/master/site-default/modules/Helloworld.module http://processwire.com/talk/topic/4410-storing-lists-in-pw-fields/ - not directly related; storing serialized field data in db... I'm not sure what you mean by "it should support the admin also". If you mean you want a GUI for it in the admin, then you are looking at a Process Module, most likely. I suggest to have a look at some of the code of the available modules as well. As for JSON, you can either use PW's wireEncodeJSON method or PHP's native json_encode. The difference between the two is that PW's removes empty vaues.

Ok... now that I see dead avatars, maybe it is time to roll back time.

Ah, sorry - been on 5.4 for so long I forgot about this. Yes, repeaters aren't supported yet. For the moment I'll add that to the list of fieldtypes to ignore so at least there won't be an error. Btw, the last update also now handles RTE links that have been processed by the PageLinkAbstractor module. EDIT: Committed version with those small fixes. NB that the check to ignore repeaters is currently only on the export, so you would need to export again to check.

Or even: echo $pages->get(2)->name

Did you ftp .htaccess and double check ? Was there some upgrade done on the server ? http://processwire.com/talk/topic/4434-pw-not-installing-correctly-admin-not-found/#entry43493 -------------------------------------- Here are a few things to check: setting chmod of /site/assets/sessions/ to 777 from: http://processwire.com/talk/topic/1175-cant-login-to-existing-processwire-site/#entry10427 create the "/site/assets/sessions/" folder new by hand from: http://processwire.com/talk/topic/2786-request-seems-to-be-forged/#entry30109 http://processwire.com/talk/topic/2786-request-seems-to-be-forged/#entry32545 changing the session name from: http://processwire.com/talk/topic/4011-cannot-login-to-admin-area/#entry40203 turn on debug from: http://processwire.com/talk/topic/490-how-to-reset-your-password-how-to-enable-the-forgot-password-function/#entry7987 http://processwire.com/talk/topic/2965-sys-admin-problem-cant-login/#entry29256 reset password from: http://processwire.com/talk/topic/2965-sys-admin-problem-cant-login/#entry35624 http://processwire.com/talk/topic/1736-forgot-backend-password-how-do-you-reset/ http://processwire.com/talk/topic/4144-need-help-locating-or-creating-admin-user/ run mysqlcheck --repair from: http://processwire.com/talk/topic/3643-cant-access-login-on-existing-site/#entry35697

Me again. I glimpsed at what you already done with that "wrapper". I now got it working for TinyMCE links plugin. So it will create localized urls when selecting from the page tree. I had to modify a couple files to add a langID option to ProcessPageList and ProcessPageEditLink. Should I just make a pull request with those changes so you can look at and test? Edit: Pull Request done https://github.com/ryancramerdesign/ProcessWire/pull/241

Little update on dev branch: The default admin theme now comes with an autocomplete search. If you are superuser, it will include templates, fields and users in the search as well. Once 2.4 goes stable, I'll assist with implementing this in other admin themes too.

By default, the "Forgot Password" module is not turned on in v2.1. My thought was that lack of such a function is technically more secure (on any site or CMS). Why? Because having such a function active means your password is only as secure as your email (*though see note at end of this message). So I thought we'd start things out as secure as possible and let people adjust it according to their own need. But I'm rethinking that decision, and may change it to be 'on' by default. If you don't already have that "Forgot Password" module installed, it is relatively easy to reset your password with the API. Lets say that you lost the password for your account named 'admin' and you wanted to reset it. Paste this code into any one of your templates (like /site/templates/home.php in the default profile, for example): <?php $admin = $users->get('admin'); $admin->setOutputFormatting(false); $admin->pass = 'yo12345'; // put in your new password $admin->save(); …or if it's easier for you to copy/paste everything on one line, here's the same thing as above on one line: <?php $users->get("admin")->setOutputFormatting(false)->set('pass', 'yo12345')->save(); Replace "yo12345" with the new password you want and save the template. Then view a page using that template (like the homepage, in our example). The password for that account has now been reset, and now you are ready to login. Don't forgot to now remove that snippet of code from the template! Otherwise your password will get reset every time the page is viewed. Once logged in, here's how to install the Forgot Password capability: 1. Click to the "Modules" tab. 2. Scroll down to the "Process" modules. 3. Click "Install" for the "Forgot Password" module. That's all there is to it. You will now see a "Forgot Password" link on your login page. *ProcessWire's "Forgot Password" function is actually a little more secure than what you see in most other CMSs. Not only do you have to have the confidential link in the email, but the link expires in a matter of minutes, and PW will only accept password changes from the browser session that initiated the request. So an attacker would have to initiate the password change request and have access to your email at the same time, making it a lot harder for a man-in-the-middle snooping on your email.

Font Awesome Page Label (almost stable version) Yet another PageListLabel module, why? Font Awesome is really awesome, hundreds of high quality icons, ready to use. (Don't we all know how cool icon fonts are.) I wished to use icons in conjunction with the other PageList modules out there. (Page List Better Labels, Page List Image Label & Page List Show Page Id ) I wanted the possibility to style the icons individually with CSS. Showing icons triggered bij template name, but can be overruled bij Page ID. (Trash Page, 404 Page not found etc.) I wanted a better file or folder indication in the PageList tree. Download: github modules directory

No, the fastest way is echo '<a href="'.$pages->get(2)->url.'">this way to the admin</a>';

Hi folks, I'm new to ProcessWire, and I'm currently evaluating it for use in an upcoming project. The reviews and write-ups I've read online have said great things about it, and from what I've seen so far, I'm really rather impressed. I've spent a lot of time using Laravel, CodeIgniter, and CakePHP, all of which make use of the MVC pattern, however, PW doesn't do this, and therefore I'm looking for some advice on how best to structure my PW applications... Reading around, I've found some write-ups which cover form handling and validation, but I'm unsure quite *where* these files should live, and I'd love some advice on how best to structure my application. Do I create a template which contains form-handling code *and* HTML (all in the same file -- like "classic PHP"), or can I separate my form handler/validation code from my markup (and have the HTML form post to a PHP script somewhere else)? Or maybe there's another way (perhaps using Modules) that I'm unaware of? If it helps, I'm /usually/ the "backend guy" on the projects I tend to work on, and I work closely with front-end chaps (designers mostly) who throw together the HTML, so if there is a way to keep the markup and processing logic loosely coupled, I'd love to hear about it! Anyway, thanks for taking the time to read this, and I really would appreciate any wisdom you kind people have to offer. Many thanks!

I've been using the option "Custom PHP code to find selectable pages" today and didn't realise quite how powerful that was (a real "D'oh!" moment there!). Something I do find reasinably often is that I want to display custom page titles in the page tree more and more for certain projects and, whilst concatenation is nice, it would be extremely useful to be able to use something similar to generate the titles. For example, in one case I've got some pages that have categories attached to them whilst the pages themselves are simply named 1-infinity, but I'd like to pad the number with zeros. It would be great to be able to create a title based off something like this: return $page->category->prefix . str_pad($page->name, 4, 0, STR_PAD_LEFT) . $page->title; There are other more complicated examples with IF ... ELSE where it checks something from the parent page if a value in the current page is set, but this one is a relatively simple example to post. Is this possible, or could it potentially introduce too much overhead in the page tree?

Thanks Ryan! I will investigate that route. This clarified a lot.

getQueryAllowedTemplates is basically a way to bypass inclusion of pages that use templates the user doesn't have access to. It deals with what pages will be allowed to be returned in a find/get result, and not anything to do with edit access. I tend to think you'd be better off going less low level than that. If the goal is to get things working right with count and pagination, then I think this can be bolted on to how the CustomPageRoles already works. Pretty much all page queries get routed through $pages->find() (including $pages->count()), so you can take advantage of that by hooking in before it and modifying the selector string (argument 0) to limit the found results to those within the users view access. For example, you might append "view_roles=$user->roles" to that selector string. That's a theoretical starting point at least. But if you'd prefer to do something like getQueryAllowedTemplates, let me know and I can make that method hookable (and thereby replaceable).

Welcome @peterofeng I'm not sure I understand <div> {$page->title}</h3> <ul> <li>Sub item 1</li> <li>Sub item 2</li> <li>Sub item 3</li> </ul> <div> <div> {$page->title}</h3> <ul> <li>Sub item 1</li> <li>Sub item 2</li> <li>Sub item 3</li> </ul> <div> This isn't a 2 level navigation. And the UL you could generate with the module but just for a simple navigation like this you could make it with your own simple foreach code. <ul> <li>item 1</li> <li class="even">item 2</li> <li>item 3</li> <li class="even">item 4</li> </ul> Same with this. It isn't supported by the module, but you could simply use css nth-child(odd) or jQuery to produce this. Not exactly sure, but you could try: 'selector' => 'parent!=1022|1002'

Good links from Kongondo there. I also want to mention that if you like to learn by example, have a look at Adrian's FieldtypePhone and/or FieldtypeMapMarker modules in the modules directory (among others). These are Fieldtype and Inputfield combinations that present objects as their value, similar to what you are talking about. The big difference in your case is that your need is simpler (though not as DB friendly), because you'll be bundling it all up into a single JSON string. The place where you would convert your object into a JSON string is in your Fieldtype's sleepValue() method, and the place where you'd convert it from a JSON string to an object is in your Fieldtype's wakeupValue() method.

I had to setup a similar thing for the cmscritic.com site. Previously it had been running WordPress, which had all the articles living off the root URL. We wanted the new site to maintain all the same URLs as the WordPress site, rather than setting up 301s. So all the articles still live off the root URL, despite the fact that they are actually located within the tree. This is the case for other pages in the site as well. As an example of how to do it, see the cmscritic case study, and the /site/templates/home.php template file code in particular.

Since you are comfortable with using the MVC pattern, this may be the way you want to go in ProcessWire too. ProcessWire is very much supportive of the MVC pattern, it's just that it doesn't require it. ProcessWire is providing your models, your template files provide your controllers, and you provide the views with the TemplateFile class (or some other view loader of your own if preferred). You can also choose to target some template files/pages as views and call $page->render() on them. If you are interested, the Blog profile does use an MVC-style approach and would be worth looking at. But after you spend some time with ProcessWire, I recommend finding the approach that best suits a particular situation rather than locking yourself down to using the same one all the time. ProcessWire is giving you a lot more in some areas than a typical MVC framework does, so you may find even faster and more maintainable ways to structure your code, depending on the situation.

Ryan, I am building new set of modules, that will create user access management easier for clients. Current way with roles, permissions and template access is fine for most needs, but very common scenario for our clients is "I want to allow these 5 groups of users to view this branch of pages and then these 3 groups of users to edit and add those pages". I cannot open the template editing, or start talking about roles and permissions to our clients - it is way above of their needs and thinking. What they want is to go into a page and choose groops that can view and choose groups that can edit this page and below it. To solve this I thought ideal would be to introduce new "term" to PW user management: groups. Groups just collect users directly or by tieing users into groups through roles (so you can say that all users that have role "editor" or "superuser" belong to group "site editors"). This part I have already figured out and working nicely. Now I am back basicly what CustomPageRoles does: altering the current way of user access. This time I want to go deeper - I want to check user access in DB query level. I need all working right: count and pagination also. This probably means keeping own version of "pages_access" table and altering how PageFinder filters results. It would be very helpful for me, if you can describe little more how getQueryAllowedTemplates works and what it does? If I read the code correctly, it checks the allowed templates and based on that, it filters results. I think what makes it difficult for me to follow, I am not 100% sure how static properties work there . When moving from template based ua to page based, would it be enough to replace getQueryAllowedTempaltes method with page specific filtering? I would be happy to build upon the template based access, but I don't see how I can do that. I need to give client ability to give view/edit access to any group in any page, without me or them need to go editing roles, permissions or templates.

Thanks for the PR Soma! I will pull this in within the next day or two and make any necessary updates to the CKEditor plugin as well. Default language is required. But you could always add your own checkbox field to the page as a toggle to disable it. Your head.inc or _init.php or whatever your common initialization file is could check: if($page->disable_default_language && $user->language->isDefault()) throw new Wire404Exception(); You'd also have to consider it with navigation generation, perhaps skipping over pages that have the toggle set while in the default language, or adding it to your selectors when querying pages. Edit: you could also just choose to not use the default language at all. if($user->language->isDefault()) $user->language = $languages->get("en-us"); // or whatever you want your default to be

ProcessWire already keeps a references to the users that created the page and last modified the page, so you don't need to maintain that separately yourself. They are present in $page->created_users_id and $page->modified_users_id (to get the ID) or $page->createdUser and $page->modifiedUser to get the User objects.

You shouldn't be changing the parents of pages like that. Use page fields to categorize the articles and you will be fine http://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/

Thanks for those kind words Ryan and Craig. Coming from you guys, it really means a lot to me, being an admin guy taking my first whack at this. And thanks a lot for taking another look at the texts Craig!

Technically I suppose you could have thousands of templates, but that's not where the scalability focus is. PW is designed to scale to unlimited pages, but not templates or fields. There's also the development factor–I don't think one could effectively develop a site with thousands of templates because that's just too much to keep track of. Consider the computer dictionary definition of Template: "a preset format for a document or file, used so that the format does not have to be recreated each time it is used." That describes templates in ProcessWire–something common so that you don't need huge quantities of them. Mary–do you think you need thousands of templates for layout reasons, field reasons, or access control reasons (or something else)? I think you'll be able to achieve what you need while only having a few templates, but want to better understand the foundation of the need.

Thanks for the testing and reports maba and Raymond, I'll experiment here and see what I can find/fix. But regarding the image field, I don't think you'll be able to use that as a live dependency because the ajax upload isn't submitting the entire form, just a single field. So when it gets processed, the context of other fields is not known. Only the existing page state is known. So that dependency would probably only come into play after the page is saved in full. As a result, image/file fields may not be good candidates for dependencies, unless we turn off the ajax upload for that situation. A repeater is a PageArray, so you'd have to extract an element from it first. Like if you wanted the first element: if($page->contentblock->first()->contentblock_headline != '') { // something }

If you are already scared yet, you definitely shouldn't come after midnight when my brothers will visit the forum too: and

If you wanted it to automatically bypass the _main.php template during an ajax request, you could also do something like this in your _init.php: $useMain = !$config->ajax;

Thanks guys!! Will go through these suggestions as soon as I can and get back to you. Saturday night here, "apparently" I have to get away from the computer and be social and whatnot... meh

I'm very picky here. When I can I compaire with === I prefer that. This will tell me that the types are the same to.

SELECT name,modified,modified_users_id FROM pages WHERE id=2

Mary, I suppose the questions are: 1. Why do you need thousands of templates? Are the baby sites structurally different (e.g. one has title and headline field, the other only has title, or different markup, etc) and/or are they aesthetically different (CSS)? 2. Will the baby sites each have more than 1 template? Max number of templates? In the end, you do not need each to have unique templates. You can have a base template and pull in .inc or .tpl files via the API to populate the unique portions of the baby sites in the frontend. Soma proposed a wonderful "template delegation" approach that would fit your project nicely, I think. Have a read here. http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/. There's other approaches there as well. So, instead of ending up with thousands of templates, you could end up with thousands of template file includes. Even then, I should think you can still cut down on the numbers depending on the uniqueness of the baby sites. It just needs careful planning/mulling over. Having said that, I don't think having thousands of templates will have any performance issues in the backend. I could be wrong on this one since I have never tried it though . You'd probably have to organise them in such a way you could easily edit them. You could use tags to group them in the backend. You could even go fancy and create a simple module that would list your templates in a table, maybe with pagination + search function to filter the list, + a click to edit a template (add fields, etc). The link could take you to the PW template edit screen or could open a modal to edit the template. This would be sort of extending the PW template backend view. We can help you get there if you want to take this route. Just my 2cts, there will be other thoughts am sure...

That's odd - you should surely get a PW 404 in normal circumstances for any page that PW thinks doesn't exist, not a redirect. Is it a 301 or a 302? (Not that it makes all that much difference.) Have you got FTP access? Anything in the error log (/site/assets/logs/errors.txt)? I know you don't expect the client to have changed the .htaccess, but it might be worth renaming it and trying a plain vanilla .htaccess from the PW download, just in case they or the hoster have changed something.

Check the name of the admin page in the database just to be sure. The id is 2.

Just a wild guess - do you think it is possible that they have messed with the .htaccess file or have some other redirect rules (maybe even in the apache conf file) that would be causing the redirect?

Thanks for the feedback guys, this was a can of worms situation. I came to realize I also needed a frontend login form and I leveraged the homepage being viewable by all to accomplish this. I wanted to to have csrf protection in my form so I extended the ProcessLogin core module (https://gist.github.com/jdart/6545755) and called the module in the home template: #home.php echo $modules->get('SpexLogin')->execute(); if (!$user->isLoggedin()) return; Hopefully that will be helpful for someone. Maybe

Dresscode?

The mb_strtolower($text) isn't necessary in the above line, as when you specify Sanitizer::translate, that's already the first thing it does in the pageName function. Take a look at the module settings in Modules > Inputfield > Page Name -- from here you can specify your own translation table for how characters should be translated. Is this what you are looking for, or something different?

Usually this is a good and simple method: In a autoload module you hook into the processInput of InputfieldTextarea. public function init(){ $this->addHookAfter("InputfieldTextarea::processInput", $this, "validateText"); } public function validateText($event){ $field = $event->object; if($field->name == "body"){ $page = $this->modules->ProcessPageEdit->getPage(); $oldValue = $page->get("$field->name"); $newValue = $field->value; echo "old value: " . $oldValue; echo "new value: " . $newValue; if($newValue !== $oldValue){ $field->value = $oldValue; $field->error("Go away!"); } } } For a error message you simply add error("text") to the field. It will get showed after saving. What this examples also shows nicely is how to get the old value and new value. The code may slightly varies for different type of fields but the principle is always the same. There's also a method to hook into Pages::saveReady() but I'm not sure what the advanced really are atm.

@mvolke the module I'm working on synchronizes structure only - Templates, Fields and Fieldgroups. It stores captured model operations in JSON files. I currently have no plans to synchronize content (Pages) though it may prove to be necessary at some point - because Pages are used for so many things, certain Pages may need to synchronized, for example options for drop-downs. I'm having Ryan take a look at the module now, and his initial reaction was positive - I think we can make this work, and I think it'll work well. You would think that, but if you look at the ProcessWire codebase, the entire meta-model, with all possible operations, is encapsulated and supports hooks - so it is actually perfectly feasible to implement this in ProcessWire. As proof of concept, I already have all Field operations captured and repeatable. Because this is implemented at the lowest API level, it is actually independent of controllers and user-interface - that is, if you were to build your own admin modules that (for some reason) make changes to any part of the meta-model, those changes would be correctly captured and would be repeatable, independently of any admin UI. There is still substantial work to do on this module, but I would say it's about half-done at this point, and there are no major roadblocks to completion - the fundamental idea is proven and works, so it's a matter of building it out completely.

1) Migrations I had the same problem during my work with Processwire. If you have a team working on a Processwire project where everyone has his own dev server then you need to be able to version the "structure" you put into Processwire and keep it in sync with the template files. I found it to be important to strictly distinguish between structure and data. In 90% of the cases this means templates and field can be seen as structure and pages would be the data. In my current project I tried to use the concept of migrations with Processwire utilizing the phpmig library. If you strictly create all of your "structure" with migrations and never with the Backend UI then it works perfectly, your structure is always in sync with the template files and you can put both in your favorite VCS. To give you an example of how this works: https://gist.github.com/webholics/6191779 2) Structure vs. Data I'd like to add more thoughts to the problem of mixing structure and data in CMSes. This is not a problem only Processwire has, but most CMSes do this (in my opinion) wrong. If your main target user group are developers, it should be possible to keep those things separate in order to enable professional workflows like continuous integration and TDD. This is only possible if you define the structure in code or in config files and not in the database and via a backend UI. It is always the case that template files and structure are strongly depended on each other. One CMS - I'd like to mention here for inspiration - which implements this concept perfectly is Bolt (http://bolt.cm/) . They use YAML files to configure the database models. Bolt then tries to keep them in sync with the database. Maybe it helps to have a look at how they did it.

If you have phone numbers written down, you usually have a name written down next to each number, right? This is metadata that puts the numbers in context. So yeah, data-types like phone numbers and e-mail addresses are necessary, but they usually have metadata associated with them to give them meaning. They're also both examples of data you can associate with a human relation. Images? not so much. Anyhow, we're edging on that topic again, so I'll just say - I still think the real problem is WYSIWYG, which is too limited and simple. For every other thing the user would enter into a user interface, we have some kind of interface that provides guidance, meaningful constraints, structure, advice, context, process, or flow - except for the most important type of input, the one for the actual content... for that, we're perfectly happy leaving the user at his own devices, working with the raw media (HTML) without any real constraints or guidance, short of picking an image from a list - censoring certain dangerous HTML tags, or otherwise crippling the user-interface to limit their use of the medium. It's just no good. Solutions involving codes or tags are usually chosen because they're easier to implement, not because they're "better" - after all, you wanted a WYSIWYG in the first place, and codes or tags are not "what you get". Somebody went through hell and high water to create a WYSIWYG, to enable the end users to work with the raw code without seeing the code - and then we just go and invent more code, and put it back in the WYSIWYG. To me that completely defeats the purpose of using a WYSIWYG in the first place. Anyhow, I've said all this before, but I don't think working with the raw medium is the answer. Yes, content management should be visual - but somebody (me? if only I had more time) needs to invent a proper abstraction for content. Something that accommodates images, as well as other media-types, as well as any other solution-specific data-types, without having to climb Mt. Everest to get there. On thing that comes to mind is these Bootstrap drag-and-drop design tools that are cropping up every week now, have you guys seen those? They provide a structured, guided, visual way to build entire web-pages out of components, which is not precisely what I'm looking for - but something along those lines. Something that allows you to get creative without editing raw HTML or entering codes or tags. Something that guides you through the creation of rich, structured content, without getting in your way - and where you can easily drop in another component template at the user's request. I will keep dreaming of this in obstinance until I or somebody else creates it