apeisa

This is great and all new to me. I'll do this change tomorrow. Thank you very much Ryan, I'll have to hit applaud on this one

Superuser is the only role that can actually edit the admin pages, and that is intentional, so that you can add stuff to it as it suits your needs. That part is hard coded, so it doesn't matter what permissions/roles you assign, it's not going to let any role other than superuser modify those pages or even see that they exist (unless you write something to do it from the API).

This is good to know! I tested it right away and it works exactly like this.

There aren't any bugs that I'm aware of in the current user/roles system. Though definitely let me know if you found any? The main limitation is just that it's not yet designed for large scale use (i.e. lots of users or data attached to those users), and it's not as refined as other parts of the system in terms of description and messages. However, if you need to setup a role to provide edit access to just another part of the site, then the system should work quite well.

There might be one bug: If you have permissions to login and logout, you cannot actually logout, if you don't give permission to admin site. I see that there is guest role allowed on logout page, but still couldn't logout.

Is there some kind minimum length for selector? I have selector like this:

$people = $pages->find("template=person, title*=$name");

If $name is "Anu" then it doesn't find anything, although I have two pages with titles like "Anu Surname". When $name is "Heikki" it does find pages like "Heikki Surname".

You don't actually need additional admin site to achieve this. Just create new roles for these like "News Editors" and "Article editors". Then you have per page setting for roles who can view which pages. And you have to also give those new roles lots of permissions, like (not sure about all of these):

# ProcessHome

# ProcessList

# ProcessLogin

# ProcessLogout

# ProcessPageAdd

# ProcessPageEdit

# ProcessPageEditDelete

# ProcessPageEditImageSelect

# ProcessPageEditLink

# ProcessPageList

# ProcessPageSearch

# ProcessPageSort

# ProcessPageTrash

# ProcessPageView

After this you want them to be able to access admin site also (if you use AdminBar then this is not necessarily needed since they can edit/add pages through front-end). This can be done when editing Admin page, settings tab and there check needed Roles from Roles-section.

After this they can access admin, but not edit any pages (or actually, they might be able to edit admin pages and mess something?). Now you need to give them rights to edit right pages. So go to your News page and edit settings -> Roles and check "News editors" there.

Of course if you want to give them simpler interface then you would need to create additional admin views (or use AdminBar).

And as you notice when editing Roles:

ProcessWire's role based access control system is currently in development. While fully functional, more work, testing and documentation is in progress, so I recommend sticking with the Superuser role for administrative accounts until development is complete.

Zlojkashtan: welcome to the forums. Strange error and I couldn't produce it here. Do you have page Admin -> adminbar -> ab-sitemap ? If not it should work if you create that page and give it template "adminbar".

I should also make uninstall method so that Adminbar cleans everything if you uninstall it (it would be easier to re-install if something goes wrong).

Will there be any limits at the new system? We sometimes have over 100 000 users that need to login.

Found an issue in IE8

Clicking on the "dark side" doesn't close the modal. Maybe it would be good to add a 'close' button in top right, so the modal close can be forced if needed?

Just pushed latest version to Github. There is now close-button on top of the modal, which should work on IE8 also. I want of course to fix that original IE8 problem and will get into that when I get to work (no IE8 at home). Does it show modal at all in IE8? Probably some css problem there...

I actually positioned the close button to top left. i think it is prettier and closer there, but please let me know if that is unnatural for you guys...

I think now there is hard to say what goes to FAQ and what goes to General support. I would probably suggest something like this:

• ProcessWire News + Announcements
  
• Showcase: Have you done something nice with ProcessWire? Share it here.
  
• Getting started: Not sure if PW works on your project? Just started and need help? Feel free to ask anything here.
  
• Working with PW: API, templates, optimization and best practices
  
• Modules/plugins
  
• Core Development (bug reports maybe here?)
  
• Wishlist
  

Scarota: thanks for the nice feedback and bug report. And welcome to the forums!

I got the exact same request from people at our company, so nice little close-button will be next thing coming.

The title field will likely get locked down (required field name) in the near future, just because I think it'll make life a little more difficult for module developers if we don't... for example, without a known title field, there would be no way to identify what the actual title of a page is, just the URL name. As a result, I don't recommend changing the name of the title field.

Yes, I though something like this.

Now, changing the "title" field's name to anything else threw the error:

Obviously there's no real advantage in changing that name (I can understand where this issue comes from) but I thought I'd point this out.

This is now fixed, thanks again for reporting this Antonio.

https://github.com/apeisa/AdminBar/commit/d4f79e2afecd509f336bef11c480588fa8b0aee6

Ragnar: started to edit css today, but noticed that the bug you reporter is not in tooltip css, it is because AdminBar didn't clear margins on lists. So if your site css didn't have something like ul, li {margin: 0} there would be that issue. It is fixed now on latest version. It is now working on Opera 11, so if you can test latest version of AdminBar in Opera 10 and your site I would be thankful.

Qwertyee: Good idea. I have been thinking about something similar, just not sure yet what would be best way to implement this. Something like this will definitely come in the future.

Antonio: thanks for this! I actually didn't realize that title field can be changed. I am pretty sure that I'll find an easy way to fix this.

This will be a game changer I think: http://developers.facebook.com/blog/post/472

