digitalbricks

This seems to work: $items = $page->repeaterfield->sort('title', SORT_NATURAL | SORT_FLAG_CASE); Got this from Example #2 on PHPs sort() manpage. So in essence, you where right @da² – i just had to add SORT_FLAG_CASE. (Until today, i didn't even know that these PHP constants exists. Lesson learned 😉 Thank you!

I tried the syntax you provided, testing different flags – with no changes in sort behavior. But you pointed me in the right direction: As the documentation to sort() says, the second argument can be int or null. So i tried this one: $items = $page->repeaterfield->sort('title', 1); // note the 1 as second argument An this worked! I am still confused to wich sortFlag the 1 is "translated" but at least this solves the issue. EDIT: I was too hasty – the solution above does NOT work.

Hello community, using PW 3.0.229 I am experiencing a strage behavior using sort() on repeater fields: I have a repeater field with an title field and three items populated: title: "a" title: "B" title: "C" In the template i am calling $items = $page->repeaterfield->sort('title'); When i now foreach() over $items i get the following sort order: B, C, a When i rename "B" to "b" (lowercase) i get this: C, a, b When all titles are uppercase, i get what i expect: A, B, C So it seems that sort() is kind of case sensitive, sorting items with lowercase titles behind items with uppercase items. I never stumpled over this before – can anyone confirm this or knows a sorting method that does not take uppercase/lowercase in account?

Sorry @elabx, i've overseen your message until now. But no, I didn't figure out what's causing this issue. For my case, disabling the enforcement of the trailing slash solved the problem – but i am still not very happy with that workaround.

A tiny update: I replaced the wire directory with the one from the current MASTER branch (v 3.0.184) an now it works as expected. So maybe there is an issue in the DEV branch only (wich may or may not make the way in an upcoming release). @ryan FYI (Let me know if you need any more information about this)

Hello community, on a site with a simple blog, I am using Pages for blog categories. Therefore I created a template blog_categories as the categories PARENT page and another template blog_category for the CHILD pages. I configured blog_categories to only allow blog_category as children – and vice versa – blog_category to only allow blog_categories as parent. Having that set up, i created a field of InputfieldPage and configured it to have my (already added) blog_categories parent page as allowed parent and set template blog_category for selectable pages. I also checked "Allow new pages to be created from field". For the super-user this works as expected: Categories (pages using blog_category) can be created within the InputfieldPage field while editing a blog post. For my editor roll, i set up the following template permissions (beside the default view-permission): blog_categories – add children blog_category – create pages – edit pages Logged in as an user in editor role, I am able to create new categories in the page tree (as child pages to the categories parent). But when the the same user tries to create a new page from within the InputfieldPage, I get the "No access to add [template-name] pages to [path-of-parent]" error on no page is created. After digging a little in wire/modules/Inputfield/InputfieldPage/InputfieldPage.module, I found that $page->publishable() returns false in the corresponding check. But I don't understand why this returns false. In the page tree, the user in editor roll is able to publish/unpublish pages – also also to edit pages so it SEEMS there is a glitch in the permission check. Note: I didn't install the predefined sytem permission "page-publish" because – as far as I understood – if not installed the page-edit permission should also indicate the permission for publishing a page. On another site, using an slightly older version of ProcessWire, the same setup works fine. On the site in question, i am using 3.0.193 dev (DEV branch) – maybe that's the problem? Or I'am doing something wrong? I am glad for any hint in the right direction!

Hello community, in order to prevent the output of a paginated page – when there are no items for the given page number – i always used a 404 exception based on Ryans recommendation. Such as if($input->pageNum>1 AND !count($stores)){ throw new Wire404Exception(); } That worked well in the past. But in a current project throw new Wire404Exception() and also wire404() are both causing an infinite redirect loop. Having a look in the network inspector, i saw that there are ping-ponged redirects from e.g. from /page2 to /page2/ to /page2 to /page2/ and so on. Essentially rediects between the page WITH and WITHOUT a trailing slash. Fiddling around i found that this is caused by the trainling slash setting of the page template: This infinite redirect only happens if a trailing slash on the page number url segment is enforced – if the setting is "doesn't matter" than the 404 works as expected again. I really like to enforce the trailing slash but this seems to break the 404 exception handling. Did I oversee something?

I know: I am late to the party – but i have a question to the initial post of @ryan (see quote above): In a current project I want to display the comments list one a cached page (ProCache) and the comments form on another, uncached page. Unless teasered in the above quote, I didn't find an option in renderForm() to configure this usecase (posting comments to another page) – or maybe i am looking on the wrong place. So, does anybody know how to set this up and could give me a hint in the right direction?

Good question! I am also interested in Personal / Single edition of ProMailer only for usage on my own site. My clients are happy with their existing mailing solutions but I like the ideal of a mailing module directly integrated into my PW site. So it would be great to have the option of purchasing a personal edition of ProMailer!