Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by ryan

  1. This week we've got a few minor issue fixes and a couple of pull request additions on the dev branch. Pull request #251 thanks to @Jan Romero added a download button to the thumbnail images in InputfieldImage. I wasn't sure we really needed that, but really liked his thinking behind it, which was envisioning the ability to add more custom buttons/actions for images. So while I didn't specifically add the download button, I added the proposed system for adding any custom buttons, and then applied that same thinking to some other parts of InputfieldImage. And we'll talk about how to add that Download button here. 🙂 First, let's look at how you might add your own download button, and note we're using this as just an example, as you might add any kind of button this way. A new hookable getImageThumbnailActions() method was added for this purpose. So here's how you might hook it (in /site/ready.php) to add a download button: $wire->addHookAfter('InputfieldImage::getImageThumbnailActions', function(HookEvent $event) { $image = $event->arguments(0); // Pageimage $class = $event->arguments(3); // class to use on all returned actions $a = $event->return; // array $icon = wireIconMarkup('download'); $a['download'] = "<a class='$class' href='$image->url' download>$icon</a>"; $event->return = $a; }); With that hook in place, here's what it looks like when you hover a thumbnail image. And if you click that Download icon, it downloads the file to your computer: or in list mode (download icon appears in right corner next to trash): I was thinking it would be useful to also be able to add custom actions after you click the thumbnail, and it shows the image edit features. So let's add a Download button there instead, by hooking the new getImageEditButtons() method: $wire->addHookAfter('InputfieldImage::getImageEditButtons', function(HookEvent $event) { $image = $event->arguments(0); // Pageimage $class = $event->arguments(3); // class(es) to use on all returned actions $buttons = $event->return; // array, indexed by action name $icon = wireIconMarkup('download'); $buttons['download'] = "<button class='$class'><a download href='$image->url'>$icon Download</a></button>"; $event->return = $buttons; }); And the result looks like this (see new Download button after Variations button): We also have that Actions dropdown that you see in the screenshot above. This is already hookable but we've not had any good examples of it. In this case, you need two hooks: one to add the action to the <select> and another to handle the processing of the action when the page is saved. So in our next example, we'll demonstrate how to display verbose EXIF information about whatever image(s) the action was selected for. In this first hook, we'll add the action to the Actions <select>: // Example of adding an “Get EXIF data” action to the <select> $wire->addHookAfter('InputfieldImage::getFileActions', function(HookEvent $event) { $image = $event->arguments(0); // Pageimage if($image->ext == 'jpg' || $image->ext == 'jpeg') { $actions = $event->return; // array $actions['exif'] = 'Get EXIF data'; $event->return = $actions; } }); And in this next hook, we'll handle the action, which gets called when the page editor form is submitted: // Example of handling an “Get EXIF data” action $wire->addHookAfter('InputfieldImage::processUnknownFileAction', function(HookEvent $event) { $image = $event->arguments(0); $action = $event->arguments(1); if($action === 'exif' && file_exists($image->filename)) { $exif = exif_read_data($image->filename); $event->warning([ "EXIF data for $image->name" => $exif ], 'icon-photo nogroup'); $event->return = true; } }); And here's what it shows after you hit save (for any images that had the action selected): The screenshot above is truncated because it was about twice is big as what's above. All the above code examples are also included in the phpdoc for each of the relevant hookable methods in the InputfieldImage module. For another recent useful addition, be sure to check out ProcessWire Weekly #454 (last week) which covered some new options available for the language translation functions like __text('hello'); where you can now tell it what kind of input type (and how many rows) to use in the admin translation interface, via inline PHP comments. Thanks for reading and I hope you have a great weekend!
  2. This week we've got ProcessWire 3.0.211 on the dev branch. Relative to the current main/master version (3.0.210), this version is 20 commits ahead. Many of the additions are user-submitted pull requests, and there are also several minor issue fixes too. Full details can be found in the dev branch commit log. I'd been planning on merging InputfieldTinyMCE into the core on the dev branch almost right away, but with so many minor fixes and improvements being added (that don't need much testing) we may put out another main/master version first in the short term, and then merge in InputfieldTinyMCE. Thanks for reading and have a great weekend!
  3. Last week we released ProcessWire 3.0.210 main/master and it's been a very smooth launch. No new issues have appeared and all upgrade reports have been good so far. If you haven't yet upgraded I'd encourage you to. Last week's post covered a lot of what's new, in case you haven't seen it yet. Also be sure to check out the ProcessWire Weekly coverage of this new version. This week I've been focused on getting caught up with some client work but there have also been a few minor commits on the dev branch, with more on the way. I hope that you have a great weekend!
  4. 140 commits, 55 resolved issues, dozens of new features, eight contributors, and five new pull requests make yet another great new version of ProcessWire. This week I’m happy to announce another new main/master branch version of ProcessWire, version 3.0.210. Like most main release versions, there is a lot here. This post covers some of the most notable additions and improvements— https://processwire.com/blog/posts/pw-3.0.210/
  5. @teppo This thing is apparently kind of an alpha or beta test, but it seems full of potential and kind of cool to imagine where it's headed when the issues are worked out. At the moment, it's odd and kind of funny with the mistakes that it makes. It seemingly just makes stuff up when it doesn't know the answer to something. It's like it has some kind of creative element to it or something, which made the behavior fascinating. It's completely different from any kind of computer interaction I've had before. I love the fact that it seems to know how to code ProcessWire stuff even if it's prone to mistakes. I've not experimented with AI, machine learning, neural networks, etc., but it makes me want to learn more about it.
  6. Happy New Year! This week we've got ProcessWire 3.0.209 released on the dev branch. Consider this version a release candidate (RC1) for the master/main branch. Relative to 3.0.208, this version contains primarily issue resolutions and minor improvements (commit log). If you have a chance to test it, please let us know if you run into any major issues by reporting them here. So long as no new major issues surface, by this time next week my hope is that we'll have the dev branch merged to the master/main branch for version 3.0.210. This week one of my clients pointed me to https://chat.openai.com/ which is really quite interesting. It's an artificial intelligence that you can chat with, and it knows quite a lot about ProcessWire and how to code in ProcessWire. Though it knows a lot about a lot of different APIs, and actually a lot about everything, not just development related stuff. But I mention it here because of how it appears it's been trained fairly well in ProcessWire. When I asked it for examples of what CMSs it knows how to code for it told me WordPress, Joomla, Drupal and ProcessWire. I'd encourage you to get an OpenAI account to try it out, it can blow your mind. Ask it questions like how to develop a ProcessWire module, how to build a search engine in ProcessWire, how to use pagination in ProcessWire, or anything you can think of. It seems to have an answer for everything. The client that told me about it is currently using it to write AWS scripts for him, and he said it's saving him a lot of development time. What I also find interesting is not just how it seems to have an answer for everything, and that it knows how to code, but also that it makes mistakes pretty regularly, and recognizes those mistakes when you point them out... and apparently learns from them. That's basically how we work. For example, I asked it how to resize an image in ProcessWire and it explained through text and code examples how to use the size() method on image fields. But it also told me that I could use the $options argument to specify the type of resize interpolation (bicubic, linear, nearest, etc.) and ProcessWire has no such option. When I told it that, it apologized and corrected its code example, and also explained more details about the size() method's $options argument. There was another instance where it made a mistake (trying to do a PHP math operation within a string) and I explained that PHP doesn't support that. It essentially said "I know that, but my example doesn't do that". Then I asked it to double check its example because it didn't look right to me, and then it replied (paraphrased) "Oops, sorry, you are right, here's a corrected version." Anyway, it's just kind of funny to me that I'm talking to a computer with these kinds of interactions, and how it seems to "think" and learn a lot like we do. It will be interesting to see where this technology leads. Currently it is a free research preview, where I suppose we are helping to test the AI and help it learn, but it's very interesting and engaging just to talk with it. Also worth noting is that it does not have internet access (other than to chat with people). So it can't go and hunt down information from websites, actually making it that much more impressive in my mind.
  7. @szabesz I'm not sure I've got the ability to develop a code editor for TinyMCE. And I'm also not sure about how many people really need that, as isn't the the main benefit of a rich text editor to be able to not have to code the HTML? (though no doubt it's useful to resolve occasionally issues in the markup). But I do think it would be nice to have something more like Ace than something like Notepad, and the current editor source code popup is more like Notepad. Maybe a way to achieve that would be a toggle that would let you temporarily swap the Input type from TinyMCE to an Ace editor Inputfield or something, it does seem technically possible, though there's probably more to it than that, but interesting to consider.
  8. @bernhard Yes, so far it sounds like that would work. I might be forgetting something, but I will definitely look into adding that, thanks!
  9. @BrendonKoz An attribute definition can either define allowed attributes or allowed values, but not both in the same definition. So you are right that a[href|id] and a[target=_blank] can't be merged into one definition, at the moment; they should be two definitions. You can do a[href|id] but if you preferred it you can also just write them separately: a[href],a[id]. Regarding things like data attributes or wildcards on classes: keep in mind this is just for filtering externally pasted content, and this is not a content filter for the editor itself. So hopefully data attribute and wildcards aren't needed as copied/pasted content. The reason for pastefilter is largely to reduce the pasted content to its roots, the base semantic HTML tags preferably without any attributes (excepting things like an href attribute on an <a> tag). If your need is to allow things like pasting in Font Awesome icon tags and such, then I would suggest just not using the Pastefilter. Either that, or use the code/source editor dialog and paste your tailored markup in there. I see the Pastefilter as being useful for our clients that primarily copy text out of Word (or other editor) and pasting it in. These folks often don't know the difference between paste and paste-as-plain-text, so they can get themselves in trouble, or they can create editor markup that is full of proprietary garbage. Pastefilter helps to prevent that issue. The default configuration of TinyMCE's content filter is a little more open than that of CKEditor's, which I think many people like, but when it comes to externally pasted content, it can be more problematic. So that's where Pastefilter helps out, but it's also completely optional and I'm guessing there will be as many instances where people don't need it as those that do.
  10. Merry Christmas, Happy Hanukkah, and Happy Holidays! The plan is to release a newyear main/master core version. I'm not currently aware of any showstopper issues specific to the current dev branch, but if you are aware of any, please report them in the GitHub issues repo (or reply to an existing issue report), as the dev branch will soon become the master branch. There's not yet a hard deadline, so whether it's end of December or the 1st week of January, we'll have a new release out shortly. The dev branch is very stable right now (likely more stable than the master branch) so it's a good time to get a new version out. I've also been holding off on several larger updates to the dev branch in anticipation of this merge to master and new release, so I've likewise been holding back on any commits that would add more to test. Once we get a new main/master release out there, the dev branch will then get InputfieldTinyMCE merged into it and there will be some JS library updates, along with other larger updates, and those that would need dev branch testing. Thanks for reading and I hope that you have a great holiday weekend and week ahead
  11. 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/
  12. @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".
  13. @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/
  14. 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!
  15. @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.
  16. 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!
  17. 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!
  18. @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.
  19. 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!
  20. 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!
  21. @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; }
  22. @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.
  23. 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!
  24. 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).
  • Create New...