Search the Community

A conversation from the GITHUB issues which I thought to be useful to have in this Forum's knowledge base. Ryan Cramer put some valuable information there, which should be searchable in this forum, i.m.h.o. My Summary: Use the "autojoin" option on pagefield (when allowing multiple pages) with care. There could be unwanted side effects especially if you use more than one of these fields with that setup on a single template. Original conversation: tbba asked: I have 2 page fields (one is the clone of the other - so they are unique apart from the name). Both are used on a template. The first field DOES remember the (dragged) sort order of the pages, the second does NOT. Has anyone else have the problem too? Is this a cache problem, or corrupt indexes? PW latest dev / php 5.6 fastcgi / Safari+Firefox Update: If I change the display order of those 2 fields in the template, both fields behave the opposite: So the first (whatever the first field is in the template when editing the page) always WORKS the second NOT. (The 2nd field lets me still adding or deleting a page - just the order is corrupt there.) Update: On localhost everything works (same php version but has opcache off in MAMP - maybe this info is important) Update: If I switch "autojoin" off for those page fields, everything works everywhere. This is my workaround for now. (I remember that "autojoin" has been a problem for me with page fields already in much earlier versions of PW on many sites so it is not a temporary phenomena.) ryancramerdesign commented If you need to retain a sort order, you'd only want to autojoin one of the page fields. Autojoin causes everything to be loaded in one query, and there can't be two different sorted result sets included in that query as far as I know. Though it's interesting it works on your localhost and not on the other server. There are some MySQL versions known to have issues with sorting and certain queries, and you may be hitting up against that on one server and not the other. Though I can definitely see how auto joining two Page fields in one query would pose challenges to retaining the sort order. So in either case, I would limit your autojoin to just one Page field, or simply not use Autojoin for page fields at all. There's not a major benefit in doing so. tbba commented MYSQL on the live server is 5.6 and on localhost/MAMP it is still 5.5. I am very glad you can confirm that this issue is not a phantom of a defect system and can be 100% nailed down to "Autojoin". I used Autojoin under the assumption that it indexes a field and makes certain searches (menu building) quicker. (Since the new cache options, I am not worried with speed on certain searches any more.) If Autojoin has, in the best case, no "major" effect with page fields and in the worst case totally confuses the system, why is the option nor switched off and deactivated for this field type? Is Autojoin only bad for page arrays or even if the page field is set to accept only one page? Are there other fields that also have a problem with "Autojoin"? (I must say this "mystery bug" - which sometimes happens and sometimes not - was quite a debugging nightmare and other users should be warned/hindered to set-up such a combination, i.m.h.o.) ryancramerdesign commented I am very glad you can confirm that this issue is not a phantom of a defect system and can be 100% nailed down to "Autojoin". Actually I can't nail it down to autojoin, but outside of using it with a simple text or number field, autojoin is an advanced option that can be affected by a lot of different factors. It's one of those things we suggest using when you find it helps, and don't use when you find it interferes. When you autojoin a multi-value field, MySQL is performing what's called a group_concat, and is at the mercy of certain MySQL memory buffers and configuration settings. It's very possible you are hitting up against that too, which is made all the more likely by auto joining two multi-value fields. That would explain why you see it on one server and not another. I used Autojoin under the assumption that it indexes a field and makes certain searches (menu building) quicker. (Since the new cache options, I am not worried with speed on certain searches any more.) It can make things quicker but it can also slow them down. It really depends on the case. The only way to tell for certain in a given instance is by testing and timing it. I do know for certain that auto-joining one or two text fields (like title and summary, for example) does provide a performance benefit to large navigation lists that use the autojoined fields, though not likely one that you would feel unless loading hundreds of thousands of pages. If Autojoin has, in the best case, no "major" effect with page fields and in the worst case totally confuses the system, why is the option nor switched off and deactivated for this field type? Because it is an advanced option that may be beneficial. If auto joining one multi-value field, like a small list of category page references, you may find it beneficial when outputting a 100 item navigation list. Or you may not. It really does come down to installation specific configuration, so it's one of those things you want to test when you use it to make sure it's working and worthwhile for your case. I wouldn't want to disable the option for this Fieldtype, because I think it can be worthwhile. But it's on the advanced tab for a reason. Is Autojoin only bad for page arrays or even if the page field is set to accept only one page? Are there other fields that also have a problem with "Autojoin"? Autojoin should be fine for Page fields, especially single page fields. What I would avoid is giving several multi-value Page fields autojoin on the same template. You are more likely to run into issues there, but again, the only way to know for certain if it's going to be an issue on your installation is to test it. If you need something guaranteed to be portable across systems, then limit autojoin use to single-value text fields and such. Any multi-value Fieldtype has potential to run into installation-specific limits that could cause issues, so always treat it as an advanced option and test.

