diogo

I don't think it should be fixed in the module. The behavior is correct and it's good that guest is on the list so it's absence doesn't confuse people. Because I consider this a small annoyance, IMO the best place to fix it is javascript.

$cheatsheet->push($pages->getById());

Hm, not exactly. I would only use the same template in the situation that you described: pages are siblings and share lots of common info. In some cases it just doesn't make sense to use the same template. Yes, this only affects the admin, in the template file you don't have a way to know that these fields are grouped (at least that I know of...), so you have to find a way of determining if the editor wants them to be active. I mentioned checking for one field, but you could use a checkbox inside the group, so the editor can activate it manually instead.

eheh

Or hover the edit link on the tree and see it on the status bar of the browser.

I really don't get these laws... they assume that everyone is dumb and remove all the responsibility from the users. For me, as a user (I'm not even talking as a developer) it's quite irritating to have all those popups and bars bout cookies, and I agree with sinnut that this will only make people ignore them at a point where I can put a popup in my website saying "do you agree to sell me your soul for a pack of cookies?" and everyone will say yes. For me the ideal would be that websites would be forced to have a "cookies policy" statement on the footer or something, where someone that is interested would know where to find it. Or to agree on a meta tag, that browsers would choose how to show people, for instance chrome already shows info about cookies if you press on the left of the url bar, the info on that meta tag could go there.

@krems04, site/templates will for sure appear in most urls for js and css, but I don't think it's sufficient for identifying PW. But it sounds more than possible to have a pretty accurate guess only from the already referred characteristics.

Nico: http://try.github.com/levels/1/challenges/1 http://rogerdudler.github.com/git-guide/ http://ndpsoftware.com/git-cheatsheet.html

- Edit: Forgot to mention on my previous post. By using a fieldset you can still change layout based on if it was used or not. Just choose a field that wouldn't make sense to be empty, and check if it was filled or not: if($series_name != "") { // series post layout } else { // normal layout }

100 sounds like a limit to me... edit: another option would be to have a hidden page called "navigation" with a pageFieldType multiple in it where you could list the pages. 97 to go

If you have more than one template, you will force the editor to choose each time, while if you have only one, you can force the children of one age to use that template removing this step when creating a page. The ideal for you is to use field sets or tabs. Play a bit with the fieldstypes FieldSetOpen and FieldSetTabOpen. The first allows you to group a set of fields and even collapse them under a common bar. The second moves those fields to a new tab.

A session also puts a cookie in the browser, so the user has exactly the same control over it. They would just have to clean the cookies or use another browser to reset the counter. I think you would have to have some kind of login to track this.

Hi valan, welcome! The user-types that you refer are the roles. You vcan create as many roles as you want and assign them to users individually. Roles in itself don't do nothing, but you can define what they will do in the admin (via template access) or in your code, by using the API: if($user->hasRole($role)){ // do something } Unauthorized users would be the default guest user. You can redirect them to the sign in page by defining access on the templates or by putting something like this in your template: if($user->isGuest()){ $session->redirect($loginUrl) }; As for the individual profile pages, you can check them like this: // assuming that the profile page of each user has the same name as the user if($user->name != $page->name)){ $session->redirect($loginUrl) };

Joss, this is not fado at all... Mariza is good, but not the only one SiNNuT, the ironic thing about that link, is that they did it for mocking at others but their portfolio is not much better

Ya, that also works with me

Soma, doesn't work with me. Did you try saving?

This message also irritates you? I did a small change on the file ProcessUser.js to get rid of it. This simply checks and disables the box with javascript. edit: something went wrong, and ths is not working. i will investigate why $(document).ready(function() { if($("#Inputfield_id").val() == 40) { // guest user // hide fields that aren't necessary ehre $("#wrap_Inputfield_pass").hide(); $("#wrap_Inputfield_email").hide(); $("#wrap_Inputfield_roles input").attr('disabled', 'disabled'); //$("#wrap_submit_save").remove(); } // Check and disable the 'guest' role checkbox $("#Inputfield_roles_37").prop({ checked: true, disabled: true }); }); edit: Ok, solved. Apparently disabling the box prevents it's value to be saved also. I went around it like this: $(document).ready(function() { if($("#Inputfield_id").val() == 40) { // guest user // hide fields that aren't necessary ehre $("#wrap_Inputfield_pass").hide(); $("#wrap_Inputfield_email").hide(); $("#wrap_Inputfield_roles input").attr('disabled', 'disabled'); //$("#wrap_submit_save").remove(); } // Check and disable the 'guest' role checkbox $("#Inputfield_roles_37") .prop({ checked: true }) .css({ opacity: 0.5 }) .click(function(){ return false; }); });

You're in luck http://modules.processwire.com/modules/markup-htmlpurifier/

Ya, in that case Macrura's solution is a good one. To sort at the end you could do like this: $images->import($images2)->sort("title");

Or like this: $images = $pages->get("/visuals/")->find("summary|title|tags.title~={$input->q}, sort=title");

Welcome Phil! -- Makes all the sense! You described exactly how I would do it For the portfolio pages don't forget to use Soma's Page List Image Label module. ...and I hope netcarver will show up to give you some tips on moving from txp to pw. edit: if you want to keep using textile, he is the one maitaining the pw module. Could hardly get better

Yes. It's the ternary operator http://www.tuxradar.com/practicalphp/3/12/4

and http://modules.processwire.com/modules/textformatter-tag-parser/

Title changed. No need to delete the posts IMO. They are part of the history

The downside of this technique is that if someone creates a page with the same name in the tree, it will unintentionally override this behavior.