Thank you very much for picking this up David, I'm glad something else wants to talk about that stuff

So, what I think would make Wolf much more flexible, are Custom Page Types. I really like The M's approach to this! Let me explain it for everybody who doesn't know this plugin. Wolf needs to have something (not as complex, but still) like other powerful CMS. Like for example the CCK in Drupal ... it's so powerful, you won't believe it.
Ok, back to Wolf. There already is this really powerful unlimited page-part adding. But if we could have different types of page parts .. like simple text fields (input type="text"), additional date fields (with page picker functionality) or select fields, we would win a lot of comfort.
Then the next step would be to group different page parts together and save a collection as Custom Page Type (or whatever you want to call it). When creating a page, you would have a usual page in the first place and the option to use one of your custom pages. This would make things like an image gallery for example much easier.
You see, this is quite what The M did, but I would like this functionality to be more tightly integrated into frog and it sould be easily extendible (with your own custom fields).
I know this would blow things up a bit, but I think it's worth it.

There is more stuff to come from my side, but I will type that tomorrow

... into Wolf? Those sound like great ideas.

What kind of user do you have in mind, Alex? Is this for a client, someone with little to no HTML, etc., knowledge? or are you thinking this would be useful for a developer/designer to hand over to a client? Or for a hobbyist who is looking for a simple website solution for their club?

