apeisa

Strange. I have double checked that this isn't browser cache issue or something like that. I have multiple sites having this issue currently (I have /wire/ as symlink, I test with few sites and if all runs correctly I update all our sites). Also tested with multiple browsers and users. I will test this more later on. There is nothing too special running on those sites. For some reason js file posts two times when files are dropped. Or have there been index.php update required or something like that?

I recently updated to latest PW and it seems to have introduced one bug: when drag 'n dropping files it doubles the file and starts immediately two upload bars. I tried to figure out which is causing this behavior, but couldn't figure out.

That damn module is always ruining all the fun.. damnit! To be honest: I need to check the code if there is something I could do to make it behave more like normal image field.

Diogo: actually not my method, just a implementation of the idea that Ryan got here in this topic. screen.width looks for actual screen resolution, not just window width. So it does work, you just cannot test it easily on desktop.

Or put the redirect url as a get param: <a href="/loginpage/?goto=<?= $page->url ?>">Login</a>

Looks cool. We are currently using Trello.com, that is nice one too.

I think that is good way to go in longer term - but I guess first we do need some signs that there is enough contributors for the wiki.

That means we module developers need to update version numbers...

Browser cache maybe?

Just add first() before ->url. I guess you have an array instead of single image.

Raydale: I was thinking about at least post to showcase, since that was interesting project. It is actually using multisite module together with this site (www.marttaperinne.fi). But I have been very short of time, so this will take little longer.

It seems to be missing from Field selection, so you probably need to use API for that (might be available on advanced mode => edit config.php and try then). One way could also be duplicating the admin template, so your new template would have Process field assigned.

First make sure you do have latest version, pw gets minor updates all the time without getting new version numbers.

Ryan: I think that sounds like a good way to go. Actually 2.2. is pretty huge: Multilang support Repeater (a la matrix) Field context settings Field widths Page cloning Page publish -permission Datefield improvements Did I forgot something? So having little bit faster and thinner 2.3 just makes sense. If form builder is dropped, then there are only 3 items on the roadmap: Addition of a Page History module, enabling one ot track revisions/versions of page edits. Field duplicate feature in the Admin > Setup > Fields. JS session monitoring to handle multiple users editing the same page. About form builder: I gotta say that I love what Steve has done with his form classes. What I think could be possible roadmap is to build js form builder that outputs the required code for Steve's class. Then PW would just have a module which allows creating those forms (using that js form builder), saves entries and allows admins to browse those entries.

There is history module on the roadmap for PW 2.3. (May 2012) How do you feel about schedule on this one Ryan? There are two big features planned for 2.3 (this and form editor), so I don't think that May is realistic - or is it?

I try to implement it soon. Btw we already published our first shop using this module: http://www.martanpuoti.fi

And for the record: I haven't used the page-publish permission myself, but that is my strong assumption on how it works. Please do report if it doesn't

Those all use admin-template, and they all have processModule behind them. If you are looking for code, then they can be found /wire/modules/process/ (https://github.com/ryancramerdesign/ProcessWire/tree/master/wire/modules/Process). But modifying those files is not the way to go here (you should never edit files under /wire/). If you want to have this done: Then you need to do this: Create two roles, user and editor Create new permission, give it name "page-publish" (name should be exactly that) Edit those two roles, but add page-publish permission only for editor, but page-edit for both of them. Other permissions as you see fit. Then edit home-template, access tab and allow edit / create / children for both editor and user roles. Now your user-role users should be able to create and edit pages, but not publish them. Editors should be able publish unpublished pages. Just for reference, there is the commit when this was added: https://github.com/ryancramerdesign/ProcessWire/commit/330d04d7054f27ce4cd8ed86952f270875488c55 (also be sure to run no more than 2 months old version of pw).

You can use it in your template code and in your modules like this: $permission = $permissions->get("change_status"); if ($user->hasPermission($permission)) { echo "You have a permission for something"; } else { echo "You don't"; } I guess there is only one additional permission that you can add and it has a meaning, and that is "page-publish" I mentioned earlier. If that permission is created, then that is also required to publish pages.

biotech: that tiny code snippet is used only when building process modules, which are kind of custom admin modules. For basic permission management workflow is this: a) Create role b) Add permissions to role c) Add role for a user d) Edit template -> access tab -> and "activate" page view / edit / create / add permissions for each roles there.

There is wiki talk going here http://processwire.com/talk/topic/1167-pw-manual/, although with different angle: for end users. I think it would be nice to have developer wiki at some point too. I think currently we can manage things like this pretty nicely using this forum.

Permission system is tied to templates. So you need to edit template and there you can click which roles do have page-edit permission. If you have simple site, then it is most probably home template that you are looking for. For having permission to publish pages: in default installation it is tied to page-create permission. But if you create page-publish permission, then that is used instead (which allows your scenario to have some people add new pages but not possibility to publish them).

Soma, this is totally different: I have build voting application (used for elections etc), where I save each vote as page. There are different kind of voting mechanisms, since in some elections each voter can give something like 40 votes. So if I have 300 people voting, it can create 300 * 40 = 12 000 votes. What I need in this situation is those 300 voters, not all those votes. All this data needs to be real time, so no use of any kind of cache. Also the original problem was that I was running out of memory, so no cache help here. Sorry for being mysterious about my use case - I tried to simplify it, but ended up complicate it for you guys... I got this working nicely, this is what I ended using (basically stripped down from Ryan's example SQL): SELECT ref_page.id FROM pages JOIN field_v_voter AS ref_field ON ref_field.pages_id=pages.id JOIN pages AS ref_page ON ref_field.data=ref_page.id WHERE pages.parent_id='$id' GROUP BY ref_page.id; In this case I have 4500 votes and 244 voters. It doesn't even blink an eye to load, even if I end up loading each of those voters. It was pretty much opposite resolution when I tried to load those 4500 pages in memory and then those 244 in addition... Also, this was very helpful to see, that it won't be that bad or mysterious if you need to get into sql level here. In simple cases like this it won't be that difficult sql after all. Although now it seems clear that in this particular application it would have been much better idea to use custom table instead of pages. SQL would have been this: SELECT voter_id FROM votes WHERE election_id='$id' GROUP BY voter_id; Also it might be nice idea to add "who has already voted" table to keep those ID:s. Thanks guys again!

Thanks Ryan, exactly the information I was looking for. My scenario is that I need to parse children pages. There might be easily many thousands of those children, all using same template. There are one particular page reference field on that template that I am looking for. Let's called it referenced_page. What I need is all unique "referenced_pages" that are used in children pages. This is one way to do it, but while page count goes up, this will be impossible: $a = array(); foreach($page->children() as $p) { $a[$p->referenced_page->id] = $p->referenced_page->title; } (currently I ended up doing it other way around, first loading all pages that can be referenced_pages, then looking if any of $page->children() has it as referenced_page, then go to next. Reason for this is that there are much less possible reference_pages than there are $page->children. This works now, but got me thinking about better way of doing all this.) I will definitely play with your examples if I can make this faster. Although I might be looking solution from wrong angle... What would be the ultimate solution would be something like this: $children = $page->children("referenced_page.unique"); foreach($children as $p) { $a[] = $p->referenced_page->id; }

This will help you a lot: http://php.net/manual/en/function.http-build-query.php Simpler way is to always have all the parameters on links, but set them zero/empty when not set, so your urls would be like this: ?region=0&sort=title&type=0 ?region=123&sort=0&type=item etc...