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.