Soma

There's currently no option for that as far as I know. But I think it would be possible to implement. For now you could add something like this to your inputfields.js of the admin theme, "teasers" being the field name of the repeater. $('#wrap_Inputfield_teasers ul.Inputfields.ui-sortable > li').addClass("InputfieldStateCollapsed");

I have no idea what you're talking about. Maybe screenshots will help. You can collapse fields by default, or when they're empty or filled in the field settings. Is that what you're looking for. Do you mean to collapse the repeater fieldset by default, like the one for fields?

Joss, that's exactly my green! I think it would ne nice to have $pages->isPublished()? Also not biggy to add and make it coherent. $page->viewable() will - return false also if there's not temlplate file found for it. - It will return true even if published, but the user has edit rights. There's $page->isTrash() $page->isNew() $page->isLoaded() $page->isChanged() $page->isHidden() why not $page->isPublished()

I'm just seeing it there's this sidebar boxes, really nice!

What i also forgot to add ( my brain ) is i would have problems where to draw the line between php and pw mb just throw in some php manual links here and there.

And all because theres no pagePublished? :-P I thinks sounds like a cool concept. One thing pops to mind. There is so many ways to archive one thing you can hardly cover all, and youd have to make sure they are seen as one way to do it, practices and examples. Not set to stone that people think that's it exactly. This is where it can get complicated. At the end it is important to understand the consequences a certain approach may has and what needs to be accomplished. Since you do also all of the front end coding and there's even more variation that can happen there, there will be a lot of the non coders lost and a lot of assistance is needed. For me PW got me started thinking a lot more before doing something and a lot comes from trying out different things, adding some fun and think about structures. What i'm trying to say is maybe PW is more a way of thinking living breathing rather than 'this is the way...' Im excited to see it's growing thanks so muchos Joss!

This is a joke not?

echo "found: ".$pages->find("template=match, team_1|team_2=$user->teams");

I just setup something like you mention and it works flawlessly. I have user template with page field to select multiple teams. A team template to create team pages. A match template with two single page fields for tema1 and team2. If I give teams to user and create match pages with teams he is in it gives me the right matches for me.

Just joking.... it should work. But take a look again at your error message? Not unique table/alias: 'field_team_1' Somethings with wrong with your field, table? I don't know really.

There's no support for team_1|team_2=1011|1014|

I often use open in new tab to have a page, template or field screen open. Not trying to convience you, I think you know that

I build a tool for page mass creation: And a tool to list pages and data in a table and have an edit link that opens in a modal: Tool like this are great and easy to implement to one needs.

Did you know the cheatsheet already: http://processwire.com/api/cheatsheet Not in relation to your question, just so. What apeisa said. Also the statuses is a bitmask, not that I understand it well, but it's like making visible and hidden both a status, which doesn't make sense it's either hidden or not, then it's visible. I'm not sure this makes sense. And only Ryan would be able to share some light, why it is how it is.

I don't like to change the way it is, because I like it the way it is. But that's ofc only me. Something that may take alternative routes with modules or custom admin template makes sense. Look at my teflon theme that does some things like dropdowns. Or my shortcut module, which makes "alt+q" and opens an autocomple dialog to search for pages, click enter and you're tehre, without even leaving and not matter where you are in the admin. I like the flow and all possible things that can be built on top of the simple approach. I wouldn't like if we change the admin to a state where it's assuming too much things that may not useful for all, or to their likings, and make it hard to change it from there with modules. For example build bustom admin pages and widgets that could help doing stuff like popups. Instead of changing the current admin flow. I'm not saying it's all bad (maybe I didn't understand all), but think about it a second. Just my 2 cents

Feel free to take it and improve it. Make it your own whatever and be sure to submit it to modulers page. You're welcome. Glad if it helps people.

Updatery I just pushed v 1.0.3. to the master to https://github.com/s...nic/ColorPicker added support for default value added reset link to set back to default color some cleanup and added readme finally updated first post

Ok fixad tha issue, damn no off to some relaxing

Nice idea, I was also thinking about some time ago. One way is to not extend the InputfieldTextarea, and make a new Inputfield type, but Hook into the necessary methods to extend the config and rendering. Since this made me wonder how it would go, I gave it a try. It's a nice example showing how to archive it using hooks only. It will give you a extra Input setting "Max length" in the field setup. And a counter for all InputfieldTextarea (not tinymce fields) and add a attribute "data-maxlength" to the one that have a max length value. I had to use "maxchars" as the setting field name as there's already this attribute, but not used in the context of page edit. The script js is also added via a hook, and is a basic example of the script that counts backward while typing. Since I was already that far it was easy to add, but you might want to modify it and add features if you like. This took me roughly 30min, and little more to add the js. I think a year ago I wouldn't knew how and would have taken ages to figure out. But it grows on you after so many modules and insight. This module shows you some good practices and maybe helps understanding modules. If you have questions please bring them in. Module code: https://gist.github.com/4252958 JScript code: https://gist.github.com/4252962 Put them in a folder /site/modules/TextAreaCounter/.. Install, enjoy. Edit: just found an issue... will take a look again

I have implemented a default value you can set in the field settings. Which means you can decide for yourself. i.e. "EAEAEA" or "". Which has effect on how you can test the field. Not sure how others have implemented the colorpicker, but this would be backward compatible if you set it to default "FFFFFF" as before. And a link "reset" alongside every colorpicker. I'll have to test a little more, but it works fine but haven't had time to commit the changes.

As you may noticed or not it has FFFFFF as default value. You could test for it. Im not really sure if having it this way makes sense for a color field or not. Resetting the value to default isnt implemented simply bcause I havent had the need. Maybe a button or something to reset would be good.

You have to look for max limit.. I think then its under details. Its not a dropdown you just set how man images are allowed.

It's set in the field settings. Got Setup -> fields -> yourfield. Then in the input tab, you can set the things you need.

Welcome henriette. There's several ways to archive what you want. Your ideas are on the right track, you definately want to create some "/footer/" page where you could enter the content for your footer then output the content of that page. http://processwire.c...-settings-page/ Single page approach: If you create a template "footer" and in the php file you just would output the markup and data of the page. You can make this page "hidden" to not show up in navigation. Then in your main template, where you would include you just render the "/footer/" page like this. echo $pages->get("/footer/")->render(); and the footer page template would be this (just example. <div id="footer"> <?php echo "<h3>$page->title</h3>"; echo $page->body; ?> </div> Subpages or repeater approach: You could use repeaters or just subpages to create the 3 blocks. Repeater module is a great way to "repeat" a set of fields. It is not installed by default. See infos here: http://modules.proce...dtype-repeater/ If using subpages you would create children pages under maybe a page "/footer/". Then output them like this. $blocks = $pages->get("/footer/")->children('sort=sort'); foreach($blocks as $block) echo $block->render(); If using repeater, it would be slightly different, but the repeater field is like a field that holds pages, but since you can't use render you'd have to output markup too. If repeater field is named "footer_blocks" with title and body field inside you'd do it like the following: $footer = $pages->get("/footer/"); foreach($footer->footer_blocks as $block) { echo "<h3>$block->title</h3>"; echo "<div class='footer-body'>$block->body</div>"; }

Ah yes, that makes sense. Still the $page_temp->editable() could be used in that case too. $this->user->hasPermission('page-edit') is not page context aware, so a user could see it for pages he has no edit rights. Well while testing I found it works with the user->hasPermission() if you do it with a hook on before render. $this->addHookBefore('Page::render', $this, 'changeView');