Techcrunch already uses it: http://techcrunch.com/2011/03/01/facebook-rolls-out-overhauled-comments-system-try-them-now-on-techcrunch/

Now it only allows FB and Yahoo logins, but more is coming (google & twitter I assume). And it is integrated very nicely to Facebook. I myself don't like Facebook spreading to every single website, but I showed this today to one of our clients and he was amazed and wanted it right away. So probably it will spread, whether I like or not

True. Sounds simple and clever!

Thanks, glad you like it so far. The examples you mentioned should work well. Though I would probably recommend using URL segments rather than GET vars, so that the template output can be cachable. (GET vars aren't cachable at the template level).

This is good to know and thanks for clarification. So if I have any GET vars then template is never cached?

This is great feature. But how about sorting page reference list? I think that setting should be on field settings, but cannot find. Should I use "Alternate/custom code to find selectable pages" to get sorting I need?

We have over 30 products and "Related products" field is pretty messy to use.

Thank you! Just updated and I can confirm that it works.

I like the fact that moving to trash doesn't remove page references that other pages has made to it. So if you have to undo your trashed page all relations are still working.

This is great news and great to get more well coded and commented examples to help module development. Haven't tried yet, but if I read correctly it should be trivial to create normal template, but add in top check if $input->get->format == rss and render rss instead of normal template.

Show we could get urls like: www.domain.com/news/ (normal news listing) and www.domain.com/news/?format=rss (rss feed).

Other way to handle rss for whole site would be one rss-template: www.domain.com/rss/?page=321 or www.domain.com/rss/?template=news etc...

I think after little testing this should come with processwire as default module (or do we call them core modules?).

Ragnar: Welcome to the forums and thank you for letting me know and providing fix also. I'll update AdminBar soon.

There is also few other issues currently:

• Another css problem when you don't have margin: 0; padding: 0 on your lists
  
• Changing template won't work (same issue in other settings also, if they require confirmation step after saving)
  

On the good news, AdminBar works nice on IE8 (well, modal background is not showing, but that should be an easy fix).

I got this on my template:

foreach($page->related_people as $person) {
        echo "<h3><a href='{$person->url}'>{$person->title}</a></h3>";
}

If that related page is moved to trash, then output will be something like this:

<h3><a href='/trash/5785_title/'>Title</a></h3>

Probably not desired effect? Shouldn't pages on trash be always hidden or at least some way out of normal API-selectors?

...except the fun starts when you need to say 'you saved %i pages' – there kicks in different 'amount forms'

Is there any way to bring it down somehow in finnish?

That is in Finnish actually simple, since we have same plural if the context is same. But many other cases it's not, and then we end up saying something like this (this is what I call dummy language):

You saved multiple pages (4).

OT: Heh, that is cool. Stina is a girl's name here.

I think we can automate the field creation part relatively easily. My plan was to add an Export/Import option to Admin > Setup > Fields, and it would basically export a JSON profile of all the fields you selected. Then you could paste that profile into another site into the "import" textarea, and it would create all the fields. The same thing could probably be done at the template level too.

Sounds excellent. Only thing to consider is when there is different fields with same name.

Simple field & template modules: Thanks for your example. Looking that code I realize that I did exact that thing with AdminBar and Sitemap-page I think that is pretty straightforward also. I'll take this route with most common needs (news/blog, event calendar etc) where I need one button installs and all others could go with field export/import.

Great topic Adam. In Finnish we can easily have few thousand versions of the same word. See example these 2253 versiions of word "kauppa" (shop): http://www.ling.helsinki.fi/~fkarlsso/genkau2.html

So it is pretty much same thing here than it is at Slovak I guess. No easy solutions. Complete phrases or some dummy language.

Page was created: Sivu luotiin.

User has created a page: Käyttäjä loi sivun.

Page cannot be saved: Sivua ei voitu tallentaa.

You can bring more content to a page: Voit tuoda lisää sisältöä sivulle.

On the other way things can be said in many different ways, but usually if we need to use basic form of the word, it ends up sounding dummy. I think important thing is that if there is some thing in phrase that can be different every time (let's say page name), then that it could be in different place also in different language.

Poor example, but:

English:

printf('You saved page %s succesfully', $pagename)

Finnish:

printf('Tallensit onnistuneesti sivun %s', $pagename)

+1

I don't know if there is already a way to do this.. but what I need is some way to import fields & templates to new site. I try to explain:

Let's say I create template "news" and it has fields:

• Title
  
• Datetime
  
• Summary
  
• Body
  
• Author
  

I have created few template-snippets that like "Latest news" and "All news" etc. This is all fine and easy. But after this next client comes up with similar request: "we also want to show news on our site." (I say that 95% of our current clients have news on their site.)

How can I easily give our next client these same fields & templates? Process could be import from other site or anything. Or should I create module "News" that creates needed fields & templates?

And this should be easy enough, since after news we need have some formal templates for Events and maybe Forum etc... This all may sound like it is fighting "against" flexibility of ProcessWire, but I don't think it like that. After client asks "This is allmost what we need, but our News will require also Attachments and Place fields." it is trivial to extend their News-template, but leave others as is. Just some conventional ways of doing things, that we can write help docs and all people on our organization can help clients etc.