adrian

See if this helps: https://processwire.com/talk/topic/17089-images-disapear-after-uploading-and-saving/?do=findComment&comment=150139

Thanks for the report - i was missing a formatValue method which is needed by Lister. Please try the latest version and let me know how that goes for you.

You need to take a look at the Network panel and view the reponse for the ajax upload script - it looks like a PHP error that is causing that unexpected character - probablt something about memory.

@godmok, @szabesz and @mel47 - could you please try the latest version on the dev branch. I had to rejig a few things to get this new version to also work with Form Builder. @mel47 - please read my previous post above regarding the breaking changes in this new version. I'll be making this the master version once I have confirmation from you guys that you aren't seeing any problems. I don't like introducing breaking changes, but in this case it was necessary to allow more flexibility for calling custom outputs via the API. Thanks!

Look here, there is complete upgrade procedure with help: Thanks for chiming in @horst - I have already linked to that: This is the problem with multiple threads for the same issue, but I think @Oca2 has the message on that now

http://modules.processwire.com/modules/markup-social-share-buttons/

@bernhard - not sure if this is useful or not, but it shows you the SQL that the PageFinder uses for a given selector.

Each page can be restricted to a user role, so you could setup each page to be limited to a different role and assign these roles to separate users - I think this would give you what you want. But without knowing exactly your scenario, it's hard to know if this would be the best option or not. You might be better off with a custom module or a ready.php hook on Page::render and handle the logic that way.

Sorry to sound like a broken record, but CroppableImage returns a pageimage object, not a url, so you need to add ->url to the end of that: <img src='{$child->overviewimg->eq(0)->getCrop('thumbnail')->url}' alt='$child->title'> If you take a look at the HTML source of the page you would have seen that it was return an ID and not a URL to the image. Also another tip is to use the Console Panel in Tracy to investigate things. In particular note what happens when you echo (which outputs a string) that it returns the filename, but not the URL.

Have you looked at the path to the image in the HTML? Did you add the ->url at the end? If it's a multiple images field, you will also need ->first() in there or a foreach loop to get each image individually.

@Oca2 - please try to avoid double posting and if you do, please follow up on both so people don't try to help you when you've already been helped. Thanks! Cheers, Adrian

It sounds like your site/assets/files folder is not writable. You can check out the Diagnostics panel in Tracy for info on the settings for each of the key directories.

You need to have a read of this: https://processwire.com/talk/topic/14251-upgrading-from-thumbnails-module-to-croppable-image-3/ Also note that once you have taken care of that, you need to add ->url to the end of your src - croppable image returns a pageimage object, not a url like the old module did.

I don't think Croppable image has this method - I think you'll have to updated your API calls for this module.

Me too.

I haven't been following the conversation, but if it helps, here is what I see with @kongondo's code:

I addition to the entityEncodeText that @bernhard mentioned, you might also find this useful: http://modules.processwire.com/modules/dynamic-description-notes/

Not yet - I haven't come across any issues that the file compiler (or some small minor conditional) doesn't take care of. Not sure I am ready to ditch 2.x support just yet, but I'll definitely keep in mind your argument re this module. Maybe I should just ask here - anyone using this module on 2.x? Would anyone mind if it was made 3.x only?

@godmok and @szabesz - well that took way too much time It's very rough, but please test the new version on the dev branch: https://github.com/adrianbj/FieldtypePhone/tree/dev This new version has lots of breaking changes, so please don't update an existing site. You'll need to uninstall and reinstall to get the new format for the default formats to show. You could I guess copy/paste them in from the module code to that field if you have data already that you can't lose. Format options now have a proper name associated with them, so if you change the pattern for a format, it should update the output everywhere. Also, you can now see exactly how each format will look based on the pattern, rather than you having to enter that in a comment at the end. When defining formats, follow this format. The category headings are optional. The key things is: name | pattern Now you can also call these formats separately from the API regardless of what the selected output format is. You can call like this: $page->phone->australiaWithCountryAreaCodeNoLeadingZero

https://github.com/mr-fan/AutoImagePages

@godmok - obviously an easy fix to ignore blank lines. The issue of the format not being updated is a little trickier - currently the selected format is stored by the format "code", rather than by a name, so changing the definition of a format won't update the format stored for a field. I should probably store formats by their "name" so the current definition for a format is called each time. I think this would be a good improvement for this module and would also be inline with your request to be able to call the format directly. The catch is making sure I don't break existing sites using this module, so I'll have to make this change with that in mind. I'll see what I can do.

In the module settings you can create your own format. Take a look at the Australia examples - the one with the country code has no leading zero for the area code. My initial suggestion to you would be to create your format based on that. I guess the contingency I never implemented is when you want to be able to call different formats for the same phone field. My initial thought for adding this is to allow you to call the format based on the name of the format in the commented part. So for example if you created a format like this: +1 (23) 456-7890 x321 /* My No Leading Zero With Country: +1 (11) 111-1111 x111 */ you would be able to call it via the API like this: $page->phone->formatted('MyNoLeadingZeroWithCountry'); That way you could create whatever custom formats you need, name them how you want, and call multiple versions on the same field because these wouldn't rely on the format chosen either in the module settings or the field settings. Does this sound ok?

No better feeling on earth when it's really good

Happily skiing the pow at -6C here in Canada - the more snow, the better Although having lived through a winter in Maryland where they are not prepared for the snow (the housing and the road crews), I do feel for what Ryan is going through!

It looks like you never specify the name of the Options field. You probably want: foreach($page->children as $item) { foreach($item->optionsfield as $option) { echo '<p>'.$option.'</p>'; } }