Leaderboard

An inputfield module that brings EasyMDE Markdown editor to ProcessWire. EasyMDE is a fork of SimpleMDE, for which there is an existing PW module. Inputfield EasyMDE has a few advantages though: EasyMDE seems to be more actively developed than SimpleMDE, which hasn't seen any updates for several years. You can define options for Inputfield EasyMDE. Inputfield EasyMDE can be used in Repeater fields and in custom fields for File/Image fields. Inputfield EasyMDE EasyMDE (Easy Markdown Editor) as an inputfield for ProcessWire. EasyMDE is a Markdown editor with some nice features, allowing users who may be less experienced with Markdown to use familiar toolbar buttons and shortcuts. More information is at the EasyMDE website. Installation Install the Inputfield EasyMDE module. Usage Create a new textarea field, and in the "Inputfield Type" dropdown choose "EasyMDE". Save the field and if you like you can then configure the EasyMDE options for the field as described below. To convert Markdown to HTML you can install the core TextformatterMarkdownExtra module and apply the textformatter to the field. Alternatively you can use $sanitizer->entitiesMarkdown() on the field value, e.g. echo $sanitizer->entitiesMarkdown($page->your_field_name, ['fullMarkdown' => true]); Configuration On the "Input" tab of the field settings you can define EasyMDE options for the field in JSON format. Refer to the EasyMDE documentation for the available options. Keys in the JSON must be surrounded with double quotes. Example: "toolbar": ["bold", "italic", "heading", "|", "side-by-side"], "sideBySideFullscreen": false https://github.com/Toutouwai/InputfieldEasyMDE https://processwire.com/modules/inputfield-easy-mde/

This module is just the inputfield and doesn't get involved with what the user might want to do with the field contents. But I take your point that some users might not know how to convert Markdown to HTML, so thanks for raising it. Using the textformatter you suggested is one way to get HTML from Markdown, or alternatively you could use $sanitizer->entitiesMarkdown() on the field value. I've added a paragraph to the readme. For me personally, the current application is for getting HTML out of custom fields for File/Image fields because CKEditor isn't supported there. Although I emailed Ryan today with some suggested fixes for getting CKEditor working there so hopefully that might change soon. More broadly I think some people just prefer working with Markdown rather than a full-blown WYSIWYG, so this is an inputfield for them. ? I don't think EasyMDE has options for loading custom CSS - the previewClass option is just if you want to specify a different class name than the default on the preview wrapper element. If you want to target the preview element with custom CSS in Page Edit you could write style rules like this: .InputfieldEasyMDE .editor-preview h1 { color:red; } And load your custom CSS file with AdminOnSteroids or with a hook like this: $wire->addHookBefore('ProcessPageEdit::execute', function(HookEvent $event) { $config = $event->wire()->config; $config->styles->add($config->urls->templates . 'custom-styles.css'); });

You might want to add that using the Markdown/Parsedown Extra textformatter is needed as well. It might be obvious to some, but first time I tried without it ?

Thanks @Ivan Gretsky I will look at this and for sure update my code snippet : use PHPHtmlParser\Dom; function print_toc($html, $link = '', $depth = 1) { $dom = new Dom; $dom->loadStr($html); $headings = $dom->find('h'. $depth); $toc = ''; foreach ($headings as $h) { $name = wire('sanitizer')->pageName($h->text); $name = strtolower($name); if($name) $toc .= "<li><a href='{$link}#{$name}'>$h->text</a>"; } return "<ul>$toc</ul>"; }

This is great! Finally it is easily possible to ditch CKEditor. Thank you so much Robin!

Kirby 3.5 is now released and the Blocks + Layout feature looks awesome. Something I still miss in ProcessWire. I know for Blocks we have the Repeater Matrix and you could use it for layouts too, but its not that intuitive in the back-end in my opinion. A module like the Layout feature of Kirby would be really awesome. ? By the way, they have a really good marketing strategy in promoting their features. At least it is working for me. ?

Thanks for the explanation, now it all makes sense to me ?

@Robin S I cannot figure out how to style the preview. Have you already done that? Looks like the option named "previewClass" should be used somehow but I do not get what exactly this means: "previewClass: A string or array of strings that will be applied to the preview screen when activated. Defaults to "editor-preview". Also, the example provided does not help much either: previewClass: "my-custom-styling", previewClass: ["my-custom-styling", "more-custom-styling"], my-custom-styling it says, but where is it defined and how?

