mikeuk

I will test this again later. I'll need to re-do it as I changed it to hard-coding it into the template just to get it done. "blocks" was the name of the field, there was a template attached, not sure what the value type was set to (but i guess it must have been multiple)

That's good to know. Is that unfolding to do with OO software? I've never seen anything like this in Drupal, though that is not always considered OO (especially older versions).

The $page->fieldtypePage object that I printed was a page with a field type Page attached, which contained a link to one page only (which has 3 fields within it). The printed output of that object was pages long. I see no reason this how PW normally is as I have no modifications to affect it Quite possibly. As I said I wasn't judging it on my own site performance as there are other issues (it's on a preview domain for one). I was more assuming such a large page object could affect performance

Rendering issues were https://processwire.com/talk/topic/15721-displaying-content-of-page-in-page-field-type/ But wouldn't the size of the object affect performance? If printing it takes over 1 minute, doesn't that signify the object is very large, and that still has to be passed to the page? I was noticing sluggish performance compared to a previous site, though I hadn't gone deeper as there are other non-PW factors I'd have to address first.

Only meant to be polite to forum (and adrian who'd helped with method I then gave up with) - https://processwire.com/talk/topic/15721-displaying-content-of-page-in-page-field-type/. Not really linked.

(apologies if this looks too similar to previous topic I created, seems more logical as a new topic) I'm curious if anyone here is implementing something along the lines of Drupal's block / Joomla's custom (editable) module functionality? In other words, areas that are editable in the backend, that can be placed on multiple pages without needing to re-enter the content on each page it is used. I tried to do this using a page as a block, and then field type Page (to get a page within a page), but this led to issues with rendering, and more important this creates an object $page->fieldtypePage which is exceptionally large, so I would prefer to avoid that route. My guess is those that do it, do it outside of PW with PHP. But the 'blocks' being editable and creatable by a site editor is important so I need to explore this or find a different solution (or tell the client no-can-do).

I've been experimenting with field type Page, to add a page within a page (to replicate a block like system). I encountered some issues rendering the results, and while debugging and displaying the $page->fieldtypePage object I realised it was huge. I mean 1 minute to display huge. Even though in normal operation, printing out the whole object wouldn't be necessary. However I presume having an object that large must affect site performance. I won't be using this field type Page any more because I'm a bit of a fanatic for clean code and good performance. But in general, what do you think? Should this be submitted as a bug? If so, what's the correct procedure for that?

The foreach displays the same error but also without the display of the block (whereas before the block was rendered with the error after). With the first() example, I got a 'not callable in this context' error. I tried all variations I can think of, including a looping again though $block (which displayed nothing). I'm guessing this is an issue with the field type Page. Perhaps there is an issue with the way the object is being built by PW? I guess I need to change the whole approach here. It's frustrating because I could just at footer php file which calls the footer fields, and hard code (include) it into the template, but that kinds of defeats the purpose (I really want the site editor to be able to add, for example an area above or below the footer in the backend which relates to a change of frontend display. This is where systems not getting in the way of how we work, get into the way of what we want to do........ Frustration aside, I guess what I really need is a blocks module. For now I'll just hard code this and later see if I can create a module to do this. EDIT: One thing I notice here is when outputting the whole object of $page->blocks, it is huge, over a minute to display it all. So I'm guessing that is the heart of the issue. After seeing that I'm guess field type Page is not ready to be used as I would have though an object that size must impact on site performance. Interested in any thoughts on this. I'm guessing all PW objects are not so large.

One addtional question. with $page->blocks->render() where blocks is a field type Page (and the page attached has three text fields), I'm getting the blocks rendered fine, but when logged in, underneath is the following error: Error: Call to a member function render() on a non-object In this case, does render() need a parameter?

Yes! Thanks that's exactly what i need. I missed render() in the docs. Just searched for that function and saw a page that i need to know more about (and may be useful to other newcomers): https://processwire.com/api/arrays/page/

Do you know of a way to do this without knowing in advance what fields blocks contains? This is important because I want the site editor / manager to have the ability to add / change the fields (pages) within 'blocks' I'm thinking aloud now..... would it be a case of getting the array of the fields within blocks for the displayed page and then going through each array element to output? I didn't initially look at this area as I'm seeing what is possible before going into pure PHP territory.

I'm confused by how Processwire should display custom fields. I have Home page set up with a field type Page (called 'blocks'), and that field has one page selected (called 'footer'), and that page contains 3 fields. The idea is that this footer page is reusable as a block on any other page, while also being fully editable in the backend (and only needing to be edited once to change on all pages). This is as close to a Drupal blocks approach as I could get. In principal, certainly from the backend, this is working fine. It's clear enough for a site editor. The issue is how to display this 'blocks' field (the page attached to it and content of fields that page contains). This system only works if I can display that field, without needing to specify or hard code the page name within the field, or fields within that page (because this may change later). The one constant will be that the 'blocks' field is always linked to selected page templates. Based on what I understand of Processwire logic, because I display the title with $page->title, I would have expected the following to work: $page->blocks or $page->fields->get('blocks') This however only returns what I presume is the field ID. I have looked through the docs, but they are light on highlighting typical uses (perhaps an example for each api element that shows how it works and why it exists in relation to backend data to frontend display, similar to the PHP manual. Something perhaps I can help with at a later date). I also think this is a type of issue can be a deal-breaker for new users because of the logic gap ($page->title outputs field content, $page->blocks outputs what might be field ID), and us newcomers can be an impatient group! So I hope solutions here will be a useful addition to the docs. After I learn how to deal with this, I'll add any info that might be useful for newcomers.

I realise an old thread, but just had the issue then realised i'd made a basic mistake. Hadn't granted all user permissions for new db. After that was fine. I didn't need to do anything else. This might help some others.

In this case, maybe pages also, but good to know for the future. Interesting read. Would need to go through that a number of times, but good to have such information in one place. With that and some other examples, problem solved. In case anyone else needs to know about this, to get what I needed (or close enough), I used the Page field type with Input type as PageListSelectMultiple, then added multiples selections to pages created to be the different groups. Thanks all for the help.

Thanks! Looks good, reading up on it now