nikosch

Wow, Gerrit van Aaken Hey Gerrit, feel free to leave your comments/wishes here or at git hub. I'm not sure, how fast I can continue work on this. But I'm curious about your improvements. Please keep in mind, that this module is still work in progress. I already use it in production, but it's not well tested. I can not say, if it works well on a large scale (like your big image database). Because the implementation uses JSON as storage format, be sure you don't need PWire-typical Selectors on your image-links. A LIKE-driven database lookup is all you can get on this fields atm (and maybe at all).

From the repeater fieldytype javascript: // Re-enable CKEditor instances ui.item.find('textarea.InputfieldCKEditorNormal:not(.InputfieldCKEditorLoaded)').each(function() { $(this).closest('.InputfieldCKEditor').trigger('reloaded', [ 'InputfieldRepeaterSort' ]); }); // Re-enable the TinyMCE instances ui.item.find('.InputfieldTinyMCE textarea').each(function() { tinyMCE.execCommand('mceAddControl', false, $(this).attr('id')); }); This is not nice. Please trigger global events on the window object, so every dynamic javascript component can subscribe and init/update it service on repeater ADD/MOVE/DELETE operations.

Hi ryan, is this topic outdated? Because all pages have an unpublished-Status (in 2016). Or do I miss the point here? Maybe this should be added in this thread.

Something broke my posting. Just a moment please. [edit] Finally!

So, here we are. Sorry the actions are a little hectic in respect of the file size (though its still huge enough to get trouble with the forum upload). tried imgur now:

Maybe you selected the wrong input field type?

Escaping? https://daringfireball.net/projects/markdown/syntax#backslash Or do I get the question wrong?

Servus bernhard, thank you for your attention. After a long office day I will better try this on weekend *). Fixed some stuff for the moment, especially dependencies from other modules (CKE). *) besides I have to clean up a messy PW test installation first

dropped a first prototype onto github some minutes ago. very early stage, developed and barely tested under PW 3.0.9. Reuses some stylesheets from CKEditor, so be sure you have installed that as well, if you want to test it. https://github.com/nikosch/ProcessWireImageLink [edit] not sure, if this works in other versions of PW and how it behaves with additional image processors. But the code is no rocket science, so the chances are not too bad

While this looks powerful, one of the important things (USP ) is missing: What about the embedding context of all this media types. Speaking of responsive websites, picture elements with different image versions, device dependent scaling, video quality etc. As long as all you do is "feeding" a rich text editor that can handle one image (plus a description more or less), you don't need a extraordinary media manager IMHO. But this is only my opinion. 2nd big topic for a "respectable Digital Asset Management" as said above is rights management. A media rights management should manage: who can see, embed, delete, edit, label .. assets. Maybe a separated collection for every user role (speaking of folders again ). Most important: access control have to be functional in resource serving context as well (means: you can't access a restricted resource, even if you know it's address).

