1

Topic: Most important 3rd party plugins?

Wolf has some clear and welcome goals to guide its development. This involves resisting feature bloat! I think this is exactly right -- but it also means that plugins are an important resource for Wolf users.

There has been some thinking about the most important plugins, and I thought I'd start a thread here to keep the conversation going.

I expect that our perception of this will be shaped by the uses we have for Wolf! And I might add that I have done the minor adjustments required to make Tagger Wolf-friendly for the future. So there, for me, is one "essential" plugin ready. :)

So -- what do people think are the "extra" (NON-core) plugin priorities, then?

Using Wolf CMS professionally and for profit? Please consider supporting Wolf financially. Thanks!

2

Re: Most important 3rd party plugins?

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

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 wink

Thumbs up

3

Re: Most important 3rd party plugins?

a.renz wrote:

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).

Well, I'd be happy to port this to Wolf with some design changes and better integration with the core. This might break the Frog part, but the development could go on for both branches.

But remember, the more_metadata plug-in (or some other infrastructure) is needed, too.

About the changes, I want to highlight the Flex CMS idea, maybe this is an approach we can pick up.

EDIT: about the integration: Maybe we can do it "right", so I need a comment/decision from Martijn how he wants or don't want to integrate a) the infrastructure b) the feature as core or 3rd party plug-in.

Last edited by M (2009-08-14 08:18)

Thumbs up

4

Re: Most important 3rd party plugins?

a.renz wrote:

.... But if we could have different types of page parts ... Then the next step would be to group different page parts together and save a collection as Custom Page Type ... You see, this is quite what The M did, but I would like this functionality to be more tightly integrated into...

... into Wolf? tongue 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.

M wrote:

Well, I'd be happy to port this to Wolf with some design changes and better integration with the core.

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?

Using Wolf CMS professionally and for profit? Please consider supporting Wolf financially. Thanks!

5

Re: Most important 3rd party plugins?

M wrote:

EDIT: about the integration: Maybe we can do it "right", so I need a comment/decision from Martijn how he wants or don't want to integrate a) the infrastructure b) the feature as core or 3rd party plug-in.

Note: This is a long post and English is not my native language, so forgive me if its a bit unstructured or sounds gruff. wink

I've read all of the comments and I understand there is a need to define multiple "elements" of sorts. These elements you would like to combine into a whole which you can then place on a page. Correct?

Should these elements be form elements or can they be anything?

Apart from that question, my initial reaction: my gut feeling is that this introduces too much complexity for the goals set for Wolf CMS core.

Let me explain. So far, I've seen lots of talk about page-parts, tabs, snippets, custom plugins all trying to full-fill some need. However, I have yet to see a clearly defined description of that need.

This already came up during my time on the Frog project, but each time I asked the question "what do you need?" I did not get the answer I was looking for. The answer I got was someone describing an implementation, not a need.

This leads me to believe that the users themselves don't entirely know what they want or that we're trying to solve multiple, differing things.

Before I continue, let me make one thing perfectly clear: I am not opposed to changes/new features in Wolf CMS.

However... wink

I am very opposed to unnecessary bloat in the core and I am very opposed to anything that would detract from Wolf's simplicity. For most/many of you the reason for starting to use Wolf (and before that Frog), is because it is so simple.

So where does that leave us? Simply put...

I'd like to see a good, clear definition of the need you are trying to solve with this plugin.

Ideally, this would be transformed into a plugin. Hopefully M's plugin fits the bill exactly, otherwise some changes might be needed. (or an extra plugin)

As far as I'm concerned, Wolf CMS should provide the core services and functionality (read API) to allow a whole host of plugins. The thing you can expect me to do is to guard against an inconsistent, wildly growing API. Expect the API to mature as we grow to Wolf 1.0 and expect us to work together on deciding the best form/implementation of that API.

As for the Flex CMS idea referenced by M - My initial feeling is that this is definitely too much complexity.
If you want these kinds of features, why not just use Drupal for example?
What difference would there be left between Wolf CMS and Drupal if we were to introduce all of these ideas?

Currently, Wolf CMS is easy enough to explain to my mother aged 63. She uses it regularly to update her small site. True, there are a few niggles that need clearing up to improve simplicity and usability but these are small. This is something I wouldn't even try with Drupal.

So I guess my question is what do we want to do with Wolf? Do we want simplicity and ease of use or do we want yet another Drupal/Joomla or <larger cms of your choice here>?

Wolf CMS founder and lead developer
Please always check the Support forums and Wiki before asking. (My Ohloh account.)
Like Wolf CMS? Consider making a financial contribution or see our financial report first.

6

Re: Most important 3rd party plugins?

ppf = page part form

mvdkleijn wrote:

Note: This is a long post and English is not my native language, so forgive me if its a bit unstructured or sounds gruff. wink