Hi, I am working on a processwire project for my college. I created an entire site about a year ago without any problem. Today however, I was making some changes to the site and I was experimenting with duplicating data across multiple pages. There is a repeater on one of the pages that I need to be the same across all pages. I clicked the checkbox to autojoin within the field options for the repeater and processwire crashed. I am not able to make any changes to the page to uncheck and I cannot view the site any longer. This is the message I get on the page. Fatal error: Exception: Could not execute User::__construct() (in /var/www/html/wire/core/Pages.php line 323) #0 /var/www/html/wire/core/Pages.php(323): mysqli_result->fetch_object('User', Array) #1 /var/www/html/wire/core/PagesType.php(101): Pages->getById(Array, Object(Template), 29) #2 /var/www/html/wire/core/Session.php(64): PagesType->get(41) #3 /var/www/html/wire/core/ProcessWire.php(138): Session->__construct() #4 /var/www/html/wire/core/ProcessWire.php(46): ProcessWire->load(Object(Config)) #5 /var/www/html/index.php(185): ProcessWire->__construct(Object(Config)) #6 {main} in /var/www/html/index.php on line 217 I tried to comment out 323 without any luck. I also took a look in the database to see if I could manually turn off the autojoin option. However, I was not able to figure out where the option was located within the database. Any help or suggestions would appreciated. EDIT: I was able to solve the issue on my own. I did a google search and found that I needed to change he flag for the field from 1 to 0 in the database, and everything works again. Here is the post that I found that solved the issue.

Hi there, Today I was testing Autojoin and Global features on fields. I have a repeater field and I activated Global and Autojoin and processwire now shows the following message: Unable to complete this request due to an error. Error has been logged. The error log was this: 2013-10-31 01:36:08 ? http://localhost/?/ Error: Exception: Could not execute User::__construct() (in /Applications/XAMPP/xamppfiles/htdocs/cms/wire/core/Pages.php line 323) How can I solve this problem? I have searched the site database, but I couldn't find this option the autojoin option to toggle it manually. Thanks in advance

I'm developing a module that lets user specify which fields she wants to show in the result list (which is intended for print use, but that's not very relevant here.) My problem is that when multiple fields are selected SQL queries tend to pile up which results in sluggish page load times. Currently matching pages (selector is also generated based on user input, but that's another story) are loaded with $pages->find() and then looped through with foreach and rest of the fields (which, as I mentioned above, are actually chosen by user) are fetched individually. This is where things get really slow, especially if user has specified 10+ fields to show One solution I've used to make things a bit faster is that most commonly used fields have autojoin setting on and thus PW doesn't require another query to fetch their content. Problem with this is that same data is used elsewhere in simple list views, which get way more hits than my little module here does and if I make all the fields autojoin it would seriously cripple those other views and in the long run possibly suffocate whole server.. Long story short, what I'm looking for is a way to turn on autojoin for certain fields on the fly before fetching pages OR mimic similar feature some other way. Any ideas how to achieve something like this are more than welcome - and don't hesitate to tell me that I'm doing it all wrong, if you know a better way to achieve same results..