I suppose on any of these scenarios, the importance for Wolf is that the plugin API is up to the job. My assumption (now that one or two of M's requirements!) have been woven into the core, is that it is robust enough for the job. It's just (ha!) a matter of people with the skills and inclination to author the plugins.

That's good news! Thanks, M! However, I wasn't entirely sure what point you were making in linking to Jesse's mockup. What's the essential bit of his approach that interests you?

ppf = page part form

Well, this might be true for the most of us

Not exactly, but close. The page_parts would be the one to do the job. They build the core of Frog/Wolf and the ppf plug-in. The only thing the plug-in does is the representation of these page parts for the administrator/editor. Right now only one page part can be shown at a time, the plug-in renders those page parts after a set of rules (e.g. text field, images, select boxes, lists, etc.)

It boils all down to form elements, because this is the only thing how the end user can interact with the system.

Well, my intention is not to add this to the core, BUT to add the possibility to the core if you do not want to add this to the core. If, and I only say if, this would be in the core, the whole edit interface would be described as a ppf definition. So each page has some kind of "layout definition" for the editing.

Well, this depends. The tab navigation for the page_parts is complex, too. We must clearly separate the use cases here.

Designer/Administrator: ensures that the page parts will be there for a page and define a form what/how the client enters the content. Currently the designer/administrator can't and must explain the creation of page_parts, inheritance for default content, etc

End user: just sees extra fields that must be filled

Sure we can argue about the use case, and I admit for simple page oriented projects it does not make much sense. My initial use case was an interface with has both sides, like cards in a deck with front and back side. I wanted to separate the content for the front and the flip side in frog and used page_parts for this. After some discussions, my customer requested me to have everything in sight --displayed at one page. This was how the ppf plug-in was born.

Abstract: the need is to provide a flexible interface for content editing that depends on the type of content.

For example:

• if the content type is a simple blog entry, it would be an excerpt and the body (or only the body with some "more" stop word)

• if the type of content is a product, I would think of: description, order number, stock, price, etc.

• if the type of content is a game review: there would be different types of information the user can not add to the existing text field in an unstructured way.

And here comes the thin line between writing an own plug-in for the content type, or use a more generic approach. And so to say it's not always that simple to choose between specific and generic. The benefit of a specific plug-in is to add custom checks (validation, help text, consistency, etc.) as well as the whole management and the own data model. On the other hand the generic approach enables not programmers (like designers) to create those interfaces with little effort. Think of it like PHP myAdmin for databases

As far as I can see, a plug-in (does not necessarily need do be mine), must be able to hook into the rendering of the editing interface. This could be implemented with some kind of delegate (either function or object), but I'm getting ahead of myself talking about implementation.

I'm with you.

Well, I just wanted to highlight that if I (or someone else) writes such a plug-in this might be used for inspiration.

I do not need to tell you that there are different use cases. Your mother will never edit HTML, PHP, or SQL to update her site as well as a photo editor to change the header. The ppf could even more add usability for the end user. The ppf definitions are managed by the technical responsible (supplier/designer/admin) and not by the end users. And please don't tell me filling out a form is more complex than navigation through a tab interface to edit content that belongs to the page.

Generic question, generic answer: edit and manage (structured) content

M

PS: your mother example reminds me, that having personas (Alan Cooper with "the inmates are running the asylum", his page about personas, other collection of articles) for Wolf would be a good thing. Instead of always stretching the capabilities of our examples. I can explain more if required.

Great to see this much talking going on on this topic

First of all, I think we're all on the same side - I think we all love the light core and the simplicity of Wolf and want to keep it that way as well. (this is applying for imy part, at least).

I think, that's an interesting decision. I would love the mentioned approach to say the standard page type is described as ppf - this would make extending it very easy and very clean. But I can understand Martin of course. So what I would like to say: if you can "persuade" your heart, please introduce this to the core!
Still I would try to keep Wolf as easy to use as possible - and maybe deliever the admin interface for custom page types as plugin that isn't enabled as default or something ...

I can understand if you don't want this, Martin - this is a big change and your arguments are reasonable! There are other possibilities to realize this. (as M already did, not to forget to mention that ^^)

Again, I want to lay out what M already said about the possible uses for this (thanks to you, M, for the long text - I couldn't write it better):
This one plugin could replace many other plugins. Like these guys that are developing Leapfrog, an event management plugin. Of course, if you want to have a proper Event planner on your page that has a customized interface and so on, you sould have your own plugin. But imagine somebody who just wants to have some simple events on his football club page, at the same time, he wants a list of the trainers (with Birth Dates, Specialization and Nationality) and a press page for press publications of his club (with own fields like, Press, extract, link to pdf of the article, publish date etc.) .. so if he understands how to use custom pages, he can do all of this with a clean set of custom pages and doesn't have to install different plugins...
Of course, he could just somehow use the page parts (one for the birth date, one for the specialization, one for the nationality for a trainer e.g.), but custom pages would make his life easier and, above all, it would make content editing more intuitive and faster.

Kind regards to all of you
Alex

Soo.... just as a small re-cap.... If I were to phrase things in programmer-speak.

We currently see a need to increase user flexibility and simplicity of use by possibly introducing a sort of typed variables: (I am deliberately not calling them page-parts by the way)

- Each variable should have a basic type. (text, onoff, dropdown, radio, etc)
- Each variable should have an id, field description (used for displaying in a form), etc.
- You can combine variables in page types(?)
- When creating a page, you could select a page type from a drop down box which defaults to a "basic page" page type(?)

This is similar to the ppf plugin by M I think but with some subtle differences and more integrated into the core.

This would allow us to store a page's content based on page type.

- By default, there would only be one page type "basic page" which equals the current Page.
- By default there would be no interface to create new page types except the Plugin API.

This would increase flexibility of the core, keep the default simplicity of the core's interface and would allow developers like M to create a "page type management" plugin or a plugin that simply creates page types through the Plugin API.

If you were to combine this with adding "create page", "delete page" functionality in the Plugin API, you would get an incredibly powerful system.

The default "Pages" tab in the admin section would be reduced to a management plugin only.. i.e. it would just present an interface to manage pages of type "basic page".

...or something along these lines anyway...

EDIT - as an afterthought... when a new page type is added, it would generate its own table. This should not be a problem unless someone creates a huge amount of page types (and as such tables). This keeps the database structure manageable... though maybe this isn't the ideal solution... will have to think on it some more.

Last edited by mvdkleijn (2009-08-15 16:01)

Yes.

and @mvdkleijn: that's exactly what I was thinking about.
I will take this as an invitation for beginning to think things through a bit

To realize this, we would need:
(this should be seen as some first ideas which just came into my head ... feel really free to comment!)

A system of known "field types"

• there would be some types coming with the core ... e.g. textline, textfield, date (most basic things should be included, some fun coming up here: what about file uploads ... ? ^^)

• each field has its own key like "textline", "textarea", "bdimagegallery_image"

• ideally, this would be extensible by plugins, these plugins use their plugin key in the field keys to prevent overlays ("

• each field would need its own handling (functions) for update/insert, delete, frontend display and backend (input) display (did I forget something?)

• ok, how to do this? PHP classes which include info variables and handling functions?

Some markup for the grouping of fields

• I like M's approach with the YAML-based syntax

• interesting would be to have the possibility to use tabs

Ok, your last point is important thinking, Martijn (is this correctly spelled?) - I agree, but  I still like the current behaviour with the page_parts to have a one-to-many relation from one "page" entry with the metadata information to all its page parts ... but this would require us to run every custom field as a longtext field, wouldn't it? (this is how M's plugin is working right now, isn't it?) ... ok, I have to say, this version also has its weaknesses..

Martijn, I think your thoughts are spot-on with regards to this.

Having the interface more or less the same; while keeping the complexity of the page types etc "hidden" and accessible via a power-user plugin and via code is, in my opinion, the best way to do this.

Actually... I am (sort of) working on that. I still need to figure out one or two things.

I would like to see a plugin that enable grouping members with different privileges, creating custom groups of members and showing a post to a specific group only. I found this feature in Chyrp but I like Frog/Wolf CMS better.

Juan

Agreed... this is potentially a big feature/bloat. (skeleton wiki page here...)

I've come up with a possible solution which (I think!) would require fairly few changes to the core to achieve this.

Assuming I get some time tomorrow or the day after, I'll pen it down in the wiki page above. In short, it would add one database table, one class and expand the current PagePart class.

It should allow for Pages that are of a PageType where each PageType is made up multiple of FieldTypes.

Last edited by mvdkleijn (2009-08-25 01:00)