Thx Robin for another great module! ? I'm always stripping down the interface of CKEditor as much as possible using your great hooks. I wonder where and why you'd be using this field? I think markdown is still too complicated for clients. I'm not using any of those nowadays. Maybe that's why I can't think of where to use this field at the moment. But I'd be happy to hear where you are using it and what you dislike with ckeditor (or why you built the module in the first place). The only thing that I really don't like is copy/paste issues with custom formatting that can get annoying. But there's also a solution for this here.

I don't think you can prevent the output of those fields - but there is a trick you can pull to prevent them being editable (as well as hiding them using a CSS rule on the wrap classes.) If you override the preset values - but to the same strings as the preset would use anyway - then the form renders them with the disabled attribute. Like this.. <?php echo $page->comments->renderForm([ 'presets' => [ 'cite' => $user->name, 'email' => $user->email, ], ]); I haven't verified, but I believe that the comments fieldtype will replace any tampered fields in the posted form with the original preset, so this might work for you.

Was looking for this too) I guess this is it. Hope it will help someone as this topic is #1 result for the search "textformatter toc". Found the link with some nice extra content here.

For anyone who is interested in integrating tailwind inside a processwire project here is a little walktrough based on my workflow. This little guide is based on Tailwind 1.9.6 (latest before 2.0 release) because some PostCSS library I use are still not compatible with 2.0 version (not a big deal, really). You can find the necessary files here. - Place package.json, tailwind.config.js, postcss.config.js inside your template folder. - Create a "pcss" folder, and make a structure like this: pcss ├── inc │ ├── colors.pcss │ ├── fonts.pcss │ ├── media_queries │ │ ├── lg.pcss │ │ ├── md.pcss │ │ ├── sm.pcss │ │ └── xl.pcss │ └── sitewide.pcss └── kickstart.pcss Now you got everything to get started, let's have a look at the files: package.json Inside "package.json" you have different dependencies I've installed to mimick my "old" scss workflow (importing, nesting, etc..), the important part however is the script section: "start": "npx tailwindcss build pcss/kickstart.pcss -o css/dist.css", "watch": "npx postcss pcss/kickstart.pcss -o css/dist.css --watch", "build": "cross-env NODE_ENV=production npx postcss pcss/kickstart.pcss -o css/dist.css" "start" is the bootstrap script you have to run at first, to let node compile tailwind as a whole. Do it at the beginning of the project or everytime you make some changes to "tailwind.config.js" Change the name of your pcss files accordingly (I've used pcss as an extension, but css would work perfectly fine) "watch" is the next script you have to run in order to have live reload of your stylesheets. "build" is the script you have to invoke once you are ready to deploy to production (you need to specify your purge rules inside postcss.config.js, keep reading.) tailwind.config.js Here you can specify your tailwind configurations, read the docs here. One thing to notice inside mine is that I've set purge: false because I prefer to configure the purge part inside a dedicated file, which is: postcss.config.js This file is responsible to handle postcss options, and purge is one of them. The paths you declare inside the content array are the ones whom will be scanned and purged eventually. Mine could be different than yours, so pay attention. The whitelistPattern array is useful when you want to exclude some classes from the purge phase, below I'm excluding the ones whom starts with "fff-". ... content: [ './*.php', './inc/*.php', './fields/*/*.php' // etc. ], whitelistPatterns: [ // Pattern to exclude during extraction /^(fff-)/ ], ... The other settings are pretty explanatory (cssnano is used in production for minification). As a final note you'll notice that every pcss file I use starts (and ends) with: /* purgecss start ignore */ css... /* purgecss end ignore */ Those tell purgecss to ignore completely the file, since I know I want to retain every rule/class I write in there. If you got everything setup correctly you can start having fun ? Run: npm install then: npm run start and finally: npm run watch Hope this little "guide" could enlighten in using Tailwind ?

Relying on .htaccess is not really uncommon for php cms's out there. Some are more minimal on utilising apache, processwire is probably more on the "take what we can get"-side. Having php serve everything – especially static assets – is just not performant enough in any way. That's the reason for needing to rely on the webserver in front of php in the first place. The reason for apache specifically is because of .htaccess. Other webservers are usually only statically configurable, which is a deal-breaker for any shared-hoster, where a (global) webserver cannot be restarted whenever a single user needs to change his configuration. So if you only support one webserver, it better be apache.

I'm using sort of the same function, and although my setup is different (i have a custom menu generated from a branch on the tree) this might help, i use this right after the opening foreach: $menuVis = true; if($child->menu_roles->count()) { foreach($child->menu_roles as $cmr) { $menuVis = false; $cmrRole = wire('roles')->get("$cmr->name"); if (wire("user")->hasRole("$cmrRole") ) { $menuVis = true; break; } } } if($menuVis == false) continue;