Leaderboard

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/

My first reaction: Seriously?! TinyMCE reminded me of my old and awful Joomla days ? Then: Ok... that looks nice... Ok... very nice... Ok... that looks great!! Thank you Ryan for all your great work! Looking forward to using it soon ? Let's show our love to TinyMCE and star the project on Github https://github.com/tinymce/tinymce Congrats, you are the winner ?

Lots of good guesses! Here's all the details: https://processwire.com/blog/posts/new-rte-for-pw/

The module originated from an idea/discussion in this thread. I hope that helps to see more PRs for improving the PW backend ? https://github.com/baumrock/Scss Watch core files When working on PRs for the ProcessWire backend you'll notice that the core ships with several SCSS files and the corresponding CSS files. To make it easy to work on the SCSS files without the need of adding complicated build tools to your project you can simply install the Scss module and add the following in /site/ready.php $modules->get('Scss')->watchCore(); Now your SCSS files will be watched for changes and once you change something and reload your page you'll get the new CSS on the fly and can commit both changes ?

My first thought was that URL hooks might help: https://processwire.com/blog/posts/pw-3.0.173/ my second thought is that if your aim is to improve search rankings then I'm not convinced that this is really going to improve things (and indeed might even make thing worse). Having a concise URL is good for humans but I bet Google doesn't care and may even prefer longer URLs. Looking at the site I bet your time would be better spent optimising performance; if you can bump up that Lighthouse score for page speed I bet that would make much more of a difference than tweaking URLs. Great looking pictures though.

I think perhaps you missed the point of my earlier post: When you use this approach you don't need a different URL to the regular one. If a non-logged-in visitor tries to view a page that you must be logged in to view then they get redirected to your custom login form and the ID of the page they tried to view is preserved in a GET variable (you could use a URL segment to hold the ID instead of a GET variable but I can't see a reason why that would be preferable). So let's say I try to view a restricted page at https://www.websitedomain.com/articles/i-love-processwire/ It doesn't matter how I got the URL - it could have been in an email, or a browser bookmark, or whatever. If I'm not logged in when I try to view it and the page template is configured like I showed in my earlier post then I'm automatically redirected to https://www.websitedomain.com/my-login-page/?return=1234 And if the hooks I showed are in ready.php then after I login I'm automatically returned to https://www.websitedomain.com/articles/i-love-processwire/

Bro, I feel very sad for you in term of having fun while developing (working). I feel lucky to be one of those guys who can refuse tasks that should be done on these pieces of software mentioned above, even more when you worked with ProcessWire. However, it is true that you have to take into account an "architecture" already in place. Bosses are "afraid" of change that concerns the backbone of their business, especially when it works as is. What I would do personally, - it also depends on the "size" of the internal architecture and context - would be to rewrite the mess under processwire in your spare time and give them a demonstration of why and how it's better, with arguments about the added value in terms of maintaining and possible future hiring of developer(s). I think it's easier and safer to hire "pure" developers rather than "closed and trained" developers on a given CMS (multi-skilled). I mean there, a pure PHP developer can jump on ProcessWire, where like a guy like me, can't take the other the opposite way. "courage brother"..

Wow! Thank you Ryan! ? I read the post and am already drooling over the upcoming editor and its features. If this seems a bit extreme, I should mention that what prompted me to move to ProcessWire (from Wordpress) was the switch to the Gutenberg editor in Wordpress - it was a definite downgrade upon their previous editor, it simply wouldn't let me type my content in as quickly. After moving to ProcessWire I quickly reaped the rewards of its editor and in addition, all the other advantageous features of ProcessWire. As a blogger who owns multiple sites I am constantly writing articles and therefore the choice of editor is extremely important to me. I am crying tears of joy over the stickybars feature in the new editor ? No more need for scrolling up just to get to the editor buttons again, yay!! I was also thrilled to see that we'll still be able to get spellcheck and wordcount on the new text editor - essential features. And retaining the ability to edit the text as source code is a must-have for those of us who are including affiliate links or ad code in our articles, thank you for ensuring that continues to be provided. The configurability of everything via toolbars and plugins looks great. I'm excited that we can add an undo button on the toolbar (maybe we could do that on the current editor too but if so I never figured it out ?) Thank you for the thorough explanation and all the screenshots, it's very helpful to see what we will be getting. I am very excited about the new editor and am looking forward to using it!

Just use $urls->httpRoot https://processwire.com/api/ref/paths/

