Leaderboard

I have to stop a day early to leave town for one of my daughter's gymnastics meets, so I'm going to save the core version bump for next week, after a few more updates. The most interesting core update this week is one suggested by Netcarver and Pete. It is to make the "HTML Entity Encoder" Textformatter option (for text fields) more foolproof, by making it harder to ignore. That's because this option is rather important for the quality assurance and security of your site's output. If you forget to enable it for one text field or another, then you allow for the potential of HTML in the output for that field, by anyone that can edit pages using that field. Most of the time when you aren't entity-encoding output, HTML is exactly what you want, such as with TinyMCE or CKEditor fields. HTML entity encoding is necessary when the field value isn't itself HTML, but will eventually be used in HTML output and needs to be valid for HTML output. Think of a "title" field, for example. For these cases, you want to be sure that characters like greater than, less than, ampersand and single/double quotes are properly encoded. Greater-than and less-than characters form HTML tags like <script>alert("gotcha!")</script>, ampersands begin entity sequences, and quotes are used to open and close HTML attribute values. By entity encoding all of these characters, we ensure they can't be used for malfeasance, scripts, XSS, defacement, etc. The worst case scenario would be that you neglect to enable the entity encoding on a text field where you are allowing non-trusted user input, as that could open the door to such shenanigans. To make things more foolproof, ProcessWire now gets in your face a bit more about using the HTML Entity Encoder. Maybe it's a bit more annoying for more experienced users, but if you happen to be in a rush, it'll make sure you at least don't forget about it. Or maybe some less experienced developers might not know the importance of entity encoding in HTML, and this update helps them too. Here's what it does: It now enables the HTML Entity Encoder (Textformatter) for all newly created text fields (and derived field types). Previously it just suggested that you enable it, but let you decide whether or not it was appropriate. Now, it errs more on the side of caution. Since the entity encoder is now automatically enabled for newly created text fields (in the admin), it seemed necessary to detect cases where the field configuration clearly indicates it's intended to allow HTML (by input type or content-type). Examples include textarea fields configured to use TinyMCE or CKEditor, or any text field with a content-type set to HTML. When these cases are detected, it advises the user to remove the HTML Entity Encoder from the selected Textformatters. If editing an existing text field (in Setup > Fields) that doesn't appear intended to use HTML (i.e. not TinyMCE or CKEditor and doesn't have its Content-Type set to HTML), it will now test all the selected Textformatters you have selected (if any) and see how they handle HTML. If they leave HTML in place, or you have no Textformatters selected, It will provide a warning to you, letting you know that HTML is allowed, and leave it up you to decide whether that's what you want. Note that these additions are only for fields created in the admin. Fields created from the API make no such assumptions and work the same as before. That's it for this week. More updates and hopefully a version bump next week. Have a great weekend!

I wanted to share this tip which I'm going to implement on Transferware Collectors Club Database. That site has a form which is a set of filters. It takes many queries to build that form and all of its options and as a result, it takes over 5 seconds to load the page. ProCache is out of the question because using a full page cache on a site like that doesn't make sense, but caching various areas with WireCache $cache does. The form is developed in a way where it will automatically populate/select the various form fields based on what it reads from the URL. So going to /?color=123 will automatically check the appropriate radio button for that color. Therefore, when using $cache to cache the form (or parts of the form), we need to cache the form in a clean, unpopulated state. The problem then becomes how do we use the cached form but also populate the fields accordingly based on the URL variables? Markup regions can do this. Assuming we had a set of radio options coming from our WireCache'd form like this: ... <input type="radio" name="color" id="color-123" value="123"> Red <input type="radio" name="color" id="color-124" value="124"> Blue ... We could devise some code that also outputs this on our page: <region pw-replace="color-123" checked></region> Markup regions will then "check" that radio. Perhaps this isn't mind blowing, but I've never thought of using Markup Regions in this way.

