marcus

Oh yes - Ryans post screams to be put on a subsite like processwire.com/philosophy.

Usually as gists on GitHub (why aren't they calling this part of their site "GistHub"? Would be my kind of humor), but until now the "normal" way. But this gistbox app looks very useful as a better interface for this, thanks for the hint! Although I find the Chrome extension somehow "aggressive" when it comes to "hooking" into website rendering. But it is just an option, anyway. Hopefully there is more feedback coming in on the two approaches over the next days Otherwise I'd like to propose a prototype phase with both definitions of recipes parallelly.

One aspect of this discussion, that derived from a very different meant thread of mine, is the difference in the definition of the word "developer". For one party, this is equal to front-end, while the "other ones" are coders/programmers. The other group defines development as both front- and backend. So even the claim of being a "developer-friendly" system includes potential annoyance. The web development universe becomes more complex, more powerful and more amazing every day - but the words and titles do not catch up. I think one has to keep this in mind especially in discussions like this where one could easily generalize "...but a developer has to this and that".

I think this is an ingenious idea and the perfect amount of onboarding / starter assistance! Nothing less, but also nothing more. And that Philipp's/conclurer's service just launched and this way is able to quickly showcase Nico's module gives me a hell of a good feeling regarding PWs future. And all the features of 2.5 of course!

Without intentional searching, I stumbled upon some snippets that would be adequate recipes - if tagged well and accompanied with a short description of problem and solution: https://processwire.com/talk/topic/5578-how-to-use-fancybox/?p=73141 https://processwire.com/talk/topic/7167-server-error-with-latest-dev-build/#entry69041 https://processwire.com/talk/topic/7573-best-way-to-implement-a-global-utility-function/#entry73157 https://processwire.com/talk/topic/3779-use-csrf-in-your-own-forms/ Just to add more examples to my idea of processwire-recipes. Since community attribution would be crucial for such a project, it's also a matter of pragmatism to keep recipes short. The easier it is to contribute the bigger the chances are that anyone does. To not create a parallel structures but to join forces on this topic, Nico and I spoke yesterday and we learned that our approaches differ slightly. We decided to present these both - and are eager to hear your feedback on them. To keep things simple Nico will shortly present the state of his snippets.pw idea so far in this very topic. What connects us nevertheless is the feel that there is need for such a "PW knowledge hub" page.

I totally avoid them. Used to do design work myself in the past, but then decided to concentrate on frontend. For design load, I team up with Tino, a proper designer in my office.

Hi gRegor, have a look into owzim's module config helper class: https://github.com/owzim/PWModuleConfigHelper - maybe it is of some use in your case.

This sounds like a good idea! Already got an idea for the humble name of said fork, "Superreno"

Thanks! Will look into it and try again after one more coffee /edit: Ah yes, I didn't create the surrounding form via api, but manually...

Hm, tried that (1. jsConfig 2. loading of jQueryCore + InputfieldCKEditor 3. loading of scripts, styles) - no change.

Thanks! Added the jQueryCore dependency (should have thought of this...) and the $jsConfig to the head. Still, there's no rendering of the modules styles and scripts, although I included... foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; foreach($config->styles->unique() as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />"; ... right after the $jsConfig and before I load module CKEditor.

I'll try to get CKEditor in a front end form, did some research here but still got the feeling that I'm missing an important step. That's what I do so far: 1. Referencing the module (I'm working with 2.4.18, so its available) $form = $modules->get('InputfieldCKEditor'); $form->render(); // not sure about this. But its an aptly named public method of the module Though I never found example code incorperating render(); 2. Put that into the site's head in order to get the necessary JS and CSS loaded: foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; foreach($config->styles->unique() as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />"; 3. Within the template I would like to have CKE, the following code <label for="body">Beschreibung:</label> <textarea id="Inputfield_body" class="FieldtypeTextarea InputfieldMaxWidth " name="body" rows="5" name="body"> ... </textarea> <script>CKEDITOR.replace('body', config.InputfieldCKEditor_body);</script> Neither CKEditors JS nor CSS gets loaded and therefore it doesn't work (JS object CKEDITOR is undefined) so I get the feeling that I initalize the whole thing in a wrong way. Is there any documentation on this I have missed? Same thing goes for a jQueryUI datepicker later - I got the feeling that haven't yet grasped the basic principle. Thanks!

Yep, thats more or less what I had in mind. Format-wise and compared to the Bolt snippets, I would propose to add more context, since I like the trio "Problem - Solution - Discussion" (see laravel recipes example above). But their tagging is perfect.