Hello again, while I evaluated possabilities around reusing the image dialog outside of CKE (https://processwire.com/talk/topic/10009-image-field-select-image-from-another-page/) I did a introspektion of CKE's pwimage plugin (indeed I reused a lot of the given logic). Because I don't like the way, the plugin grabs its image information in a big bulk of code, I started to refactor the code and ended in something like this (excerpt): [..] this.config = { uri : ProcessWire.config.urls.admin + 'page/image/' , selectors : { image : '#selected_image' , captionWrapper : '#wrap_caption' , cbLink : '#selected_image_link' , cbHiDpi : '#selected_image_hidpi' , cbCaption : '#selected_image_caption' , inDescription : '#selected_image_description' , inRotation : '#selected_image_rotate' , inPageId : '#page_id' } [..] }; [..] , getImageProperties : function (jImage , jIframeContent) { var that = this; var jImage = jQuery (that.config.selectors.image , jIframeContent); var jCheckboxLinkToLarger = jQuery (that.config.selectors.cbLink , jIframeContent); var jCheckboxHiDpi = jQuery (that.config.selectors.cbHiDpi , jIframeContent); var jCheckboxCaption = jQuery (that.config.selectors.cbCaption , jIframeContent); var jInputDescription = jQuery (that.config.selectors.inDescription , jIframeContent); var jInputRotation = jQuery (that.config.selectors.inRotation , jIframeContent); var jInputPageId = jQuery (that.config.selectors.inPageId , jIframeContent); var flipHorizontal = jImage.hasClass ('flip_horizontal'); var flipVertical = jImage.hasClass ('flip_vertical'); var src = jImage.attr ('src'); var cls = jImage .removeClass ('ui-resizable No Alignment resizable_setup') .removeClass ('rotate90 rotate180 rotate270 rotate-90 rotate-180 rotate-270') .removeClass ('flip_vertical flip_horizontal') .attr ('class') ; var imageProperties = { 'identifier' : jImage.data ('idname') , 'pageId' : jInputPageId.val () , 'src' : src , 'file' : src.substring (src.lastIndexOf ('/') + 1) , 'origin' : jCheckboxLinkToLarger.val () , 'width' : jImage.attr ('width') , 'height' : jImage.attr ('height') , 'widthAuto' : jImage.attr ('width') == 0 , 'linkOrigin' : jCheckboxLinkToLarger.is (":checked") , 'alt' : jInputDescription.val () , 'caption' : jCheckboxCaption.is (":checked") , 'hidpi' : jCheckboxHiDpi.is (":checked") , 'editing' : { 'rotate' : parseInt (jInputRotation.val ()) , 'flip-h' : flipHorizontal , 'flip-v' : flipVertical , 'crop-x' : 0 , 'crop-y' : 0 } , 'class' : cls }; if (! imageProperties.width) { imageProperties.width = jImage.width (); } if (! imageProperties.height) { imageProperties.height = jImage.height (); } return imageProperties; } As you can see, I started to put selectors into configurations und tried to build a literal of the significant image data (which was the goal). I thought it would be nice, if the Image modal page itself could implement an interface like this. So that every derived operation (including CKE) could simply ask for image properties instead of scratching data from markup and input element status all by itself. In result there would exist a future proof approach for times when UI elements, possible image modifications etc. change.

Thank you. But I'm speaking about /wire/modules/Inputfield/InputfieldCKEditor/plugins/pwimage

I tried to build this one on friday. I used a onClick event on a input field, a part of the RTE Javascript where I altered the return value (img markup) into the PageID/Src out of the data-idname-attribute. It worked very well as a proof of concept. I will try to get a better version, where it returns a json of significant Image properties. There are some design decisions to make: - use cropping, resizing etc.? - create a cached image version on these actions or get only the editing data to do all operations live in the use context? and so on. But it's possible. One thing to mention: What is the license of the CKE modul pwimage

Hi folks, I try to realize a module/fieldtype, that shows a backend comment in the page editor. Therefore I extended a textarea field and changed the render method to render the input-value plus a textfield to change the value. Later I want to toggle the view state of preview/input field by doubleclick. This works (see image below). I thought it would be nice to use Markdown or textile for basic text styling via TextFormatter, but unfortunately I don't get output formatting to work in the backend, while it works well in the frontend context. Is there any difference in rendering between frontend/backend or did I get the method totally wrong? Here's a code snippet, I'm new in module programming and I tried different ways, so thank you for any hints: // in InputfieldBackendAnnotation public function ___render() { $this->config->scripts->add ($this->config->urls->InputfieldBackendAnnotation . "InputfieldBackendAnnotation.js"); $attrs = $this->getAttributes(); $value = $attrs['value']; unset($attrs['value']); $out = $this->___renderValue () . "\n" . "<textarea " . $this->getAttributesString($attrs) . ">" . $value . "</textarea>"; return $out; } Strange enough this formats the output with nl2br, but no other Markup.

More important: How do you manage your grid blocks in the backend. Repeaters? PageTableExtended? Repeaters have the problem, that you can use only one content type. With PTE every container is a page 1) which lies between other child pages and 2) needs a "page creating activity during creation. Too sad the new Repeater Matrix is a pro fields module.

Not sure if this topic was almost discussed in this board: Is the any mechanism, to clean up this cache periodically? I mean, even if I crop images in the ImagesPicker dialog and cancel the dialog later a cache item is made.

Is it really that hard to create a Image/File reference field? The modal window even exists in the RTE dialog. The thing is: What it needs is a field, that returns a image OBJECT, not markup like RTE or all other plugins like ImageTags do. So that you can use all the nice frontend methods like cropping, caching, compressing etc. The only ways so far are: a) Use Image fields. You create doubled image uploads and have to redo all operations (cropping..) on the uploads b) Use RTE. You get the image only as markup - Well you can parse it, get the id, request the databse You need "expensive" fields in your backend, instead of a ID-entry-field You can not prevent users from editing more stuff (text, more images..) into your input Use cases for Image-References: - Group Images by topic to achieve clean backend structures - Less place in complex input scenarios - To avoid double uploads: Place ImageFields outside Repeaters, ImageReferences inside - To avoid double uploads: Place ImageFields outside PageTableExtended, ImageReferences inside - To avoid double uploads: Place reused page elements (like brand elements, trust symbols) in a global (maybe write proteced) folder - To avoid double uploads:Reuse Images in complex multi picture content blocks like <picture>-Elements - Use Image-Files with different meta infos, captions etc. without double uploading Nice to have feature extensions: - optional preview picture - optional additional fields (like in ImageExtra)

I will. Thank you, MadeMyDay

Recently I found the ProFields PageTable Type in the dev version, which adresses a lot of my ideas. Basically it needs only a (dynamic rendered?) dummy field in the table, that represents a preview of the page in the background. Howsoever its much more useful than a repeater

Exactly. I came to Processwire from Redaxo and I miss nothing - except the easy module approach for page content authoring. Module stacking has its downsides without a question e.g. you can't group slices with group elements oder classes. But it is a nice way to edit page content (and to force the editors not to "draw" page content). Especially in times of fluid grid layouts and closed Wysiwyg editors, that never meet the wishes of advances authors. So here's my suggestion: Create a (another ) Page(Collection) Fieldtype, which stores nothing but Page references (so you can reuse content-parts of other pages as well). To adress the point of DV-JF the only differences to "normal" Page InputFieldtypes were: They would render with a short, stacked preview of each linked page (the page title or something, maybe the template name) AND on Click they open the linked page as overlay editor. Nice to haves (and probably easy to do): Stacked view is sortable and has icons to remove the links (not the pages). How about that?