There is a $config setting that lets you specify roles that are not allowed to log in. /** * Names (string) or IDs (int) of roles that are not allowed to login * * Note that you must create these roles yourself in the admin. When a user has * one of these named roles, $session->login() will not accept a login from them. * This affects the admin login form and any other login forms that use ProcessWire’s * session system. * * The default value specifies a role name of "login-disabled", meaning if you create * a role with that name, and assign it to a user, that user will no longer be able * to login. * * @var array * */ $config->loginDisabledRoles = array( 'login-disabled' ); So in /site/config.php you could temporarily have something like: $config->loginDisabledRoles = ['your-role-name'];

I’m gonna say Virtual Parents?

TextformatterRockDown ProcessWire Textformatter for simple mardown-like text formatting ideal for headlines: *bold* _italic_ ~strike~ ```monospace``` #monospace# This module does intentionally not support full markdown syntax! It is intended to be used for simple formattings that you usually want to apply to headlines. Problem The title field is always available in ProcessWire and it is often used for page headlines. But unfortunately when using such a plain textfield it will not be possible to print some words in bold or italic font. One solution is to create a CKEditor/TinyMCE field, but it's a lot more tedious to setup. Also it's not easy to make it single-line-only. Solution Just apply this textformatter to your field and you'll get quick and easy headlines with bold and italic fonts that will also work with frontend editing. Backend Editing: Frontend Editing: Formatted: Custom tags You can add custom replacements easily via hook in /site/ready.php $wire->addHookAfter("TextformatterRockDown::replace", function ($event) { $str = $event->arguments(0); $start = $event->arguments(1); $end = $event->arguments(2); $str = preg_replace("/$start@(.*?)@$end/", "$1<span style=\"color:red;\">$2</span>$3", $str); $event->return = $str; }); Download https://github.com/baumrock/TextformatterRockDown https://processwire.com/modules/textformatter-rock-down/

Hello all, I have released RockFrontendTailwind, an extension module for RockFrontend. It extends Bernhard's module and adds an installation profile for site development with Tailwind CSS. Obviously RockFrontend is a required dependency for my module to work. This module aims to give you a quick start with a Tailwind based project. What RockFrontendTailwind does: A folder "rockfrontendtailwind" will be installed in site/templates. That folder contains all the configuration files needed to get you started with a webpack-based build pipeline for JS and CSS with webpack tailwindcss postcss with postcss-preset-env (for autoprefixing) babel (for transpiling) So rather than just building the CSS with Tailwind, the build pipeline also takes care of transpiling your Javascript based on configuration in a .browserslist file. Of course, the setup is opinionated. But people who are comfortable working with webpack can easily adjust / extend the configuration to their liking. The default configuration watches your JS and CSS files and compiles them into site/templates/assets main.css and main.js by default. All paths are configurable through a .env file. Live reloading during development is not part of the webpack configuration since this is handled by RockFrontend already in a very efficient way. Also a _main.php file including a very basic boilerplate for a typical setup will be placed insite/templates. It includes examples on how to render your JS and CSS assets. More detailed instructions over at github. Adding new profiles to RockFrontend through your own modules is quite straight forward thanks to the clear structure in @bernhard's module. RockFrontendTailwind can serve as a boilerplate. The only important thing is that the "profiles" folder structure remains the same. The module is currently in beta but runs very stable. It will eventually be released as an official module in the directory soon. If you want to give it a shot, I shall be happy to hear your feedback. If you are looking for a standalone webpack build pipeline with webpack-dev-server, you might want to have a look at https://github.com/gebeer/tailwind-css-webpack-processwire-starter Happy Coding!

I have setup a starter kit for developing PW sites with Tailwind CSS. You can find it at https://github.com/gebeer/tailwind-css-webpack-processwire-starter I know, I'm a bit late to the party with Tailwind. In fact I only discovered it a couple of months ago and found it to be a very interesting concept. It took quite some time to get a pure webpack/postcss/tailwind setup that features live reloading dev server, cache busting, supports babel as well as autoprefixing and works well with PW. For the cache busting part I developed a small helper module that utilizes webpack.manifest.json to always load the assets with the correct file hashes for cache busting. No more timestamps, version numbers or the like required. The little helper can be found at https://github.com/gebeer/WebpackAssets Having used it for the first time in production on a client project I have to say that I really enjoy working with Tailwind. The concept of using utility classes only really convinced me after having put it to practice. During the work on the client project, some quirks with webpack-dev-server came to surface. I was able to solve them with the help of a colleague and now it is running quite stable in both Linux and Mac environments. I am fascinated by the fast build times compared to using webpack/gulp or gulp/sass. Also the small file size of the compiled CSS is remarkable compared to other frameworks. So this will be my goto setup whenever I am free to choose the frontend framework for a project. If anyone feels like they want to give it a try, I shall be happy to get your feedback

