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

I'm interested to know a good approach to grouping pages, where one page may be in two different groups (but re-using the same page for easy client editing). To clarify for those familiar with Drupal, there I would probably use Taxonomies, Blocks and Context modules. A taxonomy term for each group would be attached to pages (nodes), much like product categories would be, and menus and links would use Taxonomies (the Context and Blocks for displaying different elements on page depending on which group was accessed, but I don't need this part now) . Example organisation as follows (this is not PW Tree): Home - Courses - - Course One - - Course Two - - Course Three - - Course Four - Adult Courses - - Course One - - Course Two - Junior Courses - - Course Two - - Course Three - - Course Four - Summer Courses - - Courses Three - Special Courses - - Course Four (The PW Tree would need to be with only one occurrence of each Course page) I'm keen on the cleanest solution, ideally not adding modules, and a PHP solution no problem (though if it can be within PW as-is, great)

I do! If the Reno admin theme layout is your idea, then I want you ideas to carry more weight. It is a huge improvement in making PW look more current. Even though what ryan has built is excellent, the admin needed that different perspective and extra touch and from what I can see, your ideas were needed. Looking at the demo in ryan's post, it looks nice and clear but changing pages means pressing back button of going back to pages menu. I think the Reno sidebar approach works better. If it is in the way, it could be collapsible (or different when viewed on mobile).

This is true, and honestly i don't think PW would have kept my attention otherwise. Being it's own thing (not based on other frameworks / systems), I believe a user needs to know support is there. It is one of the best CMS communities I have been involved in. I've been hanging around PW for years, a number of times deciding it was not right then through trial and error ending up back again. It is no doubt one of the best CMS currently available. The thing I would like to see is PW making more effort to stay modern, I realise we are all a part of that process. Since I first looked at PW, a few other very catchy CMSs have appeared and grown (example, Grav, October, Bolt) and like PW, a few appear unchanged (I realise internally is not the case (Kirby being another one). And I don't mean change for change sake. I mean to keep an appearance of fresh, modern, vibrant because like it or not CMSs need a continuous stream of new users. And that also means making the new users journey as good as is possible within the realms of the CMS objective. So when I see a CMS that I really like that is not doing that, then I tend to shout about it because I have seen what happens to a big open source project that forgets this.

Thanks horst. Couldn't work out how to do this, and was early enough in the process to re-start.

I do completely see where you're coming from. I've never professionally worked with Wordpress (I could not bring myself to support it) but have spent many hours with Drupal and Joomla. Many errors encountered of course, some bugs some of my making. But I don't recall an admin-breaking error in that time. However, you're right about the 2.7 and MySQL version (I am on latest). I don't know why I didn't update PW before continuing the project, so i did play my part in causing it. True. But two thing about open source systems that I have experienced are 1) that most users don't post in the forums, and 2) most issues for new users don't get enough attention. Probably every day each known CMS will have many users downloading and testing it. Small errors they might try and fix, but breaking errors will send them running. And most never stop at the forum to say 'hey, what happened?'. Those users are probably lost forever, and won't be supporters. I'm not saying everything should be done to cater for new users. But the competition is fierce. I believe right now gaining popularity as a CMS means recognising what designers / developers need to give to their clients, and that a system like PW needs to a client who will ask 'why not Wordpress?'. The answer has to be because 'for you' it's better. A broken admin destroys that argument in seconds. So I believe jumping on this was the right thing to do.

I might have answer to my own question. Posting for others who are new to PW. In Module->Configue->LanguageSupportPageNames, at the bottom there is a collapse select which I didn't initially see: Default language homepage URL is same as root URL? Choose Yes if you want the homepage of your default language to be served by the root URL / (recommended). Choose No if you want your root URL to perform a redirect to /name/ (where /name/ is the default language name of your homepage). Selecting No solved the issue as far as I can see

I need to set up a system that has two equal languages, neither being dominant. Therefore, English defaulting to the base url won't work (even though in Page -> Settings I have 'en' specified). My initial idea was to force the display as 'en' for English but this doesn't work (the url is overriden to display as base url). Alternatively, is there a way to change the default language without potentially breaking stuff? I have installed the language files for the other language.

Thank you Philip. I'm new to PW but longer term users may not see that it is not an intuitive system in some areas. To see nice clear language tabs in the content and a nice clear Language area with name and title, to then have no idea how that relates to front end pages was a little frustrating. Above post sent me to Page -> Home -> Settings and all was clear. Not sure how long I would have been searching for that without this post. Better would be the more standard global URL approach here, for exmaple in Language settings, have a setting for name, title and url suffix which is for all pages, with page settings overriding this if entered? At least that would have been the intuitive route for me

Good to know others saw what I did, and thanks for doing that test. It is more reassuring. For me the original issue is something that does not shine a confident light on PW's development (even when now fixed), either that such a common action (adding a language) would cause an SQL error in a stable version or the admin breaking because of it. It brings up the question 'what next?'. Yes that's true. It was my mistake not to update before continuing development. I'll give PW 3 a go.

Thanks adrian. I'll give that a go. I'm also going to restart with a parallel PW system version 3. (and thanks for the follow up post. Yes, agree with you there. I started project ages ago and it was put on hold). Edit: Thanks Robin. I'll check the modules on next test. Overall re. PW, even though an earlier version, this is going to have to be test only. For a real-world client site it's too risky and unfair to give to a paying client that I could not even complete it without breaking it. Perhaps after some time I'll get some confidence back in PW. An error breaking admin panel access completely, by an action through the panel is not good. It's something a client could do. Not the first CMS db error I've encountered but PW is the first where it's made admin panel inaccessible. That's business damaging stuff if a client saw it. I believe the best I can do for PW right now is say this was a really poor CMS moment. A lot of users will give up at that point and leave without saying a word. If this wasn't fixed post 2.7, the best thing I can do for PW is try to help and encourage this to be fixed. It needs fixing. When the panel detects such an error it absolutely needs to still be accessible, with an error displayed within. This is 2017 not 1998. Users and clients expect more. So to start with, is there an obvious starting point where I can modify my panel to override non-display of the panel when it detects an SQL error?