PW 3.0.184 – New master/main version!

[ryan]

This week we have a new master/main version released after a full year in the making. With nearly 40 pull requests, hundreds of new additions and more than 100 issue reports resolved, this new version has a ton of great new stuff and we’ll cover most of the new stuff here— https://processwire.com/blog/posts/pw-3.0.184-master/

[Ivan Gretsky]

Congratulations to all of us it the community! And the biggest possible thanks to Ryan for making this step to actively communicate with everyone interested on PRs, issues and wishes! Many of the latter came true ???

[apeisa]

Congratulations Ryan and everyone involved!

It's always amazing to see these blog posts that gather all changes from longer timeline.

[wbmnfktr]

Updated a side project (https://www.restaurants-neumuenster.de/) today to the newest master and all related modules without any issues.

Such a perfect setup overall! Feels not only faster but even Google says it is. Never saw those ratings on that site

[dotnetic]

Really nice work by Ryan and all the involved people.

I am very happy to see more adaption of PR's from the community and more effort of the community to work on ProcessWire, because @ryandecided to make PW more community-driven.

So I have a goodie for all german speaking ProcessWire users: Guess what will be released later today (if nothing happens), or at least tomorrow?
YEAH, right, the german language pack!

[AndZyk]

Thank you for the new master version. ?

But after the upgrade from 3.0.165 to 3.0.184 I get an JavaScript error on the field editing page, which results in a blank page:

Has anybody else this issue?

I think I have to wait for the upgrade a little bit.

Regards, Andreas

Edit: Ok, this issue seems to only occur on my local MAMP PRO server so far. I try to investigate further. ?

Edit 2: By the way, I use to add tags to my fields and templates for better organization. The tags I add have usually capitalization like "Foo" or "Bar". It seems to be an issue with the newly introduced InputfieldTextTags.

[ryan]

@AndZyk I haven't been able to duplicate that issue, but to me it sounds like maybe browser cache. I am also using MAMP locally (though not MAMP PRO). You might try incognito mode to see if that makes any difference. If that's not it, then it might be worth checking if any other modules are installed that might be conflicting with InputfieldTextTags, as the error does seem to be originating there. Please let me know if you find anything more.

Regarding mixed capitalization in tags, there's an open issue report on GitHub for this. I spent half a day trying to fix it a month or so ago, but couldn't figure it out and gave up on it temporarily to try again later when back to the dev branch. Until we have a solution for that it's likely preferable to avoid mixed case tags for fields or templates.

[wbmnfktr]

Just created some new instances with the latest ProcessWire version and something felt a bit off.

I got various notifications (as debug is turned on) but to be honest... I didn't expect to see those updater messages in a fresh and clean installation (blank profile, no backups involved).

Nothing that critical but somehow this feels wrong at least for me.

 

Update:
In addition to this... if those messages were "green"-colored like success messages it would have been something completely different and positive.

[shadowkyogre]

Hi Ryan!

I upgraded to 3.0.184 and saw that it kept trying to add the title field to the templates for extra image fields. I'm not sure why it's doing this. Will need to reproduce it on my minimal ProcessWire install to figure out how to reproduce it reliably. It does happen. Just not sure how and why.

That being said, I do love the new page hooks! They make it easier to output my main site pages in JSON if I just want to show them in JSON. Excited about possibly formatting page outputs in markdown or yaml later for the fun of it.

[Ivan Gretsky]

57 minutes ago, shadowkyogre said:

Hi Ryan!

I upgraded to 3.0.184 and saw that it kept trying to add the title field to the templates for extra image fields. I'm not sure why it's doing this. Will need to reproduce it on my minimal ProcessWire install to figure out how to reproduce it reliably. It does happen. Just not sure how and why.

One of my clients reports the same thing.

[MarkE]

Just trying to update a multi-instance site to 3.0.184 from 3.0.165 but the cross-linking between the two sites no longer works.

The two sites are /site/ - essentially the admin site for property bookings - and /site-web/ for the public website and which publishes availability from /site/.

In /site-web/templates/_init.php I have:

setting('admin_site', new ProcessWire($config->paths->root . 'site/'));

and in /site-web/templates/prices.php I have:

$adminPage = setting('admin_site')->pages->get("template=Availability, bodyFoot*=$host"); // bodyFoot holds permitted hosts list for PW sites
bd($adminPage, 'admin page in Prices');

In 3.0.165 $adminPage is the correct Availability page. In 3.0.184 it is a null page. I have tried clearing FileCompiler from cache in both sites, but still get the same result.

I also did a dump of setting('admin_site') in both versions and it looks identical.

Is there anything in 3.0.184 that might have changed to cause this? Any other ideas?

Thanks.

EDIT: Another really weird thing. If I try and edit site-web/templates/_init.php to add debugging then it keeps reverting when reloading - like PW is editing my php file! This only happens with 3.0.184, not 3.0.165. Think I'm losing my mind!

[ryan]

@wbmnfktr I don't see anything wrong there, that all looks like exactly what it's supposed to do. It may be a bit verbose but I think that's best when debug mode is enabled, especially on new installations. Rest assured, all looks well with your installation. It's kind of like how when you buy a new computer or phone, it installs whatever updates are needed to ensure that everything is up-to-date. 

@shadowkyogre This is not new to 3.0.184, but check to see if your title field is globally required on all templates. If so, you may want to disable that setting. It is in the field editor on the "Advanced" tab, when editing your title field. Or if you just want to disable the setting for the template that you are using, enable $config->advanced=true; in your /site/config.php file, edit the template in Setup > Templates, click the "System" tab and check the box to "Disregard global fields", for that template. Then remove the advanced setting from your config.php file, unless you want it for something else.

@MarkE I'm not aware of a difference that would affect that, but wanted to suggest booting your other site on-demand rather than on every page render. So I would replace your setting() call with the following:

if(!function_exists('adminSite')) {
  function adminSite() {
    static $instance = null;
    if($instance === null) $instance = new ProcessWire($config->paths->root . 'site/');
    return $instance;
  }
}

Then anywhere you need your instance, do your calls like adminSite()->pages->get('...'); 

Next, make sure that your instances are both running the exact same ProcessWire version. 

The other thing that's a little unconventional here is that the site you are booting is using the /site/ dir, which is ProcessWire's default. Usually if booting another instance, it would be in a different location or be using a /site-something/ dir rather than the default. I'm not sure if that's a potential issue or not, but wanted to mention it just in case. You might want to rename your /site/ to /site-admin/  so that there is no /site/ directory which would typically be the primary instance. 

Quote

EDIT: Another really weird thing. If I try and edit site-web/templates/_init.php to add debugging then it keeps reverting when reloading - like PW is editing my php file! This only happens with 3.0.184, not 3.0.165. Think I'm losing my mind!

I can assure you that PW isn't editing your file. But I agree that is really weird. Whatever is doing that might be the source of the issue. This sounds like the sort of issue I run into when I edit a file on the wrong node of a load balancer, and a moment later it gets replaced by the primary node. Make sure that you are using <?php namespace ProcessWire; at the top of your templates and any other PHP files, just to rule out anything file compiler related. Also check what /site/modules/ you have installed just in case. 

[MarkE]

3 hours ago, ryan said:

So I would replace your setting() call with the following

I used setting() because I needed to access the object in site-admin* as well as site-web. So I used your code and added:

if (!setting('admin_site')) setting('admin_site', adminSite());

3 hours ago, ryan said:

Next, make sure that your instances are both running the exact same ProcessWire version. 

Both sites are in the same installation so use the exact same version

3 hours ago, ryan said:

You might want to rename your /site/ to /site-admin/  so that there is no /site/ directory which would typically be the primary instance. 

Done that. Everything works except for the cross-site referencing as reported - I'm still getting a null page returned. (The code reversion problem seems to have been temporary).

 

*Note: I need to access the object in site-admin because the availability page is running in site-web - called by

$availabilityTable = $adminPage->runtime_markup_availability;

(where $adminPage is the one that is currently being returned as null) but the runtime_markup code is in site-admin and needs to use the site-admin instance of wire(), not the site-web one. (Why is the runtime_markup code in site-admin? Because there can be multiple public websites which may or may not be PW sites and I want them all to use the same code to render the availability table which is defined in the admin site).

Sorry if it's a bit complicated, but it was all working so well in 3.0.165!

EDIT:

The above is probably all irrelevant! The problem seems to be to do with the selector bodyFoot*=$host which is finding the correct page in 3.0.165 but not in 3.0.184. Using just "template=Availability" works fine and the found pages have field bodyFoot with the text $host.

So I changed *= to %= and now it works! I guess at sometime the selector method got changed very slightly, so I will check for other instances of that.

Anyway I'll keep the changes you suggested @ryan as they are an improvement anyway ? 

[AndZyk]

On 9/3/2021 at 6:26 PM, ryan said:

@AndZyk I haven't been able to duplicate that issue, but to me it sounds like maybe browser cache. I am also using MAMP locally (though not MAMP PRO). You might try incognito mode to see if that makes any difference. If that's not it, then it might be worth checking if any other modules are installed that might be conflicting with InputfieldTextTags, as the error does seem to be originating there. Please let me know if you find anything more.

Thank you @ryan for your response. I made some tests and think that I can provide some additional informations to my issue:

• It is not the browser cache. Incognito mode or reseting didn't help.
• It is not another module. It was still there after disabling all third party modules.
• It happens after the upgrade from 3.0.165 to 3.0.184. It worked after upgrading from 3.0.182 to 3.0.184.
• It probably has something to with the language pack. I got no issue with the default language. The latest language pack (German in my case) still has this issue.

So it seems, that something in the InputfieldTextTags module causes a conflict with the translation of language packs.

I hope this helps, but as it seems that no one else had this issue so far and it happens only on my local MAMP server, this seems to be an isolated issue. ?

 

On 9/3/2021 at 6:26 PM, ryan said:

Regarding mixed capitalization in tags, there's an open issue report on GitHub for this. I spent half a day trying to fix it a month or so ago, but couldn't figure it out and gave up on it temporarily to try again later when back to the dev branch. Until we have a solution for that it's likely preferable to avoid mixed case tags for fields or templates.

Yes, I have posted this issue on GitHub. It would be great, if this could be solved in the future, but until then I just avoid using the new InputfieldTextTags with Selectize.js. ?

 

And thanks again for the new master release. Reading through all the changes again makes you realize how much has changed since the last master release.

Regards, Andreas

[kongondo]

On 9/1/2021 at 9:28 AM, AndZyk said:

Has anybody else this issue?

 

On 9/3/2021 at 5:26 PM, ryan said:

@AndZyk I haven't been able to duplicate that issue, but to me it sounds like maybe browser cache. I am also using MAMP locally (though not MAMP PRO). You might try incognito mode to see if that makes any difference. If that's not it, then it might be worth checking if any other modules are installed that might be conflicting with InputfieldTextTags, as the error does seem to be originating there. Please let me know if you find anything more.

@AndZyk, @ryan

I can confirm this (?). I have been having a similar issue since I upgraded to 3.0.184 when it was still in dev. Back then, I just assumed the issue was the code in my module. I have since confirmed that by downgrading to 3.0.181, the issue goes away. I'll dig further to find out when it was introduced and what is causing it. In my situation, I am trying to reload/init a fieldset that has been added to an inputfield via ajax. The fieldset contains a multi page field that used Text Tags as the inputfield type. Here's the screenshot of the error:

The 'u' token comes from an 'undefined' string in what was supposed to be the JSON response. The use ajax options is not enabled under Text Tags for the page field. I am on WAMP.

Thanks.

Edited September 6, 2021 by kongondo

[kongondo]

1 hour ago, kongondo said:

I'll dig further to find out when it was introduced and what is causing it.

Just confirming that for me, the issue is not present in 3.0.183. Will now try to narrow it down to changed files in 3.0184.

 

[kongondo]

I have managed to find the code that is causing the issue.

In InputfieldTextTags.js, at the end of the file, the css class '.InputfieldPage' was added, changing the code from this (GitHub 3.0.183 )

// InputfieldTextTags.js ProcessWire 3.0.183
jQuery(document).ready(function($) {
	InputfieldTextTags();
	$(document).on('reloaded', '.InputfieldTextTags', function() { InputfieldTextTags($(this)); }); 
}); 

 

to this (GitHub 3.0.184 )

// InputfieldTextTags.js ProcessWire 3.0.184
jQuery(document).ready(function($) {
	InputfieldTextTags();
	$(document).on('reloaded', '.InputfieldTextTags, .InputfieldPage', function() { // <= '.InputfieldPage' addition causing error(?)
		InputfieldTextTags($(this));
	});
});

I have no solution at the moment ?.

Edited September 6, 2021 by kongondo

[kongondo]

On 9/6/2021 at 1:48 PM, kongondo said:

I have managed to find the code that is causing the issue.

I have got this sorted, but I don't think it will help you @AndZyk.

In my case, after adding fields to an inputfield (similar to a repeater), I was manually reloading a pagefield inputfield that uses InputfieldTextTags like this:

$myInputfieldTextTagsSelectItem.trigger("reloaded")

That was throwing up the JavaScript error I posted above. My remedy was to let ProcessWire Inputfields trigger the reload, like this:

// @note: reload() is a method in Inputfields.js
Inputfields.reload($myInputfieldTextTagsSelectItem)

Error gone! ?

[ryan]

@MarkE

Quote

I used setting() because I needed to access the object in site-admin* as well as site-web. So I used your code and added:

if (!setting('admin_site')) setting('admin_site', adminSite());

That I think may be defeating the purpose of making it load on-demand. What I intended to suggest is to add that adminSite() function, and then replace any of your calls with setting('admin_site') with adminSite(). For example, rather than calling setting('admin_site')->pages->get('...'); you'd call adminSite()->pages->get('...'); and it should do the same thing. The main difference is that your admin site doesn't get booted until the first time the adminSite() function is called. That's desirable because it prevents you from booting it when you aren't going to access it, saving overhead. A function can only be defined once, so it doesn't matter where you call adminSite(); from whether site-admin or site-web. 

Quote

The problem seems to be to do with the selector bodyFoot*=$host which is finding the correct page in 3.0.165 but not in 3.0.184. Using just "template=Availability" works fine and the found pages have field bodyFoot with the text $host.
So I changed *= to %= and now it works! I guess at sometime the selector method got changed very slightly, so I will check for other instances of that.

Great! Glad that it seems to be working now. As for why the *= wasn't working, I think we'd need to look at what is in $host in order to tell. It would also be good to know the full context of that bodyFoot*=$host, for instance is that selector being sent to a $pages API call, or to something else? The biggest difference between *= and %= is that *= matches from the beginning of a word boundary whereas %= matches anywhere in the string. So if you've got an instance where %= is matching and *= isn't, then most likely it's because of that difference. If its querying the database, then *= is also subject to stopwords and minimum indexable word length (typically 4) whereas %= is not. 

@AndZyk

Quote

It probably has something to with the language pack. I got no issue with the default language. The latest language pack (German in my case) still has this issue.

Interesting, I'll have to try that out. Are you using the latest German language pack released by @dotnetic or a different/earlier one?

Quote

Yes, I have posted this issue on GitHub. It would be great, if this could be solved in the future, but until then I just avoid using the new InputfieldTextTags with Selectize.js.

I think the capitalization issue might not be specifically with InputfieldTextTags but with its usage in ProcessField/ProcessTemplate. I don't think there's a reason to avoid using it elsewhere.

@kongondo

Quote

In InputfieldTextTags.js, at the end of the file, the css class '.InputfieldPage' was added, changing the code from this (GitHub 3.0.183 )

The InputfieldPage had to be added because often InputfieldTextTags is used in combination with InputfieldPage. The jQuery selector ".InputfieldTextTags, .InputfieldPage" seems to be valid. Does the error trigger on that line in particular, or does it occur sometime later? Do you find there is any difference if you set $config->debug = 'dev'; ? That will make it use a newer jQueryCore version.

That was throwing up the JavaScript error I posted above. My remedy was to let ProcessWire Inputfields trigger the reload, like this:

Quote

Inputfields.reload($myInputfieldTextTagsSelectItem)

Glad that seems to have fixed it. If this works, and triggering 'reload' manually didn't work, it means that $myInputfieldTextTagsSelectItem is not an .Inputfield element. The 'reload' event is is specific to .Inputfield elements, so the Inputfields.reload() method will attempt to locate the and trigger the .Inputfield element if given something other than an .Inputfield. I think that must be why it is working when the manually triggered one wasn't?

[kongondo]

50 minutes ago, ryan said:

Does the error trigger on that line in particular, or does it occur sometime later?

Thanks for responding @ryan. No, the error was triggering later,  on line 41, at the JSON.parse(). I just found it strange that removing the class .InputfieldPage made the error go away.

52 minutes ago, ryan said:

Do you find there is any difference if you set $config->debug = 'dev';

No, I didn't try this. Next time.

53 minutes ago, ryan said:

If this works, and triggering 'reload' manually didn't work, it means that $myInputfieldTextTagsSelectItem is not an .Inputfield element.

That's what I was thinking at first. However, if I added multiple fields, it would reload the first one OK then trip on the next one.

55 minutes ago, ryan said:

Glad that seems to have fixed it.

Yeah, me too! ?.

[MarkE]

5 hours ago, ryan said:

That I think may be defeating the purpose of making it load on-demand.

I did wonder if that might be the case. I need to use the setting in both sites, having just set it in site-web, and I thought setting() achieves that whereas adminSite() is not available to the other site. However, it seems I am wrong and that the adminSite() function is available in site-admin when that instance is called from site-web. So I removed the extra line and everything seems to work, thanks!

5 hours ago, ryan said:

I think we'd need to look at what is in $host in order to tell. It would also be good to know the full context of that bodyFoot*=$host, for instance is that selector being sent to a $pages API call, or to something else? The biggest difference between *= and %= is that *= matches from the beginning of a word boundary whereas %= matches anywhere in the string. So if you've got an instance where %= is matching and *= isn't, then most likely it's because of that difference.

bodyFoot was "<p>myText, some more text, ... </p>" and $host was "myText" so your explanantion is spot on and in line with the docs. However, *= worked in 3.0.165 with exactly the same values so it looks like something changed... No worries, it all works now, but I wonder if there might be a problem lurking for others if indeed there was a change.

[ryan]

@MarkE Was this bodyFoot thing querying the database, or doing something memory? When querying the database with something that uses an index, it can be affected by what characters MySQL indexes as part of a word. Though I think MySQL would much more commonly index "myText" and not "<p>myText". It may come down to more specifically what the exact text that you are using in that bodyFoot query, like perhaps it's matching a stopword? 

Or if this is a selector that isn't querying the database, it could be tested like this:

$value = WireData([ 'text' => '<p>myText, some more text, ... </p>' ]);
$tests = [ 'text*=myText', 'text%=myText' ];

foreach($tests as $test) {
  $s = new Selectors($test); 
  echo "<li>$test: " . ($s->matches($value) ? 'Yes' : 'No');
}

I get "Yes" for both fo the tests, indicating it matches. Though I recognize this is probably not the real text you are matching. 

[MarkE]

1 hour ago, ryan said:

Was this bodyFoot thing querying the database, or doing something memory?

bodyFoot is just a (CKE) textarea field in a page with template=Availability. It holds a comma-separated list of hosts which are permitted to access the Availability page in site-admin. $host is the name of the site-web host. So all the select is doing is checking that $host is in the list of hosts. I realise that it might have been better to explode the list and then check array membership but, ignoring that for now, I am puzzled by your example - I get "Yes" for both too.

Examining the (real) situation a bit more, I added some Tracy debugging to the code as follows:

$host = $config->httpHost;
bd($host, 'host');
bd(adminSite()->pages->get("template=Availability")->bodyFoot, 'bodyFoot');
$adminPage = adminSite()->pages->get("template=Availability, bodyFoot%=$host"); // bodyFoot holds permitted hosts list for PW sites
bd($adminPage, 'admin page in Prices');
$availabilityTable = $adminPage->runtime_markup_availability;

This is the output with the real data (in 3.0.184):

Replacing the %= by *= in the code results in the following:

In version 3.0.165, the *= yielded the same result as %=

[AndZyk]

On 9/7/2021 at 5:38 PM, ryan said:

Interesting, I'll have to try that out. Are you using the latest German language pack released by @dotnetic or a different/earlier one?

I have tested it with the latest German language pack for ProcessWire 3.0.184. Thank you for investigating, I will also look if I can provide more informations. ?

Regards, Andreas

Edit: This issue didn't occur after upgrading a few more websites, so maybe this was a caching issue after all.

Edited September 20, 2021 by AndZyk
Issue resolved

[xportde]

On 9/1/2021 at 10:28 AM, AndZyk said:

Thank you for the new master version. ?

But after the upgrade from 3.0.165 to 3.0.184 I get an JavaScript error on the field editing page, which results in a blank page:

Has anybody else this issue?

I think I have to wait for the upgrade a little bit.

Regards, Andreas

Edit: Ok, this issue seems to only occur on my local MAMP PRO server so far. I try to investigate further. ?

Edit 2: By the way, I use to add tags to my fields and templates for better organization. The tags I add have usually capitalization like "Foo" or "Bar". It seems to be an issue with the newly introduced InputfieldTextTags.

We have the identical situation, same error an all edit pages since 3.0.184 because of the following error:

Strangely enough, we don't use the new field InputfieldTextTags at all yet! As hotfix, we have surrounded the JSON.parse() call with try ... catch statement:

try {
   var o = JSON.parse($select.attr('data-opts'));
}
catch (e) {
   return
}

But this cannot remain a permanent solution. Are there any other findings on this problem yet?

Best Regards,

Thomas.