Well, this might be true for the most of us wink

mvdkleijn wrote:

I've read all of the comments and I understand there is a need to define multiple "elements" of sorts. These elements you would like to combine into a whole which you can then place on a page. Correct?

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.)

mvdkleijn wrote:

Should these elements be form elements or can they be anything?

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

mvdkleijn wrote:

Apart from that question, my initial reaction: my gut feeling is that this introduces too much complexity for the goals set for Wolf CMS core.

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.

mvdkleijn wrote:

[...] introduces too much complexity for the goals set for Wolf CMS core

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.

mvdkleijn wrote:

[...] However, I have yet to see a clearly defined description of that need.
[...] The answer I got was someone describing an implementation, not a need.
[...] This leads me to believe that the users themselves don't entirely know what they want or that we're trying to solve multiple, differing things.

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 wink

mvdkleijn wrote:

Ideally, this would be transformed into a plugin. Hopefully M's plugin fits the bill exactly, otherwise some changes might be needed. (or an extra plugin)

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.

mvdkleijn wrote:

As far as I'm concerned, Wolf CMS should provide the core services and functionality (read API) to allow a whole host of plugins.

I'm with you.

mvdkleijn wrote:

As for the Flex CMS idea referenced by M - My initial feeling is that this is definitely too much complexity.

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

mvdkleijn wrote:

Currently, Wolf CMS is easy enough to explain to my mother aged 63. She uses it regularly to update her small site. True, there are a few niggles that need clearing up to improve simplicity and usability but these are small. This is something I wouldn't even try with Drupal.

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.

mvdkleijn wrote:

So I guess my question is what do we want to do with Wolf?

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

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.

Thumbs up

7

Re: Most important 3rd party plugins?

M wrote:

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.)

Actually, its the pages that currently form the core of Wolf CMS. Page_parts, whilst useful for allowing end-users more control in a site setup by an administrator/developer, could be removed quite easily without much impact in the basic behavior of Wolf CMS..... smile

M wrote:

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 wink

Now this is something we can work with. wink

I've been toying with the idea of removing the "Pages" functionality from the core and turning that into a "Pages" plugin. To achieve this, we'd need to have a basic "object" if you will which is manipulated/stored by the core. Plugin devs could then extend this basic object to provide extra functionality whilst still enabling the core to manipulate them at very basic levels.

Of course, this is somewhat more involved than what you're describing but it touches on many of the same problems/subjects such as how you can create a highly configurable system without introducing too much complexity.

The "content-types" you describe could very easily be either a pre-programmes extension of a basic object like the one I talk about above, or it could be a ppf like construction or CCK like construction.

M wrote:

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.

Hmm... rather than a plug-in hooking into the rendering, I'd prefer for the core to do the rendering somehow and for the plugin to only provide a "description" of what needs to be rendered. Depends on how the formation of ideas go.

M wrote:

I'm with you.

Good to know. wink

M wrote:

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.

There are many different use cases and many different personas, I am well aware of that. However, I am also very aware that Wolf CMS will never be able to cater to all of them, so we need to pick and choose.

Anyway, my experience with end-users leads me to believe that they feel complexity increases as the number of form elements increase.

Too many form elements == difficulty to get an overview == complexity. Even if this is only a perceived complexity. (a quote of beauty lying in the eye of the beholder is lurking in the shadows near this thread)

Anyway, it isn't a question of tabs vs. forms/ppf/whatever... whatever solution fits the problem is fine by me as long as it is well thought out (which is why we're discussing things here wink ) and keeps things simple for the end-user, administrator/developer as well as plugin developers.

By the way, you're making two assumptions here which I'm not willing to make:

  1. There is an administrator. (sometimes the end-user is the admin as well)

  2. The administrator has technical knowledge or more knowledge than an end-user.

Unfortunately, I have come across plenty of administrators who are no better (maybe even worse) than end-users in terms of technical know-how/level of understanding.

M wrote:

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

Touche sir. smile

M wrote:

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.

I am familiar with them. wink I tend to use the concept of personas intuitively without formally defining them. Since there is enough to do already, I'm not sure if formally defining a set of personas is necessary. But by all means, be my guest and take a stab at it! smile (may I suggest the wiki?)

Wolf CMS founder and lead developer
Please always check the Support forums and Wiki before asking. (My Ohloh account.)
Like Wolf CMS? Consider making a financial contribution or see our financial report first.

8

Re: Most important 3rd party plugins?

Great to see this much talking going on on this topic wink

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).

M wrote:

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.

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 wink
Alex

Thumbs up

9

Re: Most important 3rd party plugins?

Just to say -- I am enjoying this conversation! I'm learning lots, as usual. ;)

