Leaderboard

The TinyMCE 6 rich text editor opens up a lot of new and useful abilities for ProcessWire users. In this post, we'll take a look at a few of them, and how you can start using them now, with a focus on those that are unique to ProcessWire's implementation of TinyMCE— https://processwire.com/blog/posts/using-tinymce-6-in-processwire/

This isn't the first star rating module for ProcessWire, but I wanted some particular config options and to have the inputfield be usable within FormBuilder. FieldtypeStars The inputfield of FieldtypeStars uses a star rating interface to set a float value. The fieldtype extends FieldtypeFloat. The inputfield has no external dependencies such as jQuery or Font Awesome and can be used in FormBuilder. Config Using InputfieldStars in FormBuilder In order to add a Stars field to a FormBuilder form you must first enable "Stars" in the "Allowed Input Types" field in the FormBuilder module config. https://github.com/Toutouwai/FieldtypeStars https://processwire.com/modules/fieldtype-stars/

Hello Stephan! Hopefully you've scoured the forums and found similarly posed questions by now, but just in case you haven't - ProcessWire is, at its core, a solution for a CMS - a content management system. ProcessWire simply takes that concept a bit further by allowing those who use it to custom tailor the system itself. So with that very short explanation, a Content Management System is something that manages content. This means that once you've come up with a visual template, theme, or whatever you'd want to call it, the system itself is what manages everything from that point onward. Going back and forth from a development tool and using it as your page editor, and hoping that the CMS you choose will simply ingest that - if I'm understanding your use case correctly here - isn't really something that many systems can take advantage of. Theoretically I suppose that it could be used to do it, but it's a lot of work to get it to a point to where it won't realistically even be used to manage things on the site. Using any CMS for this scenario seems like overkill, where the primary content is managed by a visual HTML editor. If it's logical to you, I can't say it's wrong. I will say that it's unique! It's also likely not the best option as: You're relying on your visual HTML editor tool (Pinegrow) to produce proper HTML/CSS/JS that is accessible, and without errors -- and that will always work with whatever main template you intend to embed it into You're installing a PHP/MySQL tool which, other than perhaps for page and navigation management, isn't really being used for anything else, and the powerful functionality found elsewhere in it could not be properly used (ex: search). I think, using the scenario you've provided, the simplest way would be via a PHP include. It's hard for me to picture it all as I'd think if you went this route, it'd almost make more sense to simply manage everything within Pinegrow and just upload all changes manually. I haven't looked at it closely enough, but I think you can manage a navigational structure within Pinegrow, it's just a bit more work. It could be a problem. It all depends on how you create the pages in both systems. If you're not particularly careful with it though, then my answer here would be, "Yes, it could be a problem." Absolute vs relative links would depend on your naming conventions, templating, and internal page creation within PW and Pinegrow. What you could do is use Pinegrow to manage the website in its entirety, as you seem more familiar with that as a tool. Study up on ProcessWire and how it works (and/or other CMS/CMFs to see what might fit your ability and effort the best - flat file-based CMSs might work better for you) - and then slowly convert it to being managed by a CMS instead of Pinegrow.

It used to be on TV in Germany every night, so maybe that? ?

Hi, typo - I think? /site/modules/Padloper/templates/invoice line 74 PadLoper -> Padloper (lowercase L) J

I was testing TinyMCE 6 with tailwindcss and everything works perfect, I tried the tailwindcss prose plugin by simply adding a wrapping div <div class="prose"> and boom... all the text was styled perfectly. Better yet, the classes are not removed, as many times I had to battle with ckeditor not to remove the classes from the source code. Thank you for all the hard work @ryan

Thanks @Robin S - very timely - I am making use of this in a custom frontend form today!

Hi @Kiwi Chris I've added a config setting to prevent migrations if you don't want them to be triggered automatically: $config->noMigrate = true; https://github.com/baumrock/RockMigrations/#running-migrations For adding this setting only to your local dev setup see https://processwire.com/talk/topic/18719-maintain-separate-configs-for-livedev-like-a-boss/

Oh right, it says pretty clear "Does not track inventory", enabling that and it work ofc. How do I delete this thread ? ?

Yes I did make a mistake. I reinstalled everything under Padloper/ and I got a bit further..

Oh I see, thanks. So the $customFormFields in checkout.php is a 'schema' to define the fields, then I also need to change the markup myself. Makes sense. Maybe it's good to mention the markup file here as well, it wasn't clear to me that it existed: https://docs.kongondo.com/start/checkout/custom-customer-form.html#supported-form-inputs Initially I wasn't sure if the checkout.php did anything at all, but since I could hide and show the arrow, I knew it did : P . Not my most thought-through comment. No problems, one step at a time. Appreciate the patience (more questions to come for sure : P ) tx J

I found this video, and in it there is a list of addons that I couldn't find anywhere, so that's why I asked:

Great, thanks - now it works!

Hello @joe_g, Apologies. I updated demo-1 checkout form template file earlier but forgot to also update the template partial for customer details form. I have now fixed this. I will also need to fix those for demos 2 - 4 (inclusive). For info, please see the docs for allowed form inputs. Your 'country' <select> needs to have name='shippingAddressCountry'.

I feel like it would make more sense to call focus() first and size() afterwards, but I haven’t tested or read up on anything.

This is one of those rare weeks where I've got a lot of projects in progress, but all are in the middle, none are at a convenient Friday conclusion for this weekly update. In progress are some core updates, Pro module updates, other module updates, and a client project that's keeping me busy. So I don't have anything new or interesting to report this week, but I like to still check in and say hello, and let you know I'm not running low on coffee or anything like that. ? I hope that you have a great weekend!

In the past I had used the old version of RockMigrations for some simple tasks like adding fields and templates which turned out to be huge time saver. But only just recently I started to use the new version and to discover the possibilities of this tool in more depths. And what should I say, I am really amazed. Once I had grasped the core concepts and, with @bernhard's help, had learned how to use it in a more structured way and in different contexts, it turned out to to be an even bigger time saver. I hate repetitive tasks. Adding fields and templates and fields to templates and configuring labels / access rights etc for fields in the template context in PW is a pleasure when using the GUI. But it is still a repetitive task. With RockMigrations I can have definitions of these fields / templates and fields in template context in a single file and reuse that. In a matter of seconds I have my reusable base structure available to start off a new project. Adding new structure through the GUI in a staging environment and then having to replicate it on the live sytem through the GUI. Repetitive task again. Pushing a migration file to the live system and running the migration. Again in a matter of seconds. Writing migrations wherever I want is also a great feature. Be it inside site/migrate.php or inside a newly developed module, it doesn't matter. RockMigrations will find it and do its job. At the beginning I wasn't sure how to define different field types with all their different properties. RockMigrations comes with VSCode snippets that make things easy. Or you can create a field in the GUI and then just copy/paste the code for the migration from the GUI to your migration logic. So however you prefer to create your fields, RockMigrations has you covered. This post may sound like an advertisement. But I just wanted to express how happy I am after having made the decision to spend some time to learn how to work with this module. That time was definitely well spent. Big thanks to Bernhard for creating this and releasing it as a free module.