Support/Comments for frontpage 1.0-beta

It’s here, https://github.com/shamblett/frontpage, I’ll add this to the package description in extra’s on the next update, I can’t really sig it as I have lots of packages, I can’t sig them all. I’ve raised issue 5 for this, please add any comments or potential fixes, ta.

ok, thx.
Watched it.

I hate to show my ignorance but I just can’t get this working. Must the page you are editing have it’s template set to the frontpage template for the edit to show or can I just add the relavant parts to the top of my blog template?

Ok, it won’t do anything till you login through the front end using a component like login for instance, then you should see the top menu on any pages the logged in user is allowed to edit, so you need to set the perms correctly here. Logging in through the front end as your site admin user is a good test, have a look at the user guide.

Hello,

first of all thanks for this great Plugin!
I want to use it in a bigger site with a lot of different user roles. The site has different content areas and some authors are only allowed to edit one defined area.

I managed it with ressource-groups and it work fine in the manager.
But it seems, that frontpage is not able to fetch the user rights with the concept of user groups. I must admit, that it was not that easy to understand the new authentication system in Revolution.
Perhaps I have made some mistakes here, but everything works fine in the manager.

With frontend I have the Problem, that every User in a a designated user role can edit every Ressource that is accessible für unregistered web users.
I tried some different settings in the PerformRoleCheck and contentManagerRoles but nothing worked out.

Any ideas how to solve the problem?

Thanks in advance fom germany,

Sebastian

Hi, in essence frontpage allows anybody to edit any page dependent on the Revo permissions for that user, if a logged in user can get to a page then the two checks of update and create are made to see which edit buttons, if any, will be displayed. The role management check just pre-filters this to say ’and is one of these roles’, so a user has to be a nominated role before the permissions check is carried out.

That said, there’s a ticket raised in github on this area for the next release, what would you like to see here? Maybe I can incorporate a more useful/meaningful system.

Thanks very much, I like it..

I have a little problem, after editing a page, my website still serving the old page from cache,, any idea of how to clear cache from front end?

Thanks

Not as such, I can add code to do this when you exit the edit/create pages but I didn’t want to make this global as some people may not want the whole of their cache cleared just because one page is edited, we can set a parameter for this somehow maybe, I’ll raise aticket in github to see what can be done, thanks for reporting this.

Great job!

I’m writing a simple Frontpage user guide to a client without any HTML and CSS knowledge. Obviously next release will come with a lot of new improvements. Anyway, i’d like to know whether following things will be changed:

1.) Currently all place holders like [[*longtitle]] are shown in the content editor, is there going to be a way to lock/hide/show the actual longtitle instead of the placeholder tag? An inexperienced client easily messes up the content by modifying the tags...

2.) Content looks different in the editor window as CSS styles are not fully applied. E.g, my client has hard time to edit content with <h3> headings (styled with CSS) because the final output can’t be seen on the editor window.

3.) "Inser/edit image" function is very simple, however it would be great if there’s an option to upload images from hard drive. My client can’t add new images without logging in Modx Manager and i’m trying to keep them away from that area.

Hi, good points :-

1. The problem here is if you have something like a Wayfinder call as an example, if I parse the tags this will output what it outputs if you see what I mean, this would then be ’editable’ but obviously wouldn’t persist as it would be overwritten on the next page refresh. Also if I expanded longtitle I would need to know it had been edited, this would just be text now, no tags so this is tricky. I think documentation helps here as you say, document a list of tags that are editable on the form, such as longtitle and say that to change this change it on the edit form itself, not in the content pane etc.

2. Yes, this is deliberate at the moment so that any Frontpage css doesn’t affect the actual page, we can change this and make it selectable by a setting if needed.

3. Agreed, not an area I’ve looked at in any great detail other than to check basic functionality, we can set it to use any paths you like, again selectable, and say automatically add the logged in users assets path if one exists.

Point 1 is really about the whole area of tag handling, do we expand or not? Do we show them in content or strip them completely? There will probably be as many users who want to see and be able to edit tags as ones that don’t, the possible use cases are quite large, maybe we will end up with a set of role based user profiles that will allow these different to be switched automatically.

I didn’t want to overcomplicate this area initially nor make it too restrictive until I had some feedback from users like yourself, using it in real usage scenario’s. Any ideas here gladly received.