owzim

Horst to the rescue: $event->arguments[0]->type; // spits out the actual Fieldtype class name

I have a Module, which is an InputField, I have some custom settings, which is accessible via the input tab on the field edit page. I want to validate the settings given by the user. What I have so far (like suggested here): $this->addHookAfter('InputField::processInput', $this, 'HookValidateSettingsInput'); public function HookValidateSettingsInput(HookEvent $event){ $inputfield = $event->object; // unsafe because there can be other fields with that name on other templates // and this hook would trigger there as well if ($inputfield->name == "nameOfTheInputField") { // do stuff } } But this is totally unsafe. How can I check if the currently processed inputfield (which is a text area in this case) belongs to the InputFiled settings of my module. I can't find any reference within the $event->object, just a bunch of input field wrappers with numbers. Thanks.

It'd be cool if one could click together all the fields an templates, export them into files (with the built in export functionality) and later use them on the API level (load the files) to say preconfigure a Module. Is it possible? I have not found anything on that topic. thanks

Awesome news @Ryan, especially the installer, profile exporter and template pre/append stuff

You are right, it's only in the dev branch. The field config would later replace the module config. Will look into that later this day. I am off now. Thanks for the help.

Thanks to Niko I now know I can use selectors for the autoload value. Can I use selectors to the fullest? If so I could limit the autoload to pages that have Textareas in them with the selector only, right? Would that be possible?

Thanks @Soma, will look into the Textarea counter code. I guess I can restructure the whole thing and separate concerns more clearly. Since it's my first (actual) module I am still finding my way through how everything works or should work. I am doing that, but his code base has grown over the years so certain things are done differently every time it seems, because some code uses newer features other uses older ways of doing things. It's a bit tricky at times. I'd still like to know why I cant access the settings although they are present in the json config of that field in the database.

Thanks for the efforts Nico, the autoload stuff has helped already. The difference to TinyMCE module or CKEditor is that those are standalone Inputfields, my module only hooks into things, so there is no dedicated Inputfield config. I could narrow the problem down into a very simple module, so it's easier to spot the problem.

Thanks, I merged it. But: 1. the field settings won't show up no more in the input tab of the field (I guess because the autoload is limited to page edit now) 2. the $data variable is holding merely the default settings not the ones from the database Edit: 1. is now working when I set 'autoload' => 'process=ProcessPageEdit|ProcessField' 2. I read you comment in the code, it says it has to load the moduess setting, not the field settings. I don't want that, that would not make any sense, since I want per field config. Also it IS available in the database within the FIELD settings, see:

Hi Nico, that's very kind of you, thanks. I published a dev branch of the Textarea Preview Module on Github: https://github.com/owzim/ProcessTextareaPreview/tree/dev As I said the code in InputfieldTextarea::getConfigInputfields (on field config -> input) works great but when I try to access the data in InputfieldTextarea::render (on page edit) it's not there. It's all in the file ProcessTextareaPreview.module I hope you find your way through the code. I commented out the Chrome logger stuff, If you have @Soma's Chrome logger module installed, you ca use it.

In my render hook InputfieldTextarea::render: $inputfield = $event->object; $inputfield->getAttributes(); // only holds the standard ones $inputfield->customCssPath; // null $inputfield->cssTheme; // null $inputfield->get("cssTheme"); // null

I added some input fields to the Textarea input tab with a hook: $this->addHookAfter('InputfieldTextarea::getConfigInputfields', function(HookEvent $event) { // field generation here }); The fields are rendered perfectly, all fine here: When I hit "save" the new config values are saved to the database. This is what I see in the field's config in the fields table, all fine, great: {"textformatters":["TextformatterParsedownExtra"],"inputfieldClass":"InputfieldTextarea","collapsed":2,"rows":16,"contentType":0,"trackChangesInterval":777,"cssTheme":"theme-solarized-dark"} But when I want to access the new saved data from anywhere, I can't, it's not there. Only the standard values from textarea are there but not the custom ones. What else do I have to do to make them accessible from the respective fields instance? The are there but do not seem to be added/set to the instances. PS: PW's docs need some serious work =( Thanks!

New version available: It now uses an iframe implementation, not as easy as it sounds, because the text area and the iframe somehow need to share the data. At first I went for the session thing (see above), but then realized there would be too many server requests going on. Then I went with cookies, nah 4096 byte limit .. so I now use local storage with a cookie fallback. So now the styles are scoped properly, no clashing of rules. The refresh interval is now configurable. Major code refactoring under the hood and many additions, little optimizations, not so elegant anymore, but whaaateva. It now comes with another optional theme Solarized Dark, it's not as pretty as I thought, will look for better default ones Key strokes of space and enter are ignored, so no unnecessary refreshes are taking place. When updated content is injected (and overflows the browser window), it does not scroll to to the top, but stays at the current position. Summary how it now works (for those interested): The text area is watched for changes, when it changes, the text is sent to the server, converted via text formatters. a local storage item with a unique key of that field and the respective page is set to true meanwhile within the iframe, JS is polling for that value very frequently (no server requests are taking place here), if it's true the text is injected (and only then to prevent constant flickering), the value is set to false so the iframe is only injecting when changes happen in the text area Roadmap: I would love to make the config on a per field basis, but since this module is not an input field but merely hooks into the rendering I am not sure how to, will look into that. Oh, and it's on the module directory now too: http://modules.processwire.com/modules/process-textarea-preview/ Cheers!

@netcarver Thought of that too, will implement that. Though it's worth noting that the refresh is not happening constantly but only when content changes in the textarea, and then at most once per second (it's implemented with underscore.js's toggle method). Thought of that too at one point. The thing is that the textarea content is passed via post parameter, so if the ajax refreshing is taking place within the iFrame it somehow has to know where to get the data from. Saving a temporary db value is too much I think. Could be done with sessions though. JS saves the TA content via ajax into a session variable with the field name and page id as the key, and the iFrame retrieves that session value within. But I don't how performant that is. Perhaps you had something different in mind? Edit - Some other things to consider with the iFrame approach: Since the iFrame doesn't really know if content has changed until it has fetched the new data, there would have to be a constant fetching within. How to partially surpass it: another session var, which will be set to changed: true from the inputfield ajax, then the iFrame ajax fetches that value, refreshes the HTML content and sets the var to changed: false, so no refreshing is taking place until that var is set to true again. I think that's a pretty important UX issue because a constant refresh would mess with the scrolling, so if the user updates the content and it's long enough that they (see the non-sexist neutral they here? ) have to scroll, a refresh would reset the scrolling position, yuck. This is the part where the whole implementation gets a little less elegant ... but nonetheless should be possible. Also: I'd love to add the js for within the iFrame like in other regular admin/process pages, for now that's not possible, because I die() out the content, see https://github.com/owzim/ProcessTextareaPreview/blob/master/ProcessTextareaPreview.module#L112-L130 Is there another way to prevent the whole admin UI to show up without loosing JS and CSS? Nevermind, I can of course add the script and css links manually.

Yeah, I'll be there.

Hi Adam, Thanks for the module. It's not working for me though, there is no highlighting for markdown =( Also no line numbers are showing, if this is intended, the gap should not be there then. It would also be great to have a little more customisability, like font, color, font size and so on. Or at lest have the option to have custom style sheet?

I don't understand completely. So your Hanna code does not work when executed through the text formatter but everywhere else? What's that code snippet you posted? Is that what you entered in the Hanna code php field? What's that php closing tag doing there? That might break the whole thing. AFAIK you don't enter opening and closing tags in the Hanna code input fields. I am guessing right, that you are patching together a loop with the opening of the loop and the closing of the loop in two different Hanna codes?

When I skim through the existing modules I see some mundane tasks repeated over and over again. The implementation of tasks are quite different between the modules. Install pages, install templates, assign processes, making fields configurable, making modules configurable and so on ... I just stumbled upon a need to abstract common tasks/methods when I tried to have two process modules share similar functionality, so I created a base class. Then this module config thing came up and I created yet another class to abstract that stuff away from me and make it more flexible and easier to extend/update. Both methods would require me to boilerplate code, for use in every module I will create in the future. I hate boilerplate. It can get pretty messy. If I update the boilerplate it's outdated in places it has been used in. So a way better approach, I think, is to have the module helpers have in a separate module and my modules would depend on that. My question to you people is, would you use a Module Helper Module in you Modules? It certainly adds another dependency which might not be desired, so you modules can only be installed if the helpers are installed first. Is that too much? If not I would like to know what common tasks are out there when creating modules so we can create some kind of module helper suite. I am quite new do module dev, so I am only considering the stuff I stumbled upon already. Please share your thoughts on that. Cheers!

I've to admit I misunderstood the modules purpose, like @apeisa, I thought it was a Textformatter. Still don't understand. Gotta install this one ...

Hi girls and boys, I just wanted to write some more details on this module, how it's working, why it's not implemented differently, downsides, how it could be improved and so on. Why Just recently I had an interesting chat with @marcus on how ProcessWire lacks of some markdown capabilities, for the editor in particular. Of course there is the markdown Textformatter (and now Parsedown) but the actual usability of entering Markdown was not yet taken care of in an extend I wished for. The Ghost blog system ships with pre-installed side-by-side Markdown preview capabilities, the Atom editor by Github also has this feature built right in. All in all, Markdown seems to be on the verge, when it comes to have clearly structured text data in Databases and especially in CMSs or blog systems. The folks at Perch CMS even make it one of their core mantras to never ever store any HTML in the DB. RTEs like TinyMCE or CK Editor have their places but as we all know, editor tend to wreck all our carefully structured markup and CSS with their text pasted from Word and the like. Why not client side parsing, upside of server side parsing The initial idea was to merely preview Markdown, but then it came to me that any Texformatter should be able to be previewed, so client side parsing was out of the question pretty early on. Also a JS Markdown parsing implementation could be inconsistent with the actual server side parsing. Downside of server side parsing The major downside obviously is that any text data has to be sent to the server and back so latency is inevitable. Also, you would not want to send data back and forth on every single change immediately (that's why data is send at most once per second, or not at all if no changes are taking place). Upside of current implementation with Ajax, downside of iFrame implementation Since the parsed text is loaded via Ajax and just replaced when the request is finished flickering of the refreshing text is pretty minimal. You cannot prevent images from flickering since they will be re-rendered every time the parsed text is injected. If it would be implemented with an iFrame the thing would be refreshed and flickering would be dominant and annoying. Downside of current implementation with Ajax, upside of iFrame implementation Clashing of CSS rules. If you want to display the elements properly you either have to work with many !important statements or make the rules overly specific with lengthy selectors, otherwise your current admin theme could wreck the display. With an iFrame all the styles are scoped properly, and you could even use styles that are actually used on the site, so the preview would be way more accurate. My questions I'd love to hear some suggestions on how to tackle the listed downsides, or if those should even be considered downsides. Perhaps those are out of scope of this module. The scope could remain to merely preview basic markup, so the editor has an idea how the text would turn out, focused on Textfomatters like Markdown or Textile, Autolinker and so on (so a text-focused scope). Since there already is a great module by Nico which aims at full blown previews. If so, the default hacky overwrite styles could stay as they are (could use some polish) and custom styles could be thrown out as a feature.

Great! Would also be cool to have a similar syntax like in selectors for accessing properties of fields: Hello World, I'm a {{template}} [...]. Oh, and my current relationship status is {{relationship.currentStatus}}. Infinitely deep of course

The module is not limited to markdown/parsedown, you can use any formatter. I just used it as an example. Markdown: http://daringfireball.net/projects/markdown/ Parsedown: http://parsedown.org/ Parsedown formatter: https://processwire.com/talk/topic/6576-module-textformatterparsedown/

This module adds a preview and zoom button to InputfieldTextarea for live previewing the content after being formatted by the text formatters assigned to that specific field. It's pretty alpha still but it already works. For now I was only playing with the Parsedown formatter, but it should work with every other formatter as well, even with Hanna Code, not sure though, haven't tested it. It's restricted to regular textareas, meaning TinyMCE et al are not supported yet, because they need specific change listeners. Will look into it though. The result is fetched via ajax from a process page, the default style sheet contains some Github-like styles but the style sheet is configurable, see module settings. Github: https://github.com/owzim/ProcessTextareaPreview Open for suggestions

Well it's the same with all VMs, they'll never run as performant as the host system itself.

Uhh, closest, I love that method, I use it in jQuery very frequently.