adrian

Thanks @Robin S - I am bad at remembering that New version should fix everything and should also take care of that extra "\/" that you saw at the start. Can you please confirm that your CaptainHook panel output now looks like this - note the "Site Modules" (along with "Wire Core" and "Wire Modules" section headers) and the way the files now start with just their main folder, eg: AdminCustomFiles/AdminCustomFiles.module compared with the old: /site/modules/AdminCustomFiles/AdminCustomFiles.module I think this new way makes it much easier to scroll down to find what you are looking for. Regarding FormBuilder - yes, I use the forms API. I'll see what I can do about figuring out what the issue might be with the template detection shortly. I have a hunch that it's related to the way I am getting the template of the page - because I am in ini() and not ready() when I need to do this, it's a bit of a hack

Hi @Robin S - sorry it's not working for the form-builder template. I don't use ForBuilder so a little hard to debug, but I'll take a look and see what I can figure out. Regarding the Captain Hook error - no, not related - I added some code recently to split the files into sections - that is what is causing the error for you, but still not sure why you are getting that. Any chance you could debug what the contents of $segments is when the undefined offset is reported? Thanks, Adrian

@Robin S - I just committed a new version with the template restriction options. Let me know if you have any problems. Cheers, Adrian

Hi @Robin S - You're right, there is no option to not show it in an iframe. I am definitely happy to add an option for selected templates though. I'll see what I can do about getting this done for you tomorrow.

Are you sure you don't want && rather than ||

Hey @tpr - FYI with the new Pages > Tree functionality that Ryan just committed. AOS is resulting in this:

Migrator has a country list complete with ISO country code fields etc. If you want to go this route, install this commit of Migrator: https://github.com/adrianbj/ProcessMigrator/tree/3e2121b8fdb68e9d9dc0c6aca8aae75e923a2669 Alternatively, use https://processwire.com/talk/topic/4523-page-field-select-creator/ and paste in a list of countries, or even http://modules.processwire.com/modules/batch-child-editor/ A CSV list like this (https://developers.google.com/public-data/docs/canonical/countries_csv) would be helpful for the last two options.

I get the feeling that the Gilbert Burnett you are seeing is actually the $headline. I bet that $bodycopy is not being output/echo'd within main.inc at all.

You do need to save. Not sure how your tests are set up, but if you set the email and then get it straight after, it will appear changed, but if you reload the page, it won't have stuck unless you save.

This module now works with the core Page Clone module, so now when you "Copy" a page and edit the title, the name will also change based on the config settings of this module. I think this is really important, because the current behavior of the clone module will likely result in incorrect names/urls for the new page - I don't think you can rely on site editors to manually edit page names to match titles. There is currently one issue where it doesn't work for the names of other languages on a multi-language site. I believe this is a bug in the clone module (https://github.com/processwire/processwire-issues/issues/207), but if Ryan says it isn't a bug, then I'll add a workaround in this module.

@jploch - I'd like to see a dump of $event after line 718 because $field is not an object and it should be. That said, a quick fix might be to change the hook on line 97 to: InputfieldImage::processInputFile

Ok, so based on the error, it's clear it's an issue with the ImageExtra module. Make sure you are using the latest version of that module and if you're still having problems you may need to request support in its forum thread, although it might be as simple as disabling that module on this video field.

@jploch - you need to dig a little deeper - we need to see the Response tab for the file that results in error - there will be an error message in the returned response that is breaking the upload.

It's working fine for me on PW 3 - what's the ajax error that is stopping things? console > network tab

Click "Clone or Download" on the Github page, then right-click on the "Download Zip" link and paste that into the "Add Module from URL" install option.

On the command line, type: locale -a

Glad to hear everything is up and running again! Your images should still be in their relevant site/assets/files/xxxx folders at least, so hopefully it shouldn't be too hard to rebuild.

You will need to access this via PHPMyAdmin (or some other MySQL interface).

This option no longer exists - it was only available in early alpha versions of PW 3. I recently upgraded a site from 2.6 to 3 and had a couple of similar issues, but got them sorted out without needing to add the namespace declaration. You might be able to simply remove the fieldtypeimagextra files and its row from the modules database table. Process of elimination should get you there

Hey @Peter Knight - not sure how you normally install modules, but I would suggest in general going for the class name, upload, or url to zip approaches, which avoid this possibility. Manually downloading and unzipping means you have to watch for this.

This module (http://modules.processwire.com/modules/import-external-images/) works for images embedded into HTML with full http urls, bit should be easy to modify to support a local path instead.

Not sure why that foreach version isn't working for you. Is "blocks" the name of your page reference field? Is Details > Page field value type set to multiple? Do you have a php template file for the template attached to the pages for each block?

A little more info from Ryan on why it is appearing to be huge when dumped: the _wire reference present in every Wire derived object points to the current ProcessWire (class) instance. Because the ProcessWire class extends Wire, that means it also has a _wire property, and that property in turn points back to the ProcessWire instance. That's not inherently a problem, and it's necessary for access to API variables by all Wire-derived objects. This is one of the means by which we support multiple instances of PW. There is no recursion unless some code tries to follow the protected _wire property of the protected _wire variable. In addition to the getArray() that kixe mentioned, also check out getIterator() and be sure to try the TracyDebugger module for dumping objects/arrays.

I have no idea what you have initially defined $TestimonialsRepeater to be. What you want there is a selector to get the page. For example, if the repeater content was on the homepage, then you could do: $p = $pages->get("/'");

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(); }