adrian

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

I think you might be confusing templates and pages. main.php would be template file that controls the output of pages with the "main" template, but usually main.php is used as based template that is included or modified by other templates. That aside, you need to get the repeater content from the page where it exists, so something like this: $p = $pages->get(selector to get page where repeater content is); foreach($p->repeaterfield as $repeateritem) { //usual repeater output }

$page->blocks->render() will output the content of the selected blocks page based on its template. Does that do what you need?

You need to specify what fields you want to output from blocks, so for example, $page->blocks->title

A little humorous PW vs Drupal comparison https://www.slant.co/versus/14277/4267/~drupal_vs_processwire When comparing Drupal vs ProcessWire, the Slant community recommends Drupal for most people. In the question“What are the best web content management systems?” Drupal is ranked 2nd while ProcessWire is ranked 13th.The most important reason people chose Drupal is: A more complex Drupal installation can easily exhaust 256 MB of RAM with only one or two visitors.

I agree that @Robin S solution is definitely the easiest if that works for you. But, if you do need to dynamically order with a hook, then this should work for you. Don't forget to change 'options_field_name' to the appropriate value. $this->addHookAfter('Field::getInputfield', null, function($event) { if($event->object->name == 'options_field_name') { $inputfield = $event->return; $options = $inputfield->options; foreach($options as $id => $title) { $inputfield->removeOption($id, $title); } asort($options); foreach($options as $id => $title) { $inputfield->addOption($id, $title); } $event->return = $inputfield; } }); I am a little under the weather today and I feel like I am missing an easier way to remove all existing options before sorting and adding them back. I feel like there is probably a better way to do this in general, but it doesn't look like you can use PW's sort() here. Maybe I am just not seeing it right now

I just tested this using the "Text List" and "JSON settings" options and it should now work with Core modules as well, but it's not well tested, so please let me know how it goes.

Just a heads up that I have committed a new version with lots of bug fixes (although I expect there are still some more to come). Also, there was a spelling mistake in the class name of the old version (as noted by @tpr above), so you should uninstall the old version and install this new version from scratch. Would like to get an idea of how many people are using this - I'd like to get it working well, but it's already been a substantial effort and want to make sure this is in demand over the Module Settings Import / Export that I released yesterday. Obviously this is way more powerful, but maybe it's more than most people want. Thanks for any feedback. Cheers, Adrian

I believe this requested change: https://github.com/processwire/processwire-requests/issues/25 to PW will fix it so long as the server is 64bit.

I bet the server that is failing has strict error reporting on. The code you are using should return this error: Error: Use of undefined constant pages - assumed 'pages' So it will work with strict error reporting off, but it's not correct code.