I've been working with sqlite on an embedded project for the last few years, though not using the FTS. It's generally faster than client/server databases just by the nature of its implementation. It also hardly suffers from N+1 queries and other common pitfalls. It would certainly be interesting to see how it could work beneight processwire, but really sqlite is a different beast with a lot of different tradeoffs to other databases, even if many people (looking at laravel or rails using sqlite for tests) think switching databases doesn't come with costs.

Thx @Jozsef here you go: https://github.com/baumrock/TextformatterRockDown#usage ?

Not the only thing broken, I think. All recent topics seem to be showing ‘0 views’ even though there are replies.

Thanks Bernhard, I'll try it in my next project. I did the exact same thing in most past projects, a headline text field in the format of *Bold Text* in the headline. As wbmnfktr I used the core markdown textformatter but in the template file I had to strip all tags apart from <em>. It was necessary because the core formatter adds paragraph tags around the headline that doesn't play well inside heading tags. Another negative about this approach is that I can't use front end editing. Your readme doesn't say anything about usage, does that mean I can just simply output the text field as $page->headline ? Or even $page->edit("headline")?

@olafgleba Thx for the explanation, I understand now. And as far as I understand hooking Session:loginSuccess is not 100% sufficient. What if a user is already logged in when you add the hook? I think the user will not get redirected in that case and will still be able to work in the backend. Maybe hooking before Page::render would be better and if the user is not a superuser redirect him/her somewhere else: $wire->addHookBefore("Page::render", function (HookEvent $event) { $page = $event->object; if ($this->wire->user->isSuperuser()) return; if ($page->template != 'admin') return; $this->wire->session->redirect('/maintenance'); });

I actually always use Google to search the forum ? just add "site:processwire.com/talk" Example:

@wbmnfktr, thank you, it indeed works.

@Markus Thomas Thanks a lot, that indeed is simple with no overhead ?

For me a click on Home (root) does the trick.

www.herzschlag-der-erde.de made with love and Processwire ???

how friendly is the processwire community?

Hello all, Since https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ came out, I used to implement custom page classes as modules, following the principles described in that tutorial. Now only a few weeks ago I stumbled across https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes. This seems to me a much cleaner and easier way of implementation. Though it restricts the naming of custom classes to the naming conventions for the class loader. Other than that I can't really see any more disadvantages. Which way do you prefer and why? On a side note, useful features like described in the second link often can only be found in @ryans core update blog posts. If you don't read them on a regular basis, those new features are easy to miss. I'd love to see those hidden gems find their way into the API reference in more detail. Although $config->usePageClasses is documented at https://processwire.com/api/ref/config/, I think it would deserve its own page with all the explanations from the blog post.

Adapting a post Ryan made in the Repeater Matrix support forum: In /site/templates/admin.php, before the line... require($config->paths->core . "admin.php"); ...add the following... if($page->process == 'ProcessPageEditImageSelect') { // The page ID that is open in Page Edit $edited_page_id = (int) $input->get->edit_page_id; // The page ID that contains the CKEditor field // This is where PW will look for images by default $cke_page_id = (int) $input->get->id; // If the edited page is not the same as the CKEditor page if($edited_page_id && $cke_page_id && $edited_page_id != $cke_page_id) { // Get the CKEditor page $cke_page = $pages->get($cke_page_id); // If the CKEditor page is a particular Repeater field page // Substitute the name of your Repeater template if($cke_page->template == 'repeater_your_repeater_template') { // Set the page ID where you want PW to look for images $input->get->id = $edited_page_id; } } }