vsulin

Hi, this also fixed it for me. I'll see if I can fix the module to work without the workaround now that were certain on the cause. As for the not being able to crop the image without saving. I don't really see that as a real problem.

Hi all, as a developer I only care that there is "atleast one stable version" which supports both legacy and new api that gives developers soft transition period to update their modules. Besides as this is already done with the "oo mysqli" that is available current and upcoming PDO Processwire. Thus we have "no real problem" because all modules can be updated now so they work in the current and upcoming PDO Processwire. And using PDO-only db api in your module as soon as it is available would only break backward compability for your module.

it is 2.3 stable. I added the given code before the default code and it gives the following error when just reloading the edit-page: /processwire/page/edit/ Error: Method name must be a string (line 293 of wire/core/Wire.php)

Hi all, I also ran into a problem with Thumbnails module cropimage field inside a repeater. It does work with superuser account, but when I log in with an account that has all full access to root template (all other public pages have no access rules) and all but "Administer users"-permission. It gives the following error when trying to crop an image manually: Not Editable The given error is twice in ProcessCropImage.module. This is the first one at line 58. I think it might be trying to check the "repeated page" and not the actual page for access. So the access from root/parent isn't inherited correctly to "pages inside repeater"? Or is the logic wrong when working with repeater-fields?

Hi, you guys seem to be troubled more with the fact that content.css should be here or there, but as long as it is a single static file anywhere. You are limited to 1 style and class sections for all of your different fields you use the MyTinyMCE editor on your site. So why not have a content_css.php that outputs settings that can be set per field (like all the other settings) or allowing to set the .css file used, instead of having a single style for all TextArea fields that are set to TinyMCE? This would also allow adding the brabus plugin to the default installation and disable the need to copy the whole module to achieve it all! Just my 2 cents!

Hi, Soma, did you get anywhere with this or should I start from scratch? If that content.css isn't site specific by default, might aswell try with the following. Shouldn't break anything from previous installs just by leaving the default empty: style_formats : [ {title : 'Bold text', inline : 'b'}, {title : 'Red text', inline : 'span', styles : {color : '#ff0000'}}, {title : 'Red header', block : 'h1', styles : {color : '#ff0000'}}, {title : 'Example 1', inline : 'span', classes : 'example1'}, {title : 'Example 2', inline : 'span', classes : 'example2'}, {title : 'Table styles'}, {title : 'Table row 1', selector : 'tr', classes : 'tablerow1'} ]