hi, the pw way on top of a page $input->urlSegment1 you can use various functions to check if there is one or no, for example if ( strlen($input->urlSegment1)) $foo = ... and of course validate if the segment is an authorized one, regex for example, beginning with the segment you accept in the model parameters (i nearly always use regex, i.e regex:^[0-9]{1,5}$ //or 6,7... depending on how many pages you'll have :) that will check the segment looks like a page id, if not, 404... now, coming to hooks, never did this, il let @Robin S answer this, he knows pw and hooks far better than i do ? have a nice day

Sounds like an incomplete upload (with FieldtypeFile.module being an older version that lacks those method implementations, otherwise FieldtypeImage would inherit them).

Hi, @Robin S is right, my url segment idea is not necessary but just a simple way to keep the page id alive ? now, honestly, when i have to do what you described, as much as i love coding, hooks and all what pw gives us i would probably use session vars the way @Robin S shows in the hook but simply in the login page code, maybe because i'm too used to doing this kind of thing without the help of pw... - if the user arrives unlogged on the page, i would set a session var with the id of the page and then redirect to the login page (instead of login/pageid that doesn't need this session var) - if the login is successful, simply use pw redirection abilitiy to the page the id is in the session destroying the var that isn't useful anymore but using the login/register plugin @Robin S's hook is more the pw way of working than my savage 'manage your life on your own' solution ? have a nice day

@kongondo Referring to your post in Media Manager thread, do you think that JqueryFileupload will receive further updates? Just asking so I can decide whether I should fork it and potentially make PRs.

This is exactly what creates the upgrading problem that Ryan is trying to avoid, since data is in HTML already in all processwire installs.

Being able to download full-scale images, including SVG's, directly from an admin->page-edit->images field via a single click on an icon would be a great feature

So, after 5+ years of being a ProcessWire dev, I've bagged my first multi-lang project. Be prepared for questions ?

@kongondoits been a while sorry. so i just added language english and switched my user profile to it. and .... it works with english. so it is in fact a multilanguage issue. to reproduce -> activate language support. Have only default-language in place and import the translation files: https://processwire.com/modules/german/ EDIT: Additional info. Once i had a property on the product, set my profile to german again, edited the same product, the search works fine for the existing property. But when adding another one, it does not work on the new one. So very specifically, it does not work on newly added property-line when the language is not english.

As for direct statement about financial advantages I cannot provide anything (thought I remember reading something related to it) but I do infer such a thing from this comment, for example: https://processwire.com/talk/topic/2043-drupal-vs-processwire/?do=findComment&comment=19084 Quote: "The problems with Drupal have certainly been a motivation in making ProcessWire happen. Out of the box, ProcessWire is going to be a lot better at the large scale than Drupal. ProcessWire's architecture, foundation and API are far better than Drupal (captain obvious)." Well, while writing this, I actually remember reading somewhere that he wrote that his previous way of doing business (when still using Drupal perhaps) was more profitable than the current one based on ProcessWire, but that is not just about working with PW vs Drupal but as business as general. Maybe we should ask @ryan itself? Anyway, as an addition to the actual topic: This might also help @3fingers when explaining the benefits: https://processwire.com/talk/topic/4426-pushing-pw-in-web-design-agencies/

I guess we're going back to TinyMCE)))

I don't know if anyone pm'd you already but it can be quite simple if you only need to generate a static svg from a text input. I found this library https://github.com/kartsims/easysvg which would allow you to do it all server-wise if you have .svg font files at hand. My approach would be to have a file input for the font file, a text input for the text you want to generate the svg from, a textarea (closed by default and non-editable) to hold the svg code, and something like https://processwire.com/modules/inputfield-runtime-only/ to echo the textarea's content (the svg) as a preview. Basically a hook in `ready.php`: require "/path/to/easySVG.php"; wire()->addHookBefore("Pages::saveReady", function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); if($page->template->name !== "font") return; // or whatever if(!$page->fontfile && !$page->text) return; // file and text inputs // copy/pasting from easySVG example $svg = new EasySVG(); $svg->setFontSVG($page->fontfile->url); $svg->setFontSize(100); $svg->setFontColor('#000000'); $svg->setLineHeight(1.2); $svg->setLetterSpacing(.1); $svg->setUseKerning(true); $svg->addText($page->text); list($textWidth, $textHeight) = $svg->textDimensions($page->text); $svg->addAttribute("width", $textWidth."px"); $svg->addAttribute("height", $textHeight."px"); $page->svgcode = $svg->asXML(); // textarea input $event->arguments(0, $page); }); And in your `svgpreview` field/file (check RuntimeOnly doc) or template file: echo $page->getUnformatted("svgcode"); (I used getUnformatted in case there are textformatters but it would best if there's none in the field's settings) It's not tested and made on top of my head but I think this might work. (nice to see Velvetyne here btw, I like your work and a good friend of mine made La Savate ?)

Wouldn't that be $wire->files->copy(src, dst); ?

Addition: It turns out that pre-selection doesn't work here in combination with selectors. What I did: I chose a "Default Selected Option" and made the field required. When editing the page, the selected default option is highlighted correctly in the UI and I can echo the values in the frontend – but when using selectors, the value is not considered. If I change the value of the toggle when editing a page, hit save and change it again + save, it works with selectors. Is there an approach to make it work with pre-selection? That would be important in my case.