Leaderboard

This week we have ProcessWire 3.0.201 on the dev branch which includes a couple minor fixes but also a couple of useful additions: There are new "Tab" field visibility options available for any field in the page editor. This makes the field display in its own page editor tab. It saves you from having to create a new/separate Tab field just to wrap around an existing field to make it display in a tab. So far I've found it particularly useful with ProFields (Combo, Table, Textareas, RepeaterMatrix) as well as the core Repeater, FieldsetPage and Images fields. For instance, I have a Combo field labeled "SEO" that lets me edit browser_title, meta_description, canonical_url, etc., and now I can add that field to any template and pages using that template have their own "SEO" tab. Sure you could do this before by creating a separate tab field with an "SEO" label, but now it's a lot simpler/faster, as any field can now display as a tab on its own. Like with the other visibility modes, also included are options to make the tab load dynamically on click with ajax or make the value non-editable. You can also optionally specify a label for the tab independently of the field label. This is because usually you want tab labels to be very short (1 word is best) whereas field labels have no such need. Please note that this new Tab option is exclusive to the page editor, and in order to work the field must not already be in a tab. Also added this week is a new $page->getMultiple() method. This method works the same as the $page->get() method except that it lets you retrieve multiple page property/field values at once and returns them in an array. For example: $a = $page->getMultiple([ 'foo', 'bar', 'baz' ]); list($foo, $bar, $baz) = $a; It also accepts a CSV string: $a = $page->getMultiple('foo,bar,baz'); By default it returns a regular PHP array, suitable for using in list() like the first example. But if you want it to return an associative array instead, then specify true as the 2nd argument: $a = $page->getMultiple('foo,bar,baz', true); echo $a['foo']; echo $a['bar']; echo $a['baz']; I find this method useful in reducing the amount of code/lines necessary in many cases, and most often I use it in combination with a PHP list() call, i.e. list($title,$subtitle,$body) = $page->getMultiple('title,subtitle,body'); That's all for this week. Thanks for reading and have a great weekend!

Just released the new version of the german language pack for stable version 3.0.200

By definition, a form isn't "simple" as it's not composed by a simple input that we could copy paste 13 times. A simple form is simple when you have someone have already done all the hard work. Technically speaking, even if the form has 1 field, or 13, you still need to follow some simple rules to handle the form or your future website will get hacked; And not because of the ProcessWire fault. All that to finally say, that the solution shown above are effective, and just require you to read the documentation to follow the implemenation that the author had in mind. Because they are smart and talented, they tackled the same problem you encounter and made their modules simple to use. You can also find some guides in the tutorials section of this forum, but I suggest you to buy without brainstorming the pro module made by Ryan if you are looking for a click / copy / paste solution. About the 12 years old code (which should works without hassle lol thats crazzy every time ?) you will find a lot of other working samples code to copy pasta, I still suggest you to read and understand what you are doing ? ?

Hello Wishbone, "Sending emails is not part of this module" means not that emails cannot be send by the forms createt by this module. It means that sending emails will be done fe by the WireMail class of ProcessWire and not by this module class. This module creates and validates forms - not less or more. After the validation process is finished you can do whatever you want: storing data in the DB, sending emails,.... its up to you and you have to write the code for the action after the validation by yourself. Yes, there seems to be an issue on a Mac environment for the moment, but I was not able to reproduce the error. I only got 2 messages from users which had troubles. One problem could be solved, the other is still there, but I am working on it. If you want to install the module maybe I could help you. Best regards

Hi @neophron I think the findIDs function only returns the IDs of the found pages but not full wire page objects. https://processwire.com/api/ref/pages/find-i-ds/ You should try using: <?php foreach ($pages->findMany('id=1223|1224|1225, sort=-created')->children as $item) : ?> or <?php foreach ($pages->find('id=1223|1224|1225, sort=-created')->children as $item) : ?> Gideon

Today I needed to implement a background image with sources, using the new UIkit Image component implementation: https://getuikit.com/docs/image#picture-sources PageimageSource doesn't do this out of the box, but I found I neat solution, which I thought I'd share: <?php // $bannerImage = Pageimage; preg_match_all('<source\ssrcset="(.*?)"\ssizes="(.*?)"\stype="(.*?)">', $bannerImage->render(), $matches); $sources = []; foreach($matches as $index => $match) { if(!$index) continue; foreach($match as $i => $v) { if(!isset($sources[$i])) { $sources[$i] = []; } $sources[$i][[ 'srcset', 'sizes', 'type', ][$index - 1]] = $v; } } echo '<div class="uk-background-cover" sources="' . $sanitizer->entities(json_encode(array_values($sources))) . '" data-src="' . $bannerImage->url . '" data-uk-img></div>'; This assumes that the render() function is returning a <picture> element. Cheers, Chris

