valan

MPP, thanks! Will check if after "->add" it works.

PW 2.3.1 PHP 5.3.x, script runs in template. I'll upgrade to the latest dev next week and check if problem still there. Thanks for tip with of(false).

MPP, thanks for reply! $mypage it is not PW api variable . It is created in the php script as below: $mypage = new Page(); $mypage->template = 'mytemplate'; $mypage->parent = 'path-to-mypage'; $mypage->name = uniqid(); $mypage->of(false); $mypage->myproperty = $somevalue; $mypage->save(); $mypage->of(true); Its child Pages are created in the same way after $mypage. Problem in brief: in the same script $mypage->children doesn't work (returns empty PageArray), while $pages->get($mypage->id)->children works (returns non-empty PageArray with all newly created children Pages).

Recently I've discovered unexpected (for me) behavior of Page children property. My scrip creates several pages - $mypage and its few child pages. Within the same script this code "$mypage->children" returns empty PageArray, while this code "$pages->get($mypage->id)->children" returns expected children PageArray. Is there any way to stay with "$mypage->children" syntax? E.g. may be I miss some step during Page creation that properly initializes this property?

Hi slkwrm! Merry Christmas and thanks for solution!

There are pages that can only be accessed by defined logged-in PW users (checked via api). Apart of inaccessible (for others) fields, these pages have File input field. In PW all files are stored in .../assets/files/<page_id>/filename. These files can be accessed by everybody, e.g. it compromises security. Q: How to restrict access to files, depending on PW $user?

Thanks Soma! Pete did exactly what I want. But I'd stay with the suggestion that "generate children page unique name and jump directly to edit with template X" should be embedded into admin interface for any template. As I see it - it is too common task to be left for developers only. )) Thanks!

Soma, thanks! Looks informative enough to solve (1). As for (2) - I think that it is not good to compromise interface usability in favour of some fields requirements (even Page field ))). I'd rather suggest to handle such situations in these fields. But as far as I understand, solution may require some core modules re-thinking, so leaving it for Ryan consideration.

When PW admin user creates new page it gets "first screen" with title, name and template fields. For better usability, for specific templates I need to skip this "first screen" and let user directly enter page editing. As I see it: (1) template should be selected automatically based on parent page template "allowed children template(s)". Only if there could be several templates, then user should be advised with "first screen" and the only one "select template" field on it. (2) unique "name" field should be assigned automatically on page save. Page should not be saved before editing as it happens now after "first screen", only after editing/saving. "Title" field is not global in my setup. I guess the answer is to "use hooks", but I need some help to understand which functions to hook and how to check/supply template in (1) and manage saving-in-the-end in (2). Thanks!

I've recently discovered Page Autocomplete module (great module for large sites btw) and decided to use it at my site. It works but not in the way I'm expecting. Or at least not as described at module description page. (1) "Autocomplete Advanced Options" do not appear in Page inputfield admin interface. As a result I can't include "non-title" fields to the search. (2) "Template of selectable pages" settings in Page inputfield admin interface doesn't work together with autocomplete. E.g. I need to limit search to selected templates but can't do that. I'm running PW 2.3.1 and PHP 5.3. Thanks in advance for your help!

Soma, I had the same error when I've deleted select parent page... then I've created new one and updated field select parent page - error disappeared.

Wanze, thanks! Yes, own coding is solution. I just think that this is a typical scenario. Therefore it is better to have it "in PW template settings", e.g. adding {url} tag (by analogy to available {id} tag) which may be replaced by original URL string value.

I have the following scenario: User receives email with link that has GET parameters (smth like http://mysite.com/mailbox/?message=1234). Since user doesn't have access to this page (e.g. not logged in), first of all, system should redirect him to login page (e.g. to http://mysite.com/login/) and only after succesful login - redirect user to initial link. First redirect can be configured in PW template access settings. However, as far as I understand, optional {id} tag will only be replaced with page ID (e.g. http://mysite.com/mailbox/), but GET parameters (e.g. message=1234) will be lost. So, how to receive these GET parameters (message=1234) in http://mysite.com/login/ ?

dharmanerd, thanks! It works for own templates but doesn't work in page admin frontend. Perhaps Rayan should look at it. Thanks!

Hi! I'm setting it in field admin (e.g. Setup->Fields->myIntegerField->Input->Minimum value).

Privet! I've just found that if you create integer field with minimal allowed value 0 (zero), then it doesn't save it. As a result, input accepts negative values even with HTML5 input type. Is it a bug or feature?

Yeah, got it. Thanks!

Thanks for hint! Is it possible to handle several forms at one page using these CSRF protection methods? I've used code above for two forms and got identical token names and values... Thanks!

Sublime Text 2 with plugins: + Package control + Emmet + JavaScript + jQuery + DocBlockr + PHPcs + PHPTidy + Prefixer + SublimeCodeIntel + SublimeLinter + SFTP + SideBArEnhancements + BracketHighlighter + TrailingSpaces + Alignment + Goto Documentation + Search Stack Overflow

Hi! I don't know how it works, but it works )) I've just reconsidered script logic and changed few lines, specifically search field in selector from title (PageTitleLanguage) to name (system/not multi-lang): $selector = 'template='.$template_name.', name="'.$pagename.'"'; $p = $parentpage->child($selector); // do we already have this category? E.g. the problem is probably in title field. Currently I don't have live example, may be Sevarf2 has it?

Hi! Issue with concat was in another thread http://processwire.com/talk/topic/3690-page-cant-be-edited-if-admin-has-non-default-language/ and thanks to Ryan, it's been successfully fixed with update in FieldtypeConcat.module. E.g. here we have another error. Currently I use workaround, e.g. construct selector with other/non-multi-lang fields, particularly use name field and don't use title field (type PageTitleLanguage).

Solved with new version of FieldtypeConcat field.

+1. I'd also impatiently wait when Page Link Abstracter will marry TextAreaLanguage. Currently admins running multi-language sites have to do double work, updating changed links and it is not something admins like to do ))

Hi Ryan! Thanks for attention to this problem. Yes, 1439 is default language page ID. I'm using 2.3 now. I'll switch to dev branch and let you know the result. Thanks!

Yes, newly created page has title in both languages. Tried to save twice - the same error.