mikeuk
-
Posts
37 -
Joined
-
Last visited
Posts posted by mikeuk
-
-
7 minutes ago, Soma said:
Some basics when working in OO software. If you print_r() a object (ie page or field), PHP will traverse the object (try to) and load all its references recursively. It unfolds the object which isn't really present in the original object and only loaded or accesses it if you would do call stuff on this object. This doesn't mean the object contains all the stuff you see printed at that time before you call print_r().
Edit: Oh a page field contains only a reference (by the id) to the page and loads the page object and not even its content unless you call it (except autojoin fields).
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).
-
13 minutes ago, diogo said:
That doesn't sound right. A page field returns a normal page array, just like a $pages->find() call, and how many pages can you possibly have selected in a page field?
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
13 minutes ago, diogo said:Are you sure this is not caused by something external to PW (e.g. server config, some external library...)?
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
-
5 minutes ago, Wanze said:
What rendering issues do you mean? The problem is that you cannot measure performance in printing out objects. If objects contain a lot of references to other objects, this may take time to print out. In terms of page types, you have references to other pages and there may be a recursion problem, e.g. print a parent page with references to its children pages, each child page has again a reference to the parent) etc.
The Page field is one main features in ProcessWire, at least for me. It makes the whole system powerful in terms of data modeling. If you want to measure performance, you should do it right, for example with a PHP profiler. Btw I'm also fan of clean code and good performance, that's why I'm working with ProcessWire
Cheers
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.
-
2 hours ago, kongondo said:
Er, what previous topic? ...cross-referencing would help a bit here.
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?
-
1 hour ago, adrian said:
If the page field is returning an array (multiple vs single), then you either need to do: $page->blocks->first()->render() or you need to iterate through the selected blocks, eg:
foreach($page->blocks as $block) { echo $block->render(); }
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?
-
6 minutes ago, adrian said:
$page->blocks->render()
will output the content of the selected blocks page based on its template. Does that do what you need?
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/
- 1
-
4 minutes ago, adrian said:
You need to specify what fields you want to output from blocks, so for example, $page->blocks->title
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.
-
3 hours ago, Sérgio said:
And if the course options (like Adult Courses) are going to be just options, not entire page (with fields), you can use the Options fieldtype as well.
In this case, maybe pages also, but good to know for the future.
3 hours ago, LostKobrakai said:The primer on the topic:
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.
- 1
-
1 hour ago, Ivan Gretsky said:
Look for Page field!
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)
-
16 hours ago, renobird said:
......... I don't expect my ideas to carry any more weight than anyone else in the community that wants to contribute.............
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).
- 1
-
On 25/02/2017 at 5:40 AM, cstevensjr said:
Numerous members are extremely helpful and go out of their way to help people with their particular problems.
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.
On 25/02/2017 at 5:40 AM, cstevensjr said:I believe with time, you will look back and be very pleased that you hung in there with u
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.
- 2
-
On 13/03/2015 at 9:29 AM, horst said:
A bit OT, but if you can plan the languages hirarchy right from the start of a new site, you can do it this way:
-
enable languages support
-
set Title / Label of the default language to your desired none english native language, (e.g. 'Deutsch' (German))
-
drop in the none english language pack (for admin backend) into the default language, (e.g. german langpack)
- add a new language to it and drop in a language pack for any none english language or simply don't drop in a language pack to get the english version (but not as the default one!)
As a nice sideeffect every new user in your system gets the native language per default without have it to select from the list.
So, yes, this is no solution if you once have set it up and need to switch the default language afterwards, but just want to note it.
Thanks horst. Couldn't work out how to do this, and was early enough in the process to re-start.
- 1
-
enable languages support
-
17 hours ago, adrian said:
Surely you can understand that 2.7 was working at the time when most of us were on older versions of MySQL? Out of curiosity, I googled Drupal and Wordpress along with the "column not found" error and found many results. Not trying to make excuses - just saying that this is sometimes the reality of software development - things break due to changes in dependencies - there are a lot of combinations/permutations to keep up with!
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.
17 hours ago, SiNNuT said:think you're a little quick in doubting the quality of PW's development.
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.
- 1
-
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
- 3
-
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.
-
On 09/02/2014 at 3:30 PM, Philipp said:
Quick 'n' dirty guide if you want a single page tree with the same content in different languages. The URLs will then look like example.com/en/my-article or example.com/de/mein-artikel
1:) Download and install ProcessWire
2:) Install the modules you find under the "Language" Tab.
3:) Go To Setup->Languages and add new languages. Please note, that the default one is also the default language of your site*
4:) For every field type text or textArea change the Type to TextAreaLanguage or TextLanguage. (e.G. body with TextArea becomes body with textAreaLanguage). You fields should now have multiple tabs for each language, if you edit a page.
5:) Go to the root page (/) and look under "Settings" Setup an URL for every language, e.g. en,de,ru,... . Looks like this: http://take.ms/34Tq5
6:) Create pages and fill in the content. You can build a front end language switch as described in Ryans API Language page.
ProcessWire will take care of changing URLS (e.g. /en/example to /de/beispiel) and you can access the current language via $user->language;
*It's possible later to define another language as the default 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- 1
-
7 hours ago, adrian said:
I made exactly the same argument as you some time ago I just forced the same error in PW 3 (by deleting a language field in the pages table) and it now looks like this, with everything still accessible.
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?'.
7 hours ago, adrian said:I would definitely urge you to try PW 3 - there has been well over a year of development that's gone into this new major version. I think it is only fair that you judge PW based on this version - I hope you agree!
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?
Displaying content of page in Page field type
in General Support
Posted
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)