Jump to content

ryan

Administrators
 View Profile  See their activity

  • Posts

    16,705

  • Joined

  • Last visited

  • Days Won

    1,514

 Content Type 

Everything posted by ryan

  1. ryan
    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/
  2. ryan
    @Joss The utf8mb3 listed on your field_article_text table is the same thing as utf8 I think (utf8 is 3 bytes), so that won't support emojis. Check in your /site/config.php file and look for $config->dbCharset and change it to this: $config->dbCharset = 'utf8mb4'; Then try creating a new Textarea field that uses TinyMCE. It should now use that utf8mb4 charset, and emojis should work. If you want to convert your existing field_article_text field, you'll want to export the table and all its data (with phpmyadmin), then edit the resulting SQL file/dump, change the "CHARSET=utf8mb3" to "CHARSET=utf8mb4". Then import to replace the old table. If you get an error, change the KEY length "250" for that data_exact key in the CREATE TABLE statement to "191".
  3. ryan
    @Joss Good to see you here! Lots of emoji/emoticons require 4 bytes and thus the UTF8MB4 database charset. This is something you can select at install time. You can also convert an existing DB to use it too, but I think you have to export the SQL, create a new DB and import it, replacing any "charset=utf8" with "charset=utf8mb4" in the SQL dump. This DB charset is needed whether using TinyMCE or any other kind of text field, if you want the emojis support. Though if you are already using utf8mb4, let me know, as it's always possible there's a bug I need to resolve too. Btw also check out TextformatterEmoji https://processwire.com/modules/textformatter-emoji/
  4. ryan
    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!
  5. ryan
    @gebeer The period "." is an allowed character in page names, so it's fine to have URLs ending with ".html" ... you would just make the page name end with ".html". You'd probably want to turn off trailing slashes for the templates used by those pages as well. If all URLs end with "index.html" then ProcessWire will take care of those redirects for you automatically, i.e. "/about/index.html" automatically redirects to "/about/" (unless there is literally a page named /about/index.html). If you want to migrate away from using the .html extension, converting things like /about.html to /about/ throughout the site, then it could be done with a redirect rule in the .htaccess file. If you want to have PW respond to either /about.html or /about/ in the same way, then the most direct way might be to add a $_SERVER['REQUEST_URI'] = str_replace('.html', '/', $_SERVER['REQUEST_URI']); at the top of your /index.php file. Though make sure you've got a <link rel="canonical" ... /> tag in your <head> so that search engines don't consider the about.html and /about/ two different URLs.
  6. ryan
    This week we've got a new core version on the dev branch, version 3.0.208. This version includes 15 new commits with a combination of issue resolutions and new features. See the dev branch commit log for full details. In addition, we have new versions of the following ProFields modules: FieldtypeTable, FieldtypeTextareas, FieldtypeMultiplier and FieldtypeFunctional. (Last week a new version of FieldtypeCombo was released as well). These are all posted in the ProFields downloads thread. These versions all add support for the new InputfieldTinyMCE module, in addition to other regular improvements and updates. I think that completes the list of modules I've developed that needed an update to support InputfieldTinyMCE. Speaking of InputfieldTinyMCE, it also received updates this week, primarily focused on resolving reported issues. Thanks for reading and have a great weekend!
  7. ryan
    Just a quick update this week, as yesterday was a holiday here and it becomes kind of a holiday week with kids out of school. On the core dev branch, the built-in PageFrontEdit module has been updated to support the new InputfieldTinyMCE rich text editor module. In addition. The $sanitizer->email() method has been updated with several new options. These include support for emails with Internationalized Domain Names (IDNs), UTF-8 local parts and an option to validate the DNS of the email domain. Currently all of these options are off by default but can be enabled with a new $options argument. These options will likely be translated to configure options for email fields (FieldtypeEmail) in the next week or so. In addition, a new version of the ProFields Combo has been released and this version also adds support for the new InputfieldTinyMCE module. I'm also working on updates for ProFields Table and Textareas for support of InputfieldTinyMCE as well, but those updates aren't quite ready to post just yet. If you opt to use TinyMCE with PageFrontEdit or Combo, make sure you grab the latest version of InputfieldTinyMCE, as it also received related updates this week. Thanks for reading and have a great weekend!
  8. ryan
    @bernhardI just haven't gotten to it yet, as it requires a PageFrontEdit module update rather than a TinyMCE one. I also have to update ProFields Table, Multiplier, Textareas and Combo to support TinyMCE. Once all of these are done we'll merge the TinyMCE module into the core.
  9. ryan
    This week I've been focused on a client project, building out this Reviews section (still a work in progress). There's a few hundred URLs within it, but it's just one page/template. The reviews are via ProcessWire's core comments (FieldtypeComments) field and primarily uses the FieldtypeComments find() method for filtering and sorting of comments/reviews. On this same site, this week Pete launched this very nice blog called Tailwinds, which he told me is using Tailwind CSS (and powered by ProcessWire). The name of the blog (Tailwinds) actually precedes the use of Tailwind CSS, but if you've got a blog named Tailwinds, Tailwind CSS certainly seems like the appropriate framework. ? On the core dev branch we've had a few commits resolving issues and minor improvements, but not enough for another version bump this week. Have a great weekend!
  10. ryan
    Wow nice work @BitPoet!
  11. ryan
    This week the ProcessWire core version on the dev branch has been bumped to 3.0.207. Relative to the previous version, there are several minor issue resolutions and improvements (commit log). I also recommend this version if you are testing out the InputfieldTinyMCE module, which will likely be merged into the core near the end of the year. Speaking of that module, it also received updates this week with the biggest being the addition of improved lazy loading modules for the Normal (non-inline) editor. Rich text editors are one of the most heavyweight input types you can use, so not having to initialize them all during page load is a major performance benefit, especially when you've got multiple fields using them at the same time. With these new lazy-loading modes, the Normal editor has many of the benefits of the Inline editor in terms of page editor performance, but without any of the drawbacks. The new default setting is to "load editor when it becomes visible". This ensures that resources aren't spent loading editors that are hidden behind editor tabs, fieldsets or language tabs, until they are needed. The other lazy-loading option ("load editor when clicked") is the most aggressive lazy loading option. It shows a preview of the editor content but doesn't actually load TinyMCE until you click the preview to edit it. Lastly, I've also been working on a new module (WireSitemapXML) that generates sitemap.xml output, but in a way that I think is more configurable than the other modules available for it. It also supports multi-language sitemaps, URL segments, various hooks and more. While I've got it in use already, I'm going to spend more time on the documentation before releasing it. That's all for this week, have a great weekend!
  12. ryan
    @jacmaes To remove all in an existing parent (i.e. Align), you can add: #Align { display: none } To add custom styles at the root level, omit a #Parent. So to add "Red text" at the root level, add: span.red-text { color: red } /* Red Text */ To add your own custom parent at the root level, specify it as the #Parent for any items you want to add within it, i.e. here's how we add a parent named "Hello": #Hello span.blue-text { color: blue } /* Blue Text */ #Hello p.outline { padding: 20px; border: 1px dotted #ccc } /* Outline paragraph */ I prefer the single line rules, but it's also fine if you want to use multi-line rules: #Hello p.outline { /* Outline paragraph */ padding: 20px; border: 1px dotted #ccc; }
  13. ryan
    @jacmaes If you want to replace the entire styles menu on your own, you can do this with the custom JSON option (whether input or file). See the included defaults.json file "style_formats" item. But it sounds like you just want to remove a few things from the Styles dropdown. In that case, in your Module settings (or Field settings if enabled) edit the "Custom style formats CSS". The instructions there tell you how to add or remove items, but for the specific examples that you want to remove, enter this: #Align { display:none } #Blocks (Pre) { display: none } #Inline (Underline) { display: none } #Inline (Strikethrough) { display: none } #Inline (Code) { display: none } Note this option to remove items in this manner was added within the last week, so make sure you are running the latest version. Regarding the align options, I'm thinking we may just remove those since not many seem to want them, and our image plugin (pwimage) already includes the ability to assign alignment classes to images. For the Blocks tool, I think that is unrelated to the Styles tool in terms of configuration, and I don't think that it is a replacement for the Styles tool. I have built most of our configurable settings around the Styles tool since it offers a lot more flexibility in configuration. But if you want to investigate the Blocks tool further, it can be configured with the block_formats setting specified in custom JSON (input or file). What I would probably recommend instead of the Blocks tool is just to configure the Styles tool with exactly what you want. Keep in mind the parents (Blocks, Inline, etc.) are optional and you can add options to the root level if you prefer it, or create your own Parents within it.
  14. ryan
    This week I've worked through a few minor issue reports in both the core (ProcessWire) and InputfieldTinyMCE repositories. In addition, a new version of InputfieldTinyMCE was released that includes various improvements. We'll likely go through a few minor versions of this module before it is added to the core. I recommend downloading the latest posted version (6.0.3). Thanks to all that have been helping to test and report issues as they come up. I'm going to give the core another week or so of updates before we bump to the next version there. If you've recently launched any new sites, please add them to our sites directory at processwire.com/sites/submit/ when you have a moment. And if you aren't already subscribed to the ProcessWire Weekly updates email be sure to subscribe. Thanks and have a great weekend!
  15. ryan
    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).
  16. ryan
    @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.
  17. ryan
    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!
  18. ryan
    @Violet Thanks for the great feedback, I appreciate it! @markus_blue_tomato Yes, I actually find TinyMCE 6 quite a bit easier to extend than CKEditor 4. For instance, here's how you could add a "hello" button to the toolbar: InputfieldTinyMCE.onSetup(function(editor) { editor.ui.registry.addButton('hello', { icon: 'user', text: 'Hello', onAction: function() { editor.insertContent('Hello World!') } }); }); Then you would edit your toolbar in the field config and type "hello" to it to any toolbars you wanted. Then every time you click the "hello" button on the toolbar, it would insert the text "Hello World" at the cursor.
  19. ryan
    @bernhard I'm not sure I know why that issue occurs in CKEditor, but I don't see any reason why the issue should exist in TinyMCE. I'm sure there's also a way around it in CKEditor, though I don't understand the issue well enough yet to suggest something. Most (maybe all) of the TinyMCE settings should lend themselves very well to context. The way I've got it setup currently is that it maintains all the settings (that differ from the defaults), namespaced by field name in ProcessWire.config.InputfieldTinyMCE.settings. Then any field-template context settings (that differ from the field settings) are in data attributes on the Inputfield. Field settings override defaults, then template-context settings override those. InputfieldCKEditor settings work in a similar way, but with less efficiency (all settings bundled rather than just those that override defaults), and it doesn't have the option for the data attribute override settings. Hopefully TinyMCE will work for the context you mention but let me know if not, I'm sure we'll be able to figure it out.
  20. ryan
    Lots of good guesses! Here's all the details: https://processwire.com/blog/posts/new-rte-for-pw/
  21. ryan
    This week we take a look at a new rich text editor for ProcessWire, why we chose it, some highlights, screenshots, and why we think you’ll like it— https://processwire.com/blog/posts/new-rte-for-pw/
  22. ryan
    @Pixrael I have in the past, though they've never had a compatible license. They make great stuff. But for things like this I tend to stick to things that have a GitHub repo and compatible license. I've always seen Redactor as something that would be good for a 3rd party module rather than a core inclusion.
  23. ryan
    With 2023 fast approaching, and CKEditor 4 having an EOL in 2023, I'm starting to feel a little pressure to get a plan in place. But is the replacement (CKEditor 5) the best path forward? https://processwire.com/blog/posts/reconsidering-the-ckeditor-5-upgrade/
  24. ryan
    @Pete Oops, looks like I neglected to push the final "bump version" commit. Just pushed it and the version number should update within a day. Thanks.
  25. ryan
    @bernhard Not really. This sort of thing would be simple on some fields but very difficult on others. For instance, text fields, numbers, etc... very simple. But for any field that stores data beyond the field_* table (Repeaters, Files/images, PageTable, etc.) it would be difficult to achieve and to maintain. The only way to do it reliably across all Fieldtypes would be is if each Fieldtype implemented the ability on its own (through some base Fieldtype provided interface, which we may add at some point). That's because individual Fieldtype modules are the the only authority on how and where their data is stored. Granted, the vast majority of Fieldtypes just store data in their field_* table, keeping it simple, but it's those more complex ones (repeaters, files, etc.) that are the primary obstacle to some undo or version feature that works the same across all fields. It's one of the reasons I gave up on developing the Snapshots module, which I spent weeks on before realizing such features are not sustainable for complex Fieldtypes until it becomes part of the Fieldtype interface.
×
×
  • Create New...