Jeroen Diderik

I had an issue with a PageField too, although not with 2 PageFields on the same page, I ran into a limit. In short: if you have more then 170 (in my case reproducable) referenced pages in the field, AND the 'AutoJoin' is set, then when selecting more then 170 items (using for example SelectMultiple), after saving the page, the API will only return the first 170 items...and thus only 170 will be selected if you re-open the page in the backend. Here's my post on it in the forum

I found how to fix the problem.... disable AutoJoin field on the PageReference field..... Not sure if this is documented somewhere...that setting AutoJoin will limit your options when you have more then 170 references....

This issue is starting to tick me off I can see in the SQL traces, that the first batch of 171 ID's is collected, query NR 29 Then Query 38 requests for the remainder of the batch (38 ID's) I've really lost it... can somebody recreate the problem and maybe help out? Still not sure if this is a local issue of my installation or it's PW. Here's the pages setup: Home -- card_groups (template=anything_other_then_card_group, simple page as container) -- group_1 (template=card_group) -- group_2 -- group_3 -- etc. etc. in total of 208 -- MyPage (containing pageField with input SelectMultiple, referencing template card_group) Try and select all 208 groups on MyPage, save... and see if all 208 are still selected by scrolling down the SelectMultiple field....

It gets more exciting by the minute...the plot thickens.... I have now traced down to the core/Pages.php On line 447, an IDs array if filled with $ids[(int) $key] = $id; After 170 items of my page, suddenly the parent of those pages is encountered, with $key = 0 and $id = 'the id of the parent of my referenced pages' then it continues with the rest of the referenced pages, but starts at $key 0.... Scratch that... is first comes in with getByID for the card_group field, then for the parent of the referenced fields and then with all card_group pages.