Many members of the community create modules that are very helpful for me and others and offer great support for these modules. We can offer our appreciation with a thanks in a forum post etc.. which is great and gives a feel good factor.. but to create and support modules can take a great deal of time and energy and with this in mind I was thinking how it would be nice if we could show our appreciation by having the opportunity donate beer money to authors of modules that we use. How about if a donate button is displayed on each module page so that donations could be made to the author of the module?

We had a smooth rollout of the new main/master version 3.0.200 last week (read all about it here). If you haven't upgraded yet, consider doing so, this new version is a great upgrade. I'm going to add the 3.0.200 tag shortly after I finish this post, which should trigger other services (like packagist) to upgrade. I've had a new client project in the pipeline that I've been waiting to start till the new main/master version was out, so this week I started that project. Pete and I are working together on it, like we've worked on others before. It involves taking a popular WordPress site and rebuilding it completely in ProcessWire. I've done this a couple times before, but this time it's bigger and broader in scope. I always find the large site conversions to be great learning experiences, as well as great opportunities to show how ProcessWire can achieve many things relative to WordPress, in this case. At this stage, I'm having to spend a lot of time in WordPress just to get familiar with the content, fields, etc., as well as in the theme files (php and twig). The more time I spend in these, the more excited I get about moving it into ProcessWire. For this particular site, moving from WordPress into ProcessWire is going to result in a big boost in efficiency, maintainability, and performance. Part of that is just the nature of PW relative to the nature of WP. But part of it is also that the WP version of the site is kind of a disorganized patchwork of plugins, code files, and 3rd party services, all kind of duct taped together in an undeniably confused, undisciplined and fragile manner. (Though you'd never know it by looking at the front-end of the site, which is quite nice). This has been a common theme among WordPress sites I've dug into. Though to be fair I don't think that's necessarily the fault of WordPress itself. I always enjoy taking a hodgepodge and turning it into an efficient, performant and secure ProcessWire site. I love seeing the difference it makes to clients and their future by taking something perceived as a "necessary liability to run the business", and then turning it into the most trusted asset. I think the same is true for a lot of us here. We love to develop sites because it's an opportunity to make a big difference to our clients… and it's fun. Ironically, if past history is any indicator, I seem to get the most done on the core (and modules) when I'm actively developing a site. Needs just pop up a lot more. I don't know if that'll be the case this time or not, but I do expect to have weeks with lots of core updates and some weeks with no core updates, just depending on where we are in the project. This particular project has to launch phase 1 by sometime in July, which is kind of a tight schedule, and that may slow core updates temporarily, but who knows. I'll share more on this project and what we learn in this WP-to-PW conversion in the coming weeks. Thanks for reading and have a great weekend!

Since you guys asked for it, I'll take a stab at a case study on the development process. Most of the development was done in about a week and a half. I started with the basic profile, but it ended up being something somewhat similar to the Blog profile in terms of how it's structured. Below I'll cover some details on the biggest parts of the project, which included data conversion, the template structure, the front-end development and anything else I can think of. Data Conversion from WordPress to ProcessWire One of the larger parts of the project was converting all of the data over from WordPress to ProcessWire. I wrote a conversion script so that we could re-import as many times as needed since new stories get added to cmscritic.com almost daily. In order to get the data out of WordPress, I queried the WordPress database directly (my local copy of it anyway) to extract what we needed from the tables wp_posts for the blog posts and pages, and then wp_terms, wp_term_relationships, and wp_term_taxonomy for the topics and tags. WordPress stores its TinyMCE text in a state that is something in between text and HTML, with the most obvious thing being that there are no <p> tags present in the wp_posts database. Rather than trying to figure out the full methodology behind that, I just included WP's wp-formatting.php file and ran the wpautop() function on the body text before inserting into ProcessWire. I know a lot of people have bad things to say about WordPress's architecture, but I must admit that the fact that I can just include a single file from WordPress's core without worrying about any other dependencies was a nice situation, at least in this case. In order to keep track of the WordPress pages imported into ProcessWire through repeat imports, I kept a "wpid" field in ProcessWire. That just held the WordPress post ID from the wp_posts table. That way, when importing, I could very easily tell if we needed to create a new page or modify an existing one. Another factor that had to be considered during import was that the site used a lot of "Hana code", which looked like [hana-code-insert name="something" /]. I solved this by making our own version of the Hanna code module, which was posted earlier this week. Here's an abbreviated look at how to import posts from WordPress to ProcessWire: $wpdb = new PDO("mysql:dbname=wp_cmscritic;host=localhost", "root", "root", array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8'")); $posts = wire('pages')->get('/posts/'); $sql = " SELECT * FROM wp_posts WHERE post_type='post' AND post_status='publish' ORDER BY post_date "; $query = $wpdb->prepare($sql); $query->execute(); while($row = $query->fetch(PDO::FETCH_ASSOC)) { $post = $posts->child("wpid=$row[ID]"); // do we already have this post? if(!$post->id) { // create a new post $post = new Page(); $post->template = 'post'; $post->parent = $posts; echo "Creating new post...\n"; } $post->of(false); $post->name = wire('sanitizer')->pageName($row['post_name']); $post->title = $row['post_title']; $post->date = $row['post_date']; $post->summary = $row['post_excerpt']; $post->wpid = $row['ID']; // assign the bodycopy after adding <p> tags // the wpautop() function is from WordPress /wp-includes/wp-formatting.php $post->body = wpautop($row['post_content']); $post->save(); echo "Saved post: $post->path\n"; } What I've left out here is the importing of images, topics, tags, and setting the correct authors for each post. If anyone is interested, I'll be happy to go more in depth on that, but didn't want to overwhelm this message with code. Template File Structure This site makes use of the $config->prependTemplateFile to automatically include the file _init.php before rendering a template file, and $config->appendTemplateFile to automatically include the file _main.php after. So the /site/config.php has this: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; You may recognize this as being the same setup from the Skyscrapers profile. The _init.php includes files containing functions we want to be available to all of our templates, and set default values for the regions we populate: /site/templates/_init.php /** * Include function and hook definition files * */ require_once("./includes/render.php"); require_once("./includes/hooks.php"); /** * Initialize variables populated by templates that get output in _main.php * */ $browserTitle = $page->get('browser_title|title'); $body = "<h1>" . $page->get('headline|title') . "</h1>" . $page->body; $side = ''; $renderMain = true; // whether to include the _main.php file The includes/render.php file that is included above includes several functions for generating markup of navigation and post summaries, or any other shared markup generation functions. Examples are renderPost(), renderNav(), renderTags(). This is similar to the blog.inc file from the Blog profile except that I'm letting these functions generate and return their own markup rather than splitting them into separate view files. I personally find this easier to maintain even if it's not as MVC. The includes/hooks.php sets up any hooks I want to be present for all of my templates. I could have also done this with an autoload module, but found this to just be a little simpler since my hooks were only needed on the front-end. The main hook of interest is one that makes all posts look like they live off the root "/" level rather than "/posts/" (where they actually live). This was in order to keep consistency with the URLs as they were in WordPress, so that the new site would have all the same URL as the old site, without the need for 301 redirects. /site/templates/includes/hooks.php /** * This hook modifies the default behavior of the Page::path function (and thereby Page::url) * * The primary purpose is to redefine blog posts to be accessed at a URL off the root level * rather than under /posts/ (where they actually live). * */ wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'post') { // ensure that pages with template 'post' live off the root rather than '/posts/' $event->replace = true; $event->return = "/$page->name/"; } }); Our /site/templates/_main.php contains the entire markup for the overall template used site wide, from <html> to </html>. It outputs those variables we defined in _init.php in the right places. For example, $body gets output in the <div id='bodycopy'>, $side gets output in the right <aside>, and $browserTitle gets output in the <title> tag. /site/templates/_main.php <?php if($renderMain): ?> <html> <head> <title><?=$browserTitle?></title> </head> <body> <div id='masthead'> // ... </div> <div id='content'> <div id='bodycopy'><?=$body?></div> <aside id='sidebar'><?=$side?></aside> </div> <footer> // ... </footer> </body> </html> <?php endif; ?> We use the rest of the site's template files to simply populate those $body, $side and $browserTitle variables with the contents of the page. As an example, this is an abbreviated version of the /site/templates/post.php template: /site/templates/post.php // functions from /site/templates/includes/render.php $meta = renderMeta($page); $tags = renderTags($page); $authorBox = renderAuthor($page->createdUser); $comments = renderComments($page); $body = " <article class='post post-full'> <header> <h1>$page->title</h1> $meta </header> $page->body $tags $authorBox $comments </article> "; if(count($page->related)) { $side = "<h4>Related Stories</h4>" . renderNav($page->related); } What might also be of interest is the homepage template, as it handles the other part of routing of post URLs since they are living off the root rather than in /posts/. That means the homepage is what is triggering the render of each post: /site/templates/home.php if(strlen($input->urlSegment2)) { // we only accept 1 URL segment here, so 404 if there are any more throw new Wire404Exception(); } else if(strlen($input->urlSegment1)) { // render the blog post named in urlSegment1 $name = $sanitizer->pageName($input->urlSegment1); $post = $pages->get("/posts/")->child("name=$name"); if($post->id) echo $post->render(); else throw new Wire404Exception(); // tell _main.php not to include itself after this $renderMain = false; } else { // regular homepage output $limit = 7; // number of posts to render per page $posts = $pages->find("parent=/posts/, limit=$limit, sort=-date"); $body = renderPosts($posts); } The rest of the site's template files were handled in the same way. Though most were a little simpler than this. Several were simply blank, since the default values populated in _init.php were all that some needed. Front-end development using Foundation 4 The front-end was developed with the Foundation 4 CSS framework. I started with the Foundation blog template and then tweaked the markup and css till I had something that I thought was workable. Then Mike and I sent the _main.php template file back and forth a few times, tweaking and changing it further. There was no formal design process here. It was kind of a photoshop tennis (but in markup and CSS) where we collaborated on it equally, but all under Mike's direction. After a day or two of collaboration, I think we both felt like we had something that was very good for the reader, even if it didn't originate from a design in Photoshop or some other tool like that. I think it helps a lot that Foundation provides a great starting point and lends itself well to fine tuning it the way you want it. I also felt that the mobile-first methodology worked particularly well here. Comments System using Disqus We converted the comments system over to Disqus while the site was still running WordPress. This was done for a few reasons: Disqus comments provide one of the best experiences for the user, in my opinion. They also are platform agnostic, in that we could convert the whole site from WP to PW and not have to change a thing about the comments… no data conversion or importing necessary. Lastly, ProcessWire's built-in comments system is not quite as powerful as WordPress's yet, so I wanted cmscritic.com to get an upgrade in that area rather than anything else, and Disqus is definitely an upgrade from WP's comments. In order to ensure that Disqus could recognize the relations of comment threads to posts, we again made use of that $page->wpid variable that keeps the original WordPress ID, and also relates to the ID used by the Disqus comments. This is only for posts that originated in WordPress, as new posts use a ProcessWire-specific ID.

Don't get me wrong, but these hours would have been better spent on 74€ for a single licence of FormBuilder. No coding required. I own a DEV licence since 2016 and I never think twice about the yearly payment, not even a second! FormBuilder slogan should be: Forms made easy!

@wishbone I fully understand you as non coder as we all try to build things for non-coders, but you also already know that non-coders have also to do a minimum; It wasn't my intention to feel rude (please grab this beer ? ? ) , I was trying to find again a way to say that reading the doc is what could help here. I mean the FormBuilder one, or the tutorial I linked on my previous post. Anyway, back to to your issue. I read the old code you linked, and there is the full code. It works, and if you follow (read again ?) the whole thread lol, you will find the solution for the honeypot technique (page #2 I think posted by @kongondo). About security concerns, there is no breach in the code and can be used as is. But again, without reading the doc, you will eventually get security issues only when you will add more input to the form. I mean here, the $sanitizing technique which give you "control" on the submitted user data. Again, sorry to insist, the FormBuilder module is what you need as non-coder, as I think it doesn't require code to be written, or maybe one line to render the form (I can't confirm, I have to read the doc lol ? ) and give you all the security you will need to stay safe. Code: Try something with the form, and do not hesitate to ask further help here ? Please, believe me, I am speaking by experience, we, coders, are lazy as f***, you can't imagine how ? Edit: Sorry, I didn't paid attention to your third message, you could head to the Job forum to get more attention.

Thanks! Now it works fine ? I'm going to have a look at this »Latte«

Ok, thanks @flydev ??. I'll try to figure out more on Monday. If I do not succeed, I will come back to your generous offer ? Thank you very much for your help!

<?php foreach($pages->find("parent=1223|1224|1225") as $teaser): ?> <a href='<?= $teaser->url; ?>' class='teaser-angebot-wrapper <?= $teaser->parent->select_color->title; ?>'> <section> <h3><?= $teaser->title; ?></h3> <?php if($teaser->parent->id == 1223): ?> <p>Ausstattung: <?= $teaser->textfield_01; ?></p> <?php else: ?> <p>Wo / Wann: <?= $teaser->textfield_02; ?></p> <?php endif; ?> </section> </a> <?php endforeach; ?> I've recently become a huge fan of the latte template engine (by the folks that made tracydebugger) as it produces so much cleaner output in your templates and that would be a perfect example: <a n:foreach="$pages->find('parent=1223|1224|1225') as $teaser" class='teaser-angebot-wrapper {$teaser->parent->select_color->title}' href='{$teaser->url}' > <section> <h3>{$teaser->title}</h3> <p n:if="$teaser->parent->id == 1223">Ausstattung: {$teaser->textfield_01}</p> <p n:if="$teaser->parent->id == 1224">Wo / Wann: {$teaser->textfield_02}</p> </section> </a>

Yes I will do it for the weekend. About ProcessWireMix, it's a custom Vite plugin to handle the build and generate the new "loader", which is then used to make the app view. I put a sample code of the the generated loader, but you will understand better with the example ? <?php // automatically generated at 2022-05-26T17:33:52.671Z by: yarn dev namespace ProcessWire; class ProcessWireMixAssets { const version = '2022-05-26T17:33:52.671Z'; const files = [ "additional_assets" => "assets/dark-theme.css", ]; } function mix($file) { return (isset(ProcessWireMixAssets::files[$file]) ? ProcessWireMixAssets::files[$file] : $file); } function mixVersion() { return ProcessWireMixAssets::version; } <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width"> <link rel="icon" href="<?= $favicon ?>" /> <title><?= $page->title ?></title> <?php if ($vite->isEnabled()) : ?> <script type="module" src="<?= $webappUrl ?>@vite/client"></script> <?php else : foreach ($vite->getCssAssets('src/js/app.ts') as $path) : echo `<link rel="stylesheet" href="{$path}">`; endforeach; endif; ?> <script src="<?= $vite->getAsset("src/js/app.ts") ?>" type="module"></script> </head> <body> <?php /// Inertia echo $inertia->tag; ?> </body> </html>

Here again ? I canceled a sponsor and I would like to send theses dollars to @adrian TracyDebugger project. I am again asking for Github Sponsoring Program for two reasons. The first is already said in the quoted message, and the second - take it more as an argument - I could make my boss to click and subscribe for a more important monthly donation than my monthly $15 per project. @adrian @ryan @Robin S

He needs a A 13-field form and a 13-field form is not a simple contact form IMO. Gideon

Oh yes, fix the ids selector! <?php foreach ($pages->findIDs('id=1223|1224|1225, sort=-created')->children as $item) : ?>

v. 1.2.0 is now released Twitter tags will be rendered by default Added support for image alternative text using custom fields in images Added support for inheriting image from parent pages (including home page) Added support for fallback page for image. If the image cannot be found from the current page (and possibly enabled inheritance fails), the module will try to find the image from the given page. You can use this to define default image for all pages. Fixed crash when passing an empty Pageimages object as an image Fixed crash when supplying an invalid image width or height Note that module now requires PW 3.0.142 or later, as custom fields for image and file fields were introduced in that version.

one of those tear your hair out moments: Cant seem to get a php template to send json back. I've added json to content type and disabled _init and _main files in the CMS. I've tried adding: echo "something"; echo array("something"=>"something"); echo JSON.encode(array("something"=>"something")) any I only get a blank screen when visiting the page, no {}, no nothing ? File got moved, so wasn't updatin ghte template file of the page i was looking at ?‍♂️

@dotnetic Jens, when do we get an update to the latest stable? 3.0.200 ? Or is it already online and I haven't found it?

By default, ProcessWire will prevent you from running subcruberList.php like that (you will get error 404 or 403). What you can do is create a ProcessWire template and set subcriberList.php as its template file. Then create a page with that template and do your POST request to that page. There are a couple of threads in the forums about handling forms that may be of help. Also consider using a form module such as FormBuilder.

what about the module SimpleContactForm. https://processwire.com/modules/simple-contact-form/ Wouldn‘t do that what you want?

Hi @wishbone I fully understand your feeling. I came from a non coder background, too. If you are willing to pay for a working contact form. I suggest you to buy Ryan's FormBuilder. Gideon

Hi @wishbone Maybe you can take a look at this module. Gideon

Me too ?

+1 I am working on my first Unpoly driven frontend and loving it so far. With so little code one can do a lot! What I'm aiming at the most is this: no businness data validation / calculation / transformation / whatsoever on the frontend, only in PHP at server side! A lot of "hidden" features are lurking in the Unpoly docs, reveling that things can be quickly implemented by applying a few HTML attributes only, see for example "dependent selects": https://unpoly.com/input-up-switch Unpoly is what Bootstrap is for CSS but for JavaScript, so to speak.... This is an important remark, I think. What they solve (including Unpoly) is not exactly that, but one can code all the "businness data manipulation" on the server only, and use these JavaScript libraries to implement an app like behavior in the browser relatively easily (especially in the case of Unpoly). One still needs to find the "right" backend framework/CMS/CMF that fits ones need and implement the HTML rendering for the frontend as required by the chosen JavaScript framework.

We've built an intranet for one of clients in ProcessWire before and it worked out nicely. Be sure to test all your roles and permissions carefully by creating test users for each. You might need to do some hooks or use some modules to get the level of control you need for your users.

Hello Seba, yes, this is possible. I have connected the login to our domain controller via LDAP and the control of the authorisations runs via corresponding groups. (Customized Version of this Module: https://github.com/conclurer/LdapSignIn ) in general, its just a normal website with access protection ?

@Jan Romero thank you. I really appreciated this mini tut. It would be awesome to see more of this. Breaking down a single challenge. And then newbies like me can build upon each and utilize each principle as needed. I don’t know if this repo is open to contributions but it would be a nice inclusion here: https://github.com/webmanufaktur/processwire-snippets

Not sure if that's what you're after: In the JSON of your post (let's say it has ID 19199) -> https://yoursite.com/wp-json/wp/v2/posts/19199 you should see featured_media: 19360 this gives you the image details: -> https://yoursite.com/wp-json/wp/v2/media/19360

We're currently working on a few sites that have some users with very limited access; most importantly, some users can only edit their own profile and nothing else in the backend. We're using AdminThemeUiKit, so the CMS navbar only contains the site logo and the username for those users. The problem is that the crucial "View site" link that gets you back to the frontend is hidden in the dropdown behind the username. This isn't immediately obvious (and TBH it does feel out of place there, even when you know it's there). I'm looking for ways to make the "back to site" link more visible – and I also think this is worth a discussion for AdminThemeUiKit in general. Here's what I have considered: Ideally, clicking the logo would take you back to the frontend (currently, you just get a blank page with nothing but an 'edit profile' button). I checked the settings, but the Uikit theme only has options to open the site tree or open a side navigation. Maybe a new option to go back to the frontend could be added? Or maybe the method that gets the logo link should be made hookable, so I could retain the default behaviour for editors, but change the link for users with limited access. An additional link in the menu would also work. But the only way I can think of to add this would be a Process module that just redirects to the homepage. But that's a bit overcomplicated, and I would like to do this without the additional redirect. Of course, copying the theme and modifying it manually or inserting a prominent link with JavaScript would work, but both options are sort of hacky and require some upkeep. Is there a better way? Have you come across this problem yet, and how did you solve it? I'm looking forward to suggestions!

@cjx2240 This depends on the selector you use to grab those pages. In the example, a $post->get is used, meaning it will be retrieved, by-passing restrictions. Are you using similar code? Please see documentation: https://processwire.com/docs/selectors/#access_control ps: I am not sure if ->child is also get-like.

After a lot of googling and many years this still seems like one of the best approaches to remove an undesirable part of a URL. For example, if you wanted to group a bunch of landing pages as children of "Landing Pages" but you didn't want /landing-pages in your URL. However I did run into a pretty significant issue with it, it bypasses any permissions you have to prevent page view. So if guests dont have permission to view the page, it will still load that page

Go to site\modules\InputfieldCKEditor\config.js and open config.js in your editor. This will stop CKeditor from putting the <p> tag including the start and stop (global) <p> tag : CKEDITOR.editorConfig = function( config ) { config.enterMode = 2; }; And this will give you both the <p> and <br> tag when needed but does not prevent the start and stop <p> tag CKEDITOR.editorConfig = function( config ) { config.enterMode = CKEDITOR.ENTER_BR // pressing the ENTER Key puts the <br/> tag config.shiftEnterMode = CKEDITOR.ENTER_P; //pressing the SHIFT + ENTER Keys puts the <p> tag }; ======================== Tested with processwire 2.6.1