Using Wolf CMS professionally and for profit? Please consider supporting Wolf financially. Thanks!

10

Re: Most important 3rd party plugins?

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

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... smile

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)

Wolf CMS founder and lead developer
Please always check the Support forums and Wiki before asking. (My Ohloh account.)
Like Wolf CMS? Consider making a financial contribution or see our financial report first.

11

Re: Most important 3rd party plugins?

A very brief nano-summary from a non-programmer (just to see if I'm on the same "page" as it were -- hehe -- that's almost a pun):

Under the scenario Martijn is describing, the end-user would get something that looks almost like (exactly like?) what we see now out-of-the-box: title field, metadata, text-entry area. BUT, behind the scenes, this would be managed by a plugin, and that plugin would have the capacity to create/design entry screens (I don't say "pages" necessarily!) with any variety of text-fields, check boxes, media-types, select box, file attachment, etc., that a developer could design, along the lines of M's ppf plugin. ... Yes? no? almost?

This is fundamental stuff -- and would make for a *very* powerful system, yet without losing the simplicity that first attracted a user like me. smile

While I'm at it, here's my short-list of high-priority, third-party plugins, that I would love to have the skills to author (but I don't!), pretty much in order of priority:

  • Akismet plugin for the comments plugin

  • full-blown search utility (that would give keyword-in-context, etc.) (although BlueFrog's solution has been doing the job nicely for me in the interim!)

  • easy image-adding for pages (maybe part of filter solutions -- e.g., if WYMeditor gets an image-picker facility, or TinyMCE's image-drop thing)

There are probably others I'm forgetting, but this will do for the moment!

Using Wolf CMS professionally and for profit? Please consider supporting Wolf financially. Thanks!

12

Re: Most important 3rd party plugins?

David wrote:

Under the scenario Martijn is describing, the end-user would get something that looks almost like (exactly like?) what we see now out-of-the-box: title field, metadata, text-entry area. BUT, behind the scenes, this would be managed by a plugin, and that plugin would have the capacity to create/design entry screens (I don't say "pages" necessarily!) with any variety of text-fields, check boxes, media-types, select box, file attachment, etc., that a developer could design, along the lines of M's ppf plugin. ... Yes? no? almost?

Yes. smile

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 wink

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 smile

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..

Thumbs up

13

Re: Most important 3rd party plugins?

a.renz wrote:
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 ... ? ^^)

What about them? lol... Basics first, lets prove the concept works with the basic fieldtypes. We could create helpers for more complex fieldtypes. As such, you'd be able to add a helper to be able to handle new/more complex fieldtypes.

a.renz wrote:
  • each field has its own key like "textline", "textarea", "bdimagegallery_image"

Hmm... lets start "simple". smile We can always add support for "custom fieldtypes" later. (but we could use helpers for this)

a.renz wrote:
  • 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?

IF and WHEN we allow for custom fieldtypes (don't jump the gun here wink ), the best solution would probably be to create a new class for it by extending the basic class.

a.renz wrote:
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 smile

I'm curious... M, what made you choose YAML?

Ideally, I'd like the system to have enough smarts to produce a useable grouping/look-and-feel without intervention of the person creating the new "page type". We could extend that to allow more control over the grouping/look-and-feel through whatever means... perhaps through an additional plugin.

I'm a little concerned that this is rapidly coming into the "feature bloat" category.

a.renz wrote:

Ok, your last point is important thinking, Martijn (is this correctly spelled?)

Correct. smile

a.renz wrote:

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?

If that turns out to be the case, I won't have it in the core... smile But I was thinking of assigning/creating actual field types.

Take for example the current "Add page" screen. That currently consists of variable in the Page class which get stored in the DB as certain types.

What I'm currently thinking about (though its difficult to get the idea into words without just writing the software tongue ) is to have that exact same "Add page" screen be a "Page type" as it were.

The "Page type" would essentially be a form consisting of multiple fields. When you enter information into the "Add page" screen (and therefore use that "page type") the value you enter would be stored in the DB as specific field types.

The current "Page" object would revert to a sort of placeholder. It would only carry some general information and the "real" information would be stored through the page type.

For those of you familiar with Drupal.. Wolf's "Page" object would transform into something more resembling Drupal's "Node" object.

Which is nice, but at the same time makes me fret about the level of complexity we might introduce into Wolf. If we're able to hide all of this stuff so a user would only be able to create new page types through a special plugin, then that's fine.

If, in a default Wolf installation, the user is confronted with all kinds of choices/page types/field types/nodes whatever, that's not fine.

The idea here is... when you compare a default Wolf installation before this addition and after this change, there should be no (very, very, little) change for the average user.

A plugin developer would be able to use the plugin API to define page types and use them for his/her plugin.

A "power user", whomever that might be, would be able to install the "Page type management plugin" and then be able to define new page types or alter existing ones.

Lastly... I have some initial thoughts for actual implementation of this stuff. Not sure yet on how we'd handle custom/complex field types but I have some ideas for implementing this for the basic field types. If I have time coming weekend, I'll see if I can't implement some of this to see how far I get without running into problems. Heck, who knows... maybe by monday evening there will be another new feature in Wolf 0.6.0.

wink

Wolf CMS founder and lead developer
Please always check the Support forums and Wiki before asking. (My Ohloh account.)
Like Wolf CMS? Consider making a financial contribution or see our financial report first.

14

Re: Most important 3rd party plugins?

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.

15

Re: Most important 3rd party plugins?

David wrote:

There are probably others I'm forgetting, but this will do for the moment!

There was another I was forgetting:

It would be *very* good to have a "cron" type plugin, that would allow:

1. automatic posting of pages at a certain set time in the future; and
2. an "expiry" date that would remove a page once a certain date/time has passed.

#1 is far more (IMO) important than #2, but would be good to have both!

Using Wolf CMS professionally and for profit? Please consider supporting Wolf financially. Thanks!

16

Re: Most important 3rd party plugins?

David wrote:
David wrote:

There are probably others I'm forgetting, but this will do for the moment!

There was another I was forgetting:

It would be *very* good to have a "cron" type plugin, that would allow:

1. automatic posting of pages at a certain set time in the future; and
2. an "expiry" date that would remove a page once a certain date/time has passed.

#1 is far more (IMO) important than #2, but would be good to have both!

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

Wolf CMS founder and lead developer
Please always check the Support forums and Wiki before asking. (My Ohloh account.)
Like Wolf CMS? Consider making a financial contribution or see our financial report first.

17

Re: Most important 3rd party plugins?

Uuuu, that's great idea David. I think a lot of people (including myself) will appreciate & cherish smile that plugin or better to say that possibility.

My Wolf CMS related blog Project 79 | Wolf CMS Docs

18

Re: Most important 3rd party plugins?

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

Thumbs up

19

Re: Most important 3rd party plugins?

Aggr, I somehow lost track and the subscription to this topic hasn't send my any updates. Maybe my spam folder eat the updates. Sorry.

Martijn wrote:

I'm curious... M, what made you choose YAML?

YAML is simpy expandable if I want to enhance the syntax. No complex schema and in the end yet another serialization format like, e.g. JSON. In the first places I wanted to create some fancy generator with jQuery and on the fly generation (like PhpMyAdmin) but I thought it's not worth the effort. In the end you just write one declaration and expand it over time so I've chosen the simplest solution (KISS).

David wrote:

Under the scenario Martijn is describing, the end-user would get something that looks almost like (exactly like?) what we see now out-of-the-box: title field, metadata, text-entry area. BUT, behind the scenes, this would be managed by a plugin, and that plugin would have the capacity to create/design entry screens (I don't say "pages" necessarily!) with any variety of text-fields, check boxes, media-types, select box, file attachment, etc., that a developer could design, along the lines of M's ppf plugin. ... Yes? no? almost?

Yes, but we should not (again) build the Mozilla browser with XUL or XAML wink But you are right if you take it to the end.

a.renz wrote:

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..

The page_part_forms are mostly a hack without the support of the core for a type system. But do we really need a type system?

Martijn wrote:

I'm a little concerned that this is rapidly coming into the "feature bloat" category.

+1 let's keep it simple. If you are interested we can talk about the first implementation and if you want I may be able to participate.

Should we add a Wiki page for the requirements for this functionality?

Last edited by M (2009-08-24 23:26)

Thumbs up

20

Re: Most important 3rd party plugins?

M wrote:

Should we add a Wiki page for the requirements for this functionality?

Agreed... this is potentially a big feature/bloat. smile (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)

Wolf CMS founder and lead developer
Please always check the Support forums and Wiki before asking. (My Ohloh account.)
Like Wolf CMS? Consider making a financial contribution or see our financial report first.

21

Re: Most important 3rd party plugins?

Sry I didn't say anything here for quite a while .. have been busy and on vacation and so on smile

You two are right, we should prevent this getting to big - I would love to see your idea, Martijn smile

Thumbs up

22

Re: Most important 3rd party plugins?

RFC - Request For Comments

I spent some time on writing this wiki page to outline my ideas. These are probably incomplete but it should be enough to give you an idea of what I'm thinking about for this.

Please read through the above wiki page and add any comments you have about it on this discuss: namespace wiki page instead of here. (since this thread has little to do anymore with the forum's topic!)

Wolf CMS founder and lead developer
Please always check the Support forums and Wiki before asking. (My Ohloh account.)
Like Wolf CMS? Consider making a financial contribution or see our financial report first.