Leaderboard

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.

I like to keep things light. I'd say look into Foxycart or Snipcart, or Moltin. Either solution still allows you to use ProcessWire while handling off commerce functionality to those other systems. Or you could built it entirely in ProcessWire like I did. Not recommended unless you really want to get your hands dirty. A lot of re-inventing the wheel (although a good learning experience).

One problem is your specified "icons" property doesn't match the name of your toolbar button. From this tutorial, the relevant quote is: Another problem is that in the toolbar config, you need to put the name of the button, not the name of the plugin. From checking an official plugin ("Source Dialog"), I see they went with "Sourcedialog" for the button name (and thus "sourcedialog" for the icons property). So you could change your button name from "Loop Video" to "Loopvideo" and that would fix it (since your icons property would now be the lowercase version of that). Don't forget to also change the button name in the toolbar group config just in case, since I'm not sure if it's case-sensitive. Also, after making these changes, remember that your browser will still probably have the old version cached.

FrontendContentManager (unstable / testing) FrontendContentManager is a module based on FormHelper to generate needed page edit / add form via form api. NO sanitizing of form values at the moment!!! edit pages create / add new pages add, replace and remove images Download ProcessWire module page: http://modules.processwire.com/modules/frontend-content-manager Bitbucket Repo: https://bitbucket.org/pwFoo/frontendcontentmanager Version 0.2.0 Required FormHelper (0.7.1+) Usage Example template file <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title><?php echo $page->title; ?></title> <?php // Load FormHelper module and also set wire('fh') variable $fcm = $modules->get('FrontendContentManager'); // edit existing page //$form = $fcm->edit($pages->get('1108')); // add a new page based on a template and a parent object $parent = $pages->get('name=test'); $form = $fcm->add($parent, $parent->template); // jsConfig needed by ckeditor echo $fcm->JsConfig(); // outpunt needed scripts for inputfield modules, ... foreach ($config->styles as $file) { echo "<link type='text/css' href='$file' rel='stylesheet' />\n"; } foreach ($config->scripts as $file) { echo "<script type='text/javascript' src='$file'></script>\n"; } ?> </head> <body> <h1><?php echo $page->title; ?></h1> <?php // output the forom echo $form; ?> </body> </html> *UPDATED TO 0.1.0* At the moment I have no usage for FCM module, but after FormHelper 0.5.2 is finished I've done a quick FCM rewrite. Only few tests done yet! *UPDATED TO 0.2.0* Updated to work with redesigned FormHelper 0.7

The line $picture->template = $pages->get($template); seems to be the culpit.

I have no clue then... is caching enabled, or are pages published and visible on the site?

wireRelativeTimeStr() has been there since PW 2.3 if I recall correctly. All the words in it are translatable via the translation tool pointed at /wire/core/Functions.php.

It does only work with a specified id radio=1002