Got a little further by looking at the SQL queries run. Seems I found a bit more info: The page containing the Page field is queried like this: (seen in the debug trace when on this page in the Backend) SELECT false AS isLoaded, pages.templates_id AS templates_id, pages.* , pages_sortfields.sortfield, (SELECT COUNT(*) FROM pages AS children WHERE children.parent_id=pages.id) AS numChildren, field_title.data AS `title__data`, GROUP_CONCAT(field_card_group.data SEPARATOR ',') AS `card_group__data`, field_fb_success.data AS `fb_success__data`,field_fb_error.data AS `fb_error__data`,field_max_checkin.data AS `max_checkin__data` FROM `pages` LEFT JOIN pages_sortfields ON pages_sortfields.pages_id=pages.id LEFT JOIN field_title ON field_title.pages_id=pages.id LEFT JOIN field_card_group ON field_card_group.pages_id=pages.id LEFT JOIN field_fb_success ON field_fb_success.pages_id=pages.id LEFT JOIN field_fb_error ON field_fb_error.pages_id=pages.id LEFT JOIN field_max_checkin ON field_max_checkin.pages_id=pages.id WHERE pages.templates_id=61 AND pages.id IN(1341) GROUP BY pages.id The part: GROUP_CONCAT(field_card_group.data SEPARATOR ',') AS `card_group__data` is what returns a full list of id's that are referenced... so far so good, got 210 id's But the next query that is run is: SELECT id, templates_id FROM pages WHERE id IN(1337,1338,1353,1399,1400,1401,.. etc This is where not all id's from the previous query are included in the IN ( ) part. it only includes 170 id's Hope anyone has an AHA moment... not sure why this is happening... still going through the processwire Core to find out where things are done.

Further testen: - created a addHookAfter('Pages::save', $this, 'pageSaveHook'); Logging the values of the reference field.. all selected fields are in there (when selecting all in de multiselect) - Checked the database values in my field_card_group table (the Page field is called card_group), all are there and saved properly... So... conclusion: drawing the multiselect or checkboxes... somewhere after 171 items, the others are not set selected or checked ... Search continues

Hi All, I've stumbled onto something strange. I have a Page field, referencing to a collection of pages of a certain template. There are 302 possible pages to potentially reference. The field is setup as a Multipage SelectMultiple (same behaviour with Checkboxes) When I select all the pages, it only stores a reference to the first 171. This is concistent, on different servers, with more then 171 possible pages to reference. It doesn't seem to be a limit of php, the data in the multipart/form is fully send and fields coming after this field are succesfully saved. So... is there some limit on a PageArray / Page field? Running PW 2.6.13

Hi, I understand what you are saying, I actually did that (sort-of) in a different site, using a pagefield in a user profile to 'connect' them to a page (in this case a hostel somewhere in the tree) and used that in the front-end to give them access to specific functionality as 'hostel owner'. This time I'm trying to customize the backend of processwire and don't wan't to mess with processwire's core files (apart from index.php which actually works great and is do-able when upgrading to newer versions, since this is the only file I need to manually check I'll give the Dynamic-Roles module a go and see if it brings me what I'm trying to accomplish throughout the application and hides the rootPages a client has no access to. Thx for the input!

Hi all, I've been working on this for ages, but I cannot seem to find a generic way to exclude pages (subtree's) from the admin interface depending on a known rootParent id. My case: I have a site-tree like: HOME - Client A - Client B - Client C My subdomain determines which client we are. I have a hookAfter in a custom module that attaches to: ProcessPageList::execute This filters the tree so that when the user logs in at: clientA.domain.com the pagetree in the admin interface only shows: HOME - Client A Thus filtering by rootParent But, I'm trying to hook into for example the Pages::find to make a more generic way of filtering, so that also the Search (ajax or lister) are working correctly. They now also return pages from the other subtrees like Client B etc. Is there a workable 'generic' hook to filter results within processwire? Background on setup: My setup is done this way to have a shared /site/modules, /site/assets, /site/logs etc. but to have a client specific /site-clienta/templates My core code in this application (it's not a public site, it's actually a narrowcasting system) is centrally managed within /site/ And templates are maintained within a clients' /site-client It is all running in the same database (so that I don't have to maintain multiple instances/code/settings etc) I made some changes in /index.php so that I have a $siteCore and a different $siteDir, this way, only templates are in the clients site directory. The siteCore also has templates, which are in code included in the clients templates if needed... This setup works great and is remarkably easy to maintain (shared templates, custom templates (overrides), central modules, shared users, etc.) The only thing missing is filtering all pagetree results (everywhere, but now mainly search/ajax results) by client rootParent. I looked into using permissions/roles, but the hassle to maintain it is not worth it... I already know by the domainname what to do, so I don't want to implement a different layer... The current setup allows me to very quickly add a new client by simply create a rootParent with a pageName like: site-clientD and a directory /site-clientD and /site-clientD/templates and I'm ready to customize it where needed, letting the core handle defaults etc.

First: thx for the great module, I can scrap my first attempt to something similar! Second: are there any thoughts on adding an option to add an already existing 'page' to the PageTableExtended field in the admin. Since I build a type of 're-usable widgets' for my client, they want to re-use already created 'pages', thus re-using content. Right now you can only create new 'pages', or I missed something along the way? I might dive in myself and see if I can add that myself, if time will let me, but I wonder how many others might consider this a welcome addition? And should that become a PageTableExtendedExtension or a new version of PageTableExtended

Bedankt Martijn! Any idea how big the Dutch PW community is?

Cheers diogo!! I will certainly put your comment through to them!

Thanks Matthew! This is on the list for the next revision

Hi All, First of all a big "THANK YOU!" to the community of ProcessWire and its founding father! It has been a great adventure developing this site with ProcessWire, allowing me to focus on getting things done! http://www.goaroundeurope.com On thing that was great, for me and for the site owners is the widget system I created. I used Pagefields for including a multitude of widgets that the site-owners place on pages in the site. They can create their own widget too and reuse them throughout the site. ProcessWire not only helped me during development, but the backend is very user friendly for the site owners. This was one of the major factors I considered when choosing the platform to build this site on. I only have to develop it once (and maintain/extend it ofcourse), but they have to use it day in day out....