adrian

Small update to the ProcessWire Info panel which adds a new redirecting "Login" button. Obviously this is only relevant if you have checked the "Force Guest Users into Development Mode on Localhost" option in the config settings. I always do this because I like the Tracy debug bar enabled whether I am logged in or not when developing. The nice thing about this login button is that it redirects to the page you were on when you clicked it, so you can be viewing a page on the frontend of your site, click this button, enter your credentials and you will be automatically redirected back to the page you were viewing. Showing the login button: And if you are already logged in, then you'll get a logout button instead (which also returns you to the current page after logout):

Not sure if this helps, but this PW video fieldtype (https://github.com/adrianbj/FieldtypeVideo) makes use of http://www.mediaelementjs.com/ to play videos in HTML5 with a flash fallback if there is no browser support.

Thanks - I took a look and your /wire/config.php file is missing these lines: https://github.com/processwire/processwire/blob/57b297fd1d828961b20ef29782012f75957d6886/wire/config.php#L869-L906 I just realized the issue - you mentioned that you are running PW 3.0.36. The latest stable version is 3.0.62 and the latest dev is 3.0.74. If you update to either one of those, all your errors should go away. I am curious how you ended up with 3.0.36 - where did you download that from? OT - did you intentionally restyle (colors) the Tracy console panel, or is that CSS leaking through from your site somehow?

It sounds like there is something missing from your /wire/config.php or your /site/config.php is overwriting the $config->dbSqlModes setting in /wire/config.php That might explain why the ONLY_FULL_GROUP_BY is not being disabled. Could you please post both of those config.php files - PM them to me if you prefer. PS - this is what I see:

Thanks - actually it would be great if you could enter this in the Tracy console panel and tell me what it returns: d($config->dbSqlModes); $minVersion = '5.7.0'; $serverVersion = $database->getAttribute(\PDO::ATTR_SERVER_VERSION); if(version_compare($serverVersion, $minVersion, '<')) d('false');

PW does tend to make use of a lot of efficient sql queries, so even though 203 queries are a lot, they are normal and fine in PW. Something I had forgotten about - PW actually disables the MySQL only_full_group_by setting. Whether this is the correct approach or not is debatable, but that is how it is currently supposed to work, but it seems like it only works for MySQL 5.7.0 or greater, so I am guessing you have an earlier version that still has the only_full_group_by setting enabled. What you can do though is add the following to your /site/config.php file: $config->dbSqlModes = array( "5.6.0" => "remove:STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY" ); Note that I have used 5.6.0 as an example - you will need to find the version of MySQL that you are running and use that instead. This should take care of all those errors. Please let us know how it goes.

Hey @bernhard - I took another look at the $wire variable not being available in ready.php (and init.php / finished.php) and this has been fixed in the latest version. Please confirm it all works at your end please.

Hi @bernhard - that $wire issue is interesting. I will take a look soon. As far as the memory limit issue with Captain Hook - I reduced my memory down to 64MB and it still worked. I had to go to 32MB to get the error so I am wondering what file caused the error on your system. Could you please debug the path of $file in this function: https://github.com/adrianbj/TracyDebugger/blob/8b92a7d6aec5d9999a77f591496fe8b3ed32080b/panels/CaptainHook/CaptainHookSearch.php#L44 Hopefully that last one to be output should be the file that is causing the limit to be reached. That will at least give me an idea of what is going on. I could of course just set a higher memory limit for this panel, but would like to see what is causing it to fail first. Thanks!

The modules manager module hasn't been tagged as PW 3 compatible. I honestly don't really think it is necessary these days - we have such an easy way of installing modules directly in PW by their class name.

What type of field is "group" ? There doesn't appear to be anything wrong with your original selector, but I am wondering if maybe it's a Page Reference or Options field type. It would be great to see exactly what the SQL query is (the one coming from that selector). Do you have TracyDebugger installed? If so, take a look at the PDO queries section of the debug mode panel and see if you can find the query for us please.

That fatal error is an interesting one and suggests a possible bug in ProcessWire. You should not have to (and probably shouldn't) disable that mysql setting. I would like to know what selector in your template (that calls the PageFinder) is resulting in that error. Is it possible for you to narrow that error down to a specific $pages->find selector?

I am not sure why you disabled the file compiler. If you leave that turned on you shouldn't even need to add the namespace to the top of the module files. Was there a reason you chose to disable it?

@hellomoto Can you please check your phpinfo (via Tracy if you have it) and let me know if tokenizer is enabled.

Yes you can, but generally there is no need to have more than one unless they are on the same template. You can use template context overrides - click on a field name in the template view (showing all fields) and set the label and other details there and these will only be for that template.

The label is what the user sees when they are editing the page in the admin, so it's very useful. You can rename the field from "images" to "myphoto", but you need to change the name of the field, not the label.

Your field name is "images" - it's the label that you've set to "myphoto". Just replace the call to "myphoto" with "images" and you should be fine!

Yeah, those should all work just fine. If they're not, then something must be odd with your settings somewhere. Is this online somewhere I could take a look?

Very late response to this, but I would like to follow up on this. I specifically testing BCE with importing CSV to the MapMarker module and it worked fine (if you set up the CSV field pairings correctly. It should also work with the Leaflet map as well. If you have time, it would be great to hear how you set these up in case there is actually a problem still.

I have had random failures on an old shared host that I no longer use. I never got around to debugging, but I wondering if it's a curl issue. I'd be curious if you have better luck disabling curl here: https://github.com/processwire/processwire/blob/57b297fd1d828961b20ef29782012f75957d6886/wire/core/WireHttp.php#L639 Just remove 'curl' from the $allowMethods array. It should resort to fopen and socket consecutively if curl fails completely, but maybe there is some curl setting on that host that is randomly problematic with Github. Not sure, but maybe worth a try.

@tpr's awesome Admin On Steroids (http://modules.processwire.com/modules/admin-on-steroids/)

There is slight mistake in what @PWaddict wrote - you still need to access that "first" image in the array I would also advise using more meaningful variable names, eg use $repeater_item rather than $image in the loop, because it's not actually the image that you are getting, but rather the repeater item that has title, body, and image field in it. foreach($page->your_repeater_field as $repeater_item) { echo "<img src='$repeater_item->your_image_field->first->url'>"; } The other option is this if you want to output all images from your image field. foreach($page->your_repeater_field as $repeater_item) { foreach($repeater_item->your_image_field as $image) { echo "<img src='$image->url'>"; } }

Repeaters are another one of those fields that returns an array so you need to foreach through each of the repeater items, then grab the images from that repeater item. On mobile so no code example but hope that makes sense.

Unless set to "1", image fields return an array (as do File fields, and many others). You have to either foreach through all images, all call a specific one. You can do: first(), last(), or eq(n). Read more about it here: https://processwire.com/api/fieldtypes/images/

For a little more info on what I found which will hopefully help others: There were lots of JS errors in the browser developer tools Console tab like this: Uncaught SyntaxError: Unexpected token < which is a good indication that there is an error message, or at least some HTML being returned in the AJAX request which is not expected by the JS script. So then I went to the Network tab of the developer tools and found the script that is uploading images (?id=1&InputfieldFileAjax=1), and checked the response - that is where I found this login form: Also. of course, when I saved the page, it asked me to login again, so that was also a hint. @Roberts R mentioned that he didn't get the console errors - turns out he didn't have "Disable Cache" checked on the Network tab and apparently that made a difference. I always have it checked because Chrome caching drives me crazy but this might be a helpful hint for others.

Yeah, hooks are very cool and not as scary as they may first appear. Be sure to check out the Captain Hook panel in Tracy - it gives you a list of available hooks for each file/class/module in ProcessWire. It can take a little time to figure out what you should be looking for, but once you do, the skies the limit!