Frog CMS

ho yea I like those kind of idea :)

and I will really impress to have a cache plugin too.

I add those observer right now !!

and for the page_add_before_save I can't pass the page if it is not yet saved !!

good :)

I have add those observer: page_add_after_save [$page], page_edit_after_save [$page], page_delete [$page], part_edit_after_save [$part], page_requested [$full_query_url]

@gido – I shamelessy stole your code example and placed it in the site’s Docs section in preperation for a more complete document about Observers… when I find the time.

Maybe my problem fits in here.

I have form, I use Observer – page_found and problem is when form has errors, how can I serve those error variables in frontend?

Lets say:

$name = '';
if(empty($name)) { $error = 'Your name is null'; }

So how can I server this $error variable into frontend?

thanks..

How would I go about observing:
/admin/setting/plugins

I’ve tried various attempts but alas nothing has worked thus far:
Observer::observe('view_backend_setting_index', 'orderplugins')

I thought there was a naming forumla, but I don’t see it yet!?

Hi Martijn,

Indeed, I’m trying to observe the admin Plugins page in the same way as ‘view_backend_list_plugin’ checks for plugin pages. Is this possible yet? I’m trying to modify the appearance of the Plugins page before it returns to the browser.

Hi Martijn,

As I have come to understand it, there is no other way to override the actual html output of Frog in the backend!? CSS is a fine start, but in some instances I need to be sure that a user does not have access to something particular (a stylesheet can always be disabled to otherwise allow access to something).

Ultimately, I am trying to set up some finer role permissions … without actually having to go to the extent of writing a complicated plugin.

Jonte > How will you stop role elevation?

I am aware of users being able to inject code in the admin area, thankfully non of my immediate users are external to the company nor are they knowledgable about such things as code injection.

Like many Frog users however, I am hoping these security issues are resolved in the core, by the time I need to expose the CMS to external clients.

What about allowing developers/editors to only include Snippets in pages – and only allowing administrators to create/edit snippets.

That way, the lesser privileged don’t get to write any potentially-dangerous code themselves, but can still utilise already-made and approved bits of code.

Or a configurable combination of the above items?

My thoughts for the future direction of the security system in Frog where actually more going towards a combination of roles and permissions.

The current “administrator” and “developer” roles would be changed to be containers for certain permissions.

You could then setup permissions on certain types of actions/objects. For example, a certain role could have a “view” permission on pages but no “modify” permission.

I was thinking about something like: “View”, “Create”, “Modify”, “Administer”

Still just a brainstorm though, haven’t really given it much concrete thought yet.

The underlying principle would be to keep it as simple as possible, have a good clean default and it should allow you to say things like “Users with role XYZ are allowed to create objects of type Page”.

Notice the work objects… If we’d use something like this, I’d like to use the same set of permissions for everything in Frog. Pages, Comments, Layouts, Snippets, etc.