Leaderboard

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!

Great news! I've just installed the new Inputfield on a testing installation. It seems to work well. I've tried both standard and inline modes. Pwlink and pwimage are working, same classes are added for alignment as before. I can't see HTML Purifier. I guess content managers will be happy now inserting all the pink h1's everywhere they love so much) Is it planned or will this be abandoned? As @cb2004 said migration instructions from CKEditor are indeed needed. Hope they are planned. And I guess we should politely ask (beg?) the CKEditor-related module authors to create new versions for TinyMCE. I am talking about: @Robin S and his HannaCodeDialog, @FireWire and his Fluency Translation... Please, please))

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 ?

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.

You can enable that in the field's settings on the "input" tab.

@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.

Just tried out ddev for the first time and it looks like it is working really well. Thanks @bernhard and others for contributing to this thread. Ddev looks way easier then my previous setup based on homebrew https://getgrav.org/blog/macos-monterey-apache-multiple-php-versions. Here's the steps I had to take to get started with ddev. I'm writing it here so that other people don't have to spend much time with this. `ddev config` - Choose `php` project. Docroot location = `wwwroot` and let it create the folder `git clone --branch dev https://github.com/processwire/processwire.git wwwroot` - Downloads the latest PW dev branch into the 'wwwroot' directory `ddev start` and open the site's url. It will look something like https://pwtest.ddev.site/ Go through Processwire Installer and enter the configurations The Processwire installer might complain about " Unable to determine if Apache mod_rewrite (required by ProcessWire) is installed. On some servers, we may not be able to detect it until your .htaccess file is place. Please click the 'check again' button at the bottom of this screen, if you haven't already." - Just click the "Continue to Next Step" button `ddev describe` - Shows the name, urls, and ports of the running servers Enter the following in the Processwire Installer DB Name = db DB User = db DB Pass = db DB Host = db DB Port = 3306 Character Set = utf8mb4 - if you want emojis? DB Engine = InnoDB Done. Just follow the rest of the prompts to access your site Maybe it could automatically create a site/config-ddev.php that gets automatically included into site/config.php? https://ddev.readthedocs.io/en/stable/users/topics/cms_specific_help/ and https://ddev.readthedocs.io/en/stable/developers/project-types/. Something like: // Automatically generated include for settings managed by ddev. if (file_exists(__DIR__ . '/config-ddev.php') && getenv('IS_DDEV_PROJECT') == 'true') { include __DIR__ . '/config-ddev.php'; } Looks like all of the custom CMS projects are located at https://github.com/drud/ddev/tree/master/pkg/ddevapp After looking at some of the .go files, it looks like it can get a little complex? https://github.com/drud/ddev/blob/master/pkg/ddevapp/drupal.go Oh well. Now it's time to have some fun with ddev and Processwire!

That's great. Can't wait to find a bit of spare time to take it on a test drive. Cool that the module is already on TinyMCE 6.2, as that release comes with a more flexible autocomplete api. This is going to shave a lot of (or almost all of the) JS code from my autocomplete module.

Does anyone sell or offer PW website templates for end users? Is there a market for that like there is for WordPress and other frameworks/CMS ? Envato market comes to mind…

Not really. The difference being that wordpress assumes you are wanting to write a blog, and as such there are a reliable set of core fields and design expectations that are the bare minimum and take into account the minimal technical back-end file structure required to accommodate 'the loop'. The good news is, you don't have to use a template that is that sophisticated for Processwire. ANY HTML template will do - even from an old static website. And since every field is essentially a custom field (like ACF or pods) it takes very little effort to convert an existing static HTML design with slices into a template that Processwire can use. The simplest form for using regular HTML is probably the 'direct output' strategy: https://processwire.com/docs/front-end/output/direct/ To get that sort of simple construction methods for Wordpress quickly you often need to use a tool like Pinegrow that can take a static HTML template and split it up appropriately into the various default template files and structure that Wordpress can accommodate. But it you are already going that far, you may as well develop it yourself.

I might be misunderstanding, but couldn't you do this in the base template...? <?php if ($page->id == 1044 || $page->parent->id == 1044): ?>

@gebeer Interesting. You want to hook WireLog::___save() and recover the type log on arguments(0) ? https://github.com/processwire/processwire/blob/dev/wire/core/WireLog.php#L96-L175

sorry, a typing error: mengtest = menutext ('menutext|title')

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.

@ryan I haven't tested this out yet but from what you are saying (you sound very passionate about the change), I am as excited as you have been to jump in. We start a new build next week and I am going to take the leap as it is going to be merged in the core. The site won't be live for a few months so it will be a good opportunity for us. Just as an early question, one thing my clients always ask for is the ability to embed social media posts or similar, it's the only thing they miss from another CMS which I think you can guess what it is. Is TinyMCE geared up for this as I always found CKE a complete nightmare to manage this? Finally, I am guessing with old sites everything will have to be reconfigured with regards to toolbars/settings? Thats fine, but the core code will obviously have to contain some instructions that CKE is EOL, and some documentation will have to be created. I am sure you have already considered this, but we obviously have A LOT of old sites that will need reconfiguring, and lots that use Combo now as well.

If you know the parent page you can iterate over all the children very easily, even passing in a selector with your mengtest condition. You could try... echo "<ul>"; foreach($page->children('mengtest=...') as $child) { echo "<li><a href='$child->url'>$child->title</a></li>"; } echo "</ul>"; Docs: https://processwire.com/api/ref/page/children/

Just as an update to this topic, I tried out the jQuery load change and unfortunately it didn't work. However, some of the other ideas I had led to results in working with back-end code, and the test page is working OK now. I still need to run some more tests but thought I'd update the thread while I remember it.

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 !!

@kongondo I have a MM field "icons", allowed media types images. When adding an image via "Add Image", the MM modal pops up and shows all files of type image. I'd like to automatically apply a filter (profile) so that only images with tag 'icon' and extension svg are being listed. Otherwise editors have to manually choose a filter each time. "Add Image" issues a request which contains a property "filters". But in the field settings I don't see how I could configure which filters to apply. Is this scenario possible at all?

I noticed in TinyMCE it's also possible to have predefined HTML templates for snippets of markup which sounds neat. I can't think of any obvious uses right now and HannaCode is likely more powerful for this, but it does make me wonder if there's a way of combining it with HannaCode so that inserting a HannaCode could also show you what the markup would look like: https://www.tiny.cloud/docs/tinymce/6/template/ ? From what I can see it only inserts parsed HTML so without a way of wrapping it in some sort of ID/data attribute that could be problematic.