Leaderboard

This is a double full circle for me. I started using TinyMCE, then migrated my custom stuff to FCKEditor (when that's what it was called). Then when I came to PW Tiny was still the default, then it moved to CKEditor and now we're going back to Tiny :)

This week I'm happy to report that the InputfieldTinyMCE module is now released. It is currently released in the modules directory and GitHub but the plan is it will be merged into the core, likely before the end of the year. No need to wait till then though, as you can start using it today. Please consider the module in beta for the moment, though the TinyMCE library itself is in a stable state. A lot of the work that went into developing this module went into the configuration aspect. Here are a few a more details that weren't covered in last week's post: After installing the module, on the module configuration screen, you can decide whether several settings should be configurable for each field, or if you want to just configure them with the module (affecting all fields): One of things that I thought was important was to make it a lot simpler to add custom classes/styles to the editor. I always found this kind of a pain in CKEditor. So in TinyMCE, I made it so that you can just define these custom styles with the field settings using just simple CSS definitions. InputfieldTinyMCE takes care of converting to a format that TinyMCE can understand (for its menus), as well as the styles to show in the editor. For instance, I wanted to add some common Uikit text classes to a custom "Uikit" group in the Styles dropdown: And here's the result in the editor: The markup produced has the correct Uikit classes in the markup so that on the front-end of my site the output is Uikit ready. You can add 3rd party or your own custom plugins from the module settings: And then you can enable them for any field in the field editor: These are just a few interesting tidbits, but there's a lot more. Also, if you didn't see last week's blog post, that covers a lot more too. Either way, I'd encourage you to download InputfieldTinyMCE, give it a try and please let me know how it works for you. If you come across any bugs, please open an issue report. Thanks for reading and have a great weekend!

https://github.com/baumrock/RockShell#how-to-use-rockshell It's a command line interface for installing PW (php rockshell pw-install) and it also has an opinionated setup command (php rockshell pw-setup). Creating commands is very easy. You can list all available commands via "php rockshell" I'm afraid I don't understand what you want to say. But here's the conditions from their FAQ page: teppo was faster ?

I don't want to be a grinch here or anything like that... but: Did you talk to your tax accountant about receiving donations through PayPal, Buy me a coffee, Github, whatever? You might want to. At least to be safe. Just asking for a tax audit I had a few weeks back. ?

Was a bit slow to answer, so @gornycreative pretty much covered this already, but just to be clear: in my experience most of them are still valid. Potential exceptions may, for an example, include modules that for some reason rely heavily on a certain admin theme. Overall there have been very few breaking changes in the core through the years, so most — probably close to all — modules that worked for 3.0 (or even 2.x versions) still work today, some may just look a bit off. Or there may be a core feature nowadays that solves a similar need without a need for third party module ? One thing worth keeping in mind is thatolder modules typically don't have/use the ProcessWire namespace, which means that you'll have to keep FileCompiler enabled for modules. This is the case by default, so not a problem unless you've intentionally disabled $config->moduleCompile via site/config.php. I must admit that this confused me a bit. If you're just looking to see which field is attached to which page, that doesn't sound like a reason to switch entire admin theme. Admin themes are generally more about the look and feel of the admin, not so much about the features included, while this sounds like a rather specific feature. I can't remember if I've seen exactly this type of list myself; fields are connected to templates, so usually you'd want to see which templates a field belongs to or which pages use a specific template, rather than which pages use a specific field ? If you're interested which fields have a value in specific field, then that's a different story. You can use the built-in pages find feature to list pages where that field is not empty: Also, as a general rule of thumb — and this is definitely more than a bit opinionated — I wouldn't recommend installing new admin themes unless you know what you're doing. While admin themes can be changed, and third party admin themes may work perfectly fine, generally speaking admin features are most likely to work best with the default (Uikit) admin theme. Then again, "at your own risk" is often just something developers say when they put stuff out there. It doesn't necessarily mean that something is broken — just that there's no guarantee that it will, and also no warranty in case it doesn't work ? Don't worry, asking questions is A-OK ?

I always loved working with the Tinymce customization rather than CK, very excited to see how it has evolved!

@cb2004 Well my preference would have been that CKEditor continue developing and improving CKEditor 4, but now that I've worked with TinyMCE 6 for 3 weeks it's been a pleasant surprise and even more of an upgrade than I think CKEditor 5 would have been. TinyMCE comes with a media plugin and toolbar. Though I've not used it and am guessing you'd have to turn off the Purifier option in order to use it (since it would insert iframes or scripts). I don't think iframes and scripts belong in richtext since it would be very difficult to discern malicious scripts from legit scripts. So I'd rather just disallow them completely (which is one thing Purifier does). Basically, embedding social media or media players directly in markup from a richtext editor opens a lot of security concerns. On the other hand, using modules like TextformatterVideoEmbed, HannaCode, or others that let you embed service specific stuff — this is a good way to do it. It's relatively simple to convert the embed scripts/codes from nearly any social media service into a HannaCode, and even simpler if there's a dedicated module for the service you are wanting to use. So for your client, I would ask them which social media posts they are looking to embed, find out the company's recommend way of doing that, and convert it to a HannaCode, dedicated Textformatter module (one of the simplest kind of moodules to make), or even just ready.php hook after FieldtypeTextarea::formatValue. I think you'll find that configuring individual TinyMCE fields is very simple and there's not really much, if anything at all, to converting a field using CKEditor to one using TinyMCE. I thought that I could also have TinyMCE recognize some of the CKEditor settings and convert them automatically (like toolbar, available headlines, and plugins). On the other hand, I think it's better to configure TinyMCE yourself as there's a lot of useful stuff that wasn't there with CKEditor. But if you just want to convert a defaults configured CKEditor field to a defaults configured TinyMCE field, there's basically nothing to it other than selecting "TinyMCE" rather than "CKEditor" for the "Inputfield type" (Textarea field settings dropdown on the Details tab). One of the nice things about changing a CKEditor 4 field to TinyMCE is that saving a page with an existing value doesn't usually result in any changes to the markup value. CKEditor 4 and TinyMCE 6 seem to markup things exactly the same, just plain simple HTML. Also I should mention that CKEditor 4 isn't going to stop working at any point either. I've been thinking that both TinyMCE and CKEditor will live in the core until CKEditor 4 is completely EOL, and at that point it'll move to a 1st party module. So there won't ever be a case where you will be required to convert all of your CKEditor to TinyMCE fields, unless you want to. In my case, I'll probably keep some installations using CKEditor 4 until it needs some other kind of major development or redo. ProFields Combo, Table and Textareas will all support both CKEditor 4 and TinyMCE 6. I don't see any reason to ever drop CKEditor 4 support in ProFields. So long as the module is installed, it'll be selectable as an option. I'll be adding TinyMCE support to these modules soon as well. @Ivan Gretsky Thanks for testing it out! The intention is that everything works just as before, so there isn't any learning curve. HTML Purifier is enabled by default unless you turn it off (in "Features"). This is what cleans the markup server-side. Since you mention pink H1s, I'm wondering if you instead mean CKEditor's ACF (advanced content filter)? TinyMCE has something similar (content filtering) that can be configured with various settings like valid_elements, valid_children, valid_styles, invalid_styles, and many others. InputfieldTinyMCE uses the defaults for most of these, but the one that I've focused on as a configurable setting with the module is invalid_styles which is exactly how you could prevent pink H1s, by just typing the word "color" and "background" and "background-color" into your "Invalid styles" setting. It's also a good idea to instruct clients on how to "paste as plain text", or add the plain text paste option to your toolbar (I think it's already in the menubar). If you want even more control over how content is pasted without any instruction to the client, TinyMCE has pretty much thought of everything here, see Copy/paste options. As far as I know, we didn't have this level of control with CKEditor. There's not much to add here as there's little or nothing to it unless you've spent a lot of time really tweaking CKEditor settings and custom plugins, etc. And for those cases I would probably just keep using CKEditor 4. But I do plan to have TinyMCE recognize CKEditor settings for toolbar, plugins and block formats, and automatically convert them where there are equivalents. Though I worry a little that by doing that, some might skip over doing any of their own configuration, and thus miss a lot of new options. I'm going to detail how to build simple plugins in a related blog post. I was thinking of a simple HannaCode insert plugin as a good example. Not as powerful as HannaCodeDialog, but rather just a simple example to get module authors started. The module also comes with a really simple plugin example named hello that just alerts "Hello" every time you click a button on the toolbar or menubar, but this obviously isn't useful for anything other than being a starting point.

That's one of the things that "php rockshell pw-setup" does. DDEV is supposed to be used with docker, so you can use it on any OS. You'll get exactly the same environment no matter who is working on the project - that's especially great in teams. Laragon is not by far easier to use but a lot easier to setup. But you only need to setup DDEV once. Then it runs and runs and runs. And with ddev setting up a new project is by far easier then it was with Laragon for me. It's just "ddev config" and you are done. The biggest benefit for me is that you get a real unix dev environment. So if you have some special need for your server (eg creating thumbnails from PDF via poppler-utils you are out of luck with laragon). With DDEV you simply add poppler-utils to the config of the web container and you can develop everything locally and it will work the same on the live server. Also the config of the project can be added to the project's git repo. That means everybody can just do a git pull && ddev start and will have a working version of the project with all the settings and tools needed for it to run. You can't do that with laragon.

Exactly this! Solved! Ohh!! This is neat ? Need to upgrade to latest RockMigrations, still on v1!

FCKEditor actually is what CKEditor was originally called. I think it was a good marketing decision to change the name to CKEditor. ? It will be interesting to see what editor IP.Board switches to, whether CKEditor 5, TinyMCE 6, some other editor, or if they just keep using CKEditor 4. Currently, this version of IP.Board uses the same exact CKEditor version as ProcessWire (4.19.0).

If you are using custom page classes + RockMigrations MagicPages feature, then you can simply add this to your init() method: $this->createOnTop(); Here's the full code for a custom page class using that feature: <?php namespace ProcessWire; use RockMigrations\MagicPage; class BasicPagePage extends Page { use MagicPage; public function init() { // $this->setPageNameFromTitle(); // would also be possible :) $this->createOnTop(); } }

See the first bullet point under "Docker desktop may be used for free as part of a Docker Personal subscription for": This is repeated in other documents, including the service agreement. You don't have to (and can't, that would be quite impossible) fill all the conditions for free use, just one, and use within "small companies" (or "small businesses") is one of them.

I think the easiest way is the AddNewChildFirst option in AdminOnSteroids. If you don't want to use that entire module, can you can grab the hook it uses: https://github.com/rolandtoth/AdminOnSteroids/blob/2e8f9c56dbc0d05edcb203d7dcf9af31eb862b02/AdminOnSteroids.module#L786-L795 Basically you're just setting the sort value of the new page to 0.

As you can use almost ANY available HTML in ProcessWire... the part of buying templates/themes is self-explanatory. While selling themes... there are some (3 or 4 I know of) but that's it. As ProcessWire is so individual in a lot of areas, creating themes only works out for basic setups like blogs or something. That's the reason I dropped most of my starter profiles a while back. Those worked for what they were but supporting tons of "I need this, that, and whatever ... BUT without paying anything" made me drop them completely. Yet selling full-projects based on ProcessWire is thing that works out pretty well if you know your audience/niche.

Interesting... for me it's always $config->dbHost = 'ddev-projectname-db'; You can use it on both actually quite easily. The benefit is (as @bernhard already mentioned) it's Docker-based and you could move on to almost any other machine just with your local config. BUT on Linux it depends a bit on your distro as Arch doesn't has the needed packages - even in the AUR they are missing. Ubuntu, Debian and Fedora/CentOS work totally fine. One thing I learned the hard way... talk to your real host to know what they are using so you can create a matching DDEV host with PHP, MySQL/MariaDB versions matching that exact provider. That makes things way easier sometimes. I can't as Laragon is one of most wonderful dev-setups you can use in my opinion. Install and go from there. It was always a real pleasure to use it and I never ever had any issues with it by itself. Yet... sometimes (as mentioned above) the real hosting company didn't match up with the Laragon setup which caused minor issues at some point - it's years back so I don't remember the details anymore.

There are a number of older modules that still work just fine, generally speaking there is generally not a lot of compatibility breaking upgrade during the core upgrade cycle. It's also not necessary to upgrade to the latest and greatest dev version - there is always a stable release channel and a development channel - which channel you choose to put in production is ultimately up to you. Kongondo has stuff on his own site. https://processwireshop.pw/plugins/dynamic-selects/ When you view the fields list, it shows you how many pages use that field and clicking that number will give you a list. You can also get lister pro which allows you to create remembered custom lists based on any number of criteria, including selectors to check if a field is filled out or empty. For your purposes of analyzing field use, this is one I'd definitely recommend - it is also possible to edit value within a lister. https://processwire.com/store/lister-pro/ There is a version of Lister included in core but it doesn't have the ability to remember/save listers as pages or edit-in-place.

Hey @fruid, just noticed this post in the modules forum. It would be best to post ProMailer specific questions to the ProMailer (VIP) support area of the forum — this way Ryan will notice them. I've never used a subscription form from ProMailer myself so can't really answer right away, but it looks like form markup is defined (and can be customized) via promailer-subscribe.php. You can find instructions for modifying ProMailer templates from https://processwire.com/store/pro-mailer/manual/#about-the-promailer-subscribe-page-template-file (specifically take a closer look at the part starting with "If you have any custom fields you also want to use, please do the following" under "Modifying the “Subscribe” form"). Custom fields are explained at https://processwire.com/store/pro-mailer/manual/#custom-fields-reference. -- The modules area of the forum is intended for module-specific support threads (one thread per module) so I'm moving this thread to "General Support".

Hi, I'm very happy to announce that processwire is finally available on turnkey. Here is the link https://www.turnkeylinux.org/node/32567 Turnkey offers production ready free open source server images, meaning that they give you servers already installed and configured ready to be facing the internet. You can now host your own processwire without having to install or configure it. Thanks, Have a good day !!

Good day, community! I have found another great opportunity to support PW ecosystem - just look here! This is @teppo's sponsorship page. He is doing such a load of super cool and useful things, that sponsoring him is a sure must))) Please start throwing your money at this fine gentleman)) Pitifully I cannot do it myself now easily, but I'll find a way. I almost feel guilty for not paying for Wireframe)) I've updated my other post with the modules' authors accepting donations list - just in case. You can check other great sponsorship chances there.