adrian

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.

Thanks, I forgot about that - went looking in the field settings - I still think perhaps it would be best to be configurable at the field level.

Yeah, I have and yesterday I decided not to because I didn't want to bloat this will all the tools available in Module Toolkit, but now I am second guessing that decision especially given that Module Toolkit is mostly a Process module so if you don't run it, it's not doing anything. I'll think on this a little more - stay tuned

This is really the domain of although that module does still need a little attention. That said, there might also be a place for it in this module - let me think on this a little more.

Unfortunately, that doesn't actually work: https://github.com/ryancramerdesign/ProcessWire/issues/1060 I'd actually like to not only have the ability to have a hidden images field, but also the ability to restrict a CkEditor field to store uploaded images in only designated image fields.

I haven't tested, but maybe this helps: https://github.com/somatonic/ColorPicker/issues/7

Or if you up are for a little bit of a challenge and great learning experience, you could create your own custom fieldtype based off the Event fieldtype: http://modules.processwire.com/modules/fieldtype-events/

Module has been released and now available over here: