bernhard

I'm not using PHPStorm, I'm using VSCode and it just works. I think I had to install this once: https://github.com/shengyou/vscode-handler This one is linked in that document: https://github.com/aik099/PhpStormProtocol And I just found this one linked there as well ? https://github.com/recca0120/laravel-tracy

Hi Teppo, thx a lot for your thoughts ? Almost ? Technically it's 2 parts: 1) The module (framework) that lives in /site/modules and provides helper functions (just like the pw admin), eg $theme->assets->render() that could render all js scripts and css styles in the head (that can be populated easily in all your templates via $theme->assets->add("assets/main.css"); $theme->assets->add("assets/main.js"); 2) The theme files that live in /site/templates/yourtheme and provide all the markup generation blocks (the basic setup is very similar to the default site profile). These files can easily be pulled from github. 3) Optional: Theme customizations, eg /site/templates/mythemechanges that only provide those files that are different from the master theme (eg a custom logo). Technically building themes is even possible at infinite recursion levels (themeMaster, themeChild1, themeChild2, themeChildN) where the first existing file is taken, starting from themeChildN (whenever it is requested as $theme->getFile("blocks/foo.php"); It's not about populating a $content variable in the theme files. It's more about providing the presentation layer (views) that can be shared across projects. The logic still has to be built into every single project, but with the huge difference that it will be as simple as that most of the time: <region pw-replace="header"> <?= $theme->render("blocks/menu.php") ?> </region> In the example above I'm just using the $content variable of the default site profile, but that just shows how flexible this approach is and that's by no means a necessity! ? In other words: In the example above I'm using the business logic of the default site profile just by including _func.php and the current template file and I'm using 2 presentation layers, first the default uikit theme (the bright one) and then the second theme with the default and secondary uikit colors. Trust me, I've been there ? ? And I disagree (but also not meant in a bad way). ProcessWire gives us the freedom to build things the way we want and that's what we all love it for, don't we? ? The problem that I see with those markup generation modules is that they are either opinionated about the output (only support one framework) or don't look good or are just not easy to use. I'm building all my sites with uikit, so it's tedious to create a menu like this: $options = [ 'active-class' => 'uk-active', 'child-item-template' => '<li {class}>{title}</li>', ... ]; $modules->get('WhatSoEver')->render($options); Why? Because I'm not clever enough to always remember the correct markup/syntax and the module has other defaults (because the module author might not use uikit) and I'm doing this waste of time (and fun) over and over again... Actually I've not done too much frontend stuff, but I try to avoid repeating work as much as possible ? But you got a valid point here and I'll think about that more closely (what should be part of themes and what should be a separate module). Well, that's a good thing as it means that we are not building the same thing twice ? But I'm still not sure about it. See the explanation about the $content variable above. Isn't that separation of concerns in the way you mean it? It would also be easy to provide a similar feature to RockThemes that calls a Controller file before it renders the template/block (or view, if you want to call it like that). Eg you could have the template file /site/templates/yourtheme/blocks/header.php <region pw-replace="header"> <div uk-grid> <div><?= $logo ?></div> <div><?= $menu ?></div> </div> </region> And then you could have a controller file /site/templates/yourtheme/blocks/headerController.php: <?php namespace ProcessWire; class headerController extends themeController { public function renderMenu() { return '<ul><li>...</li></ul>'; } public function renderLogo() { return '<a href="..."><img src="..."></a>'; } } I think I like that concept... But I have to think about it ? Same with RockThemes ? Yes, that sounds like finally we are talking the same language ? Extending themes could either be done just by replacing a content block (by just placing a file with the same name in your child theme) or - don't forget about we are still using ProcessWire ? - hooks! <?php $theme->addHookAfter("render(blocks/footer.php)", function($event) { $event->return .= "<div class='uk-text-center'>Hello World added by Hook</div>"; }); Or something like this: <?php $theme->addHook("HeaderController::renderFoo", function($event) { $event->return = 'BAR!'; }); Would be great to hear what you think about all that, thx! ? Have a great week everybody! PS: Another story that would make a lot of sense once we have some kind of standard in the frontend just like we have in the backend ($config->scripts->add(...)) would be some kind of site builder features. I've talked about that with @Jonathan Lahijani as he has put huge effort on that topic during the last year.

Hi @teppo! Thx for your elaborate answer ? Thx, this sounds like the name of my module and the headline of this topic is somewhat misleading. Actually my take is closer to WireFrame than to WordPress Themes. Or maybe it is something in between. Well. I don't like site profiles ? Actually, I hate them ? Site profiles are so rigid and one-way. What if I developed a new project, started with my great profile and implemented a new feature (like new SEO markup that was not supported yet. I'd have to implement that feature on my site, then I'd have to update my site profile if I wanted to use this feature for future projects. And then? What happens to the 10 sites that I've built using this site profile during the last year? I'd have to update all of them one by one. What I want is to implement a feature once and then just do a git pull to update all instances. Maybe I'm overengineering, though... I think our approaches are quite close. I might have only been missing the site-profile part when I played around with WireFrame. So I ended up with a blank site and thought: "Ok, that's not too much of help or not really what I wanted." The idea of RockThemes is to provide a framework on the one hand (with a helper class just like ryan has the uikit helper functions file), but in addition to that themes could also provide basic page blocks that one needs over and over again. In contrast to WordPress Themes this could be files that are completely decoupled from the site's field setup. An uikit slider for example could look like this: /site/templates/themeMaster/blocks/slider.php <?php // defaults if(!isset($images)) $images = $page->images; ?> <div class="uk-position-relative uk-visible-toggle uk-light" tabindex="-1" uk-slider> <ul class="uk-slider-items uk-child-width-1-2 uk-child-width-1-3@s uk-child-width-1-4@m"> <?php foreach($images as $image): ?> <li> <img src="<?= $image->url ?>" alt=""> <div class="uk-position-center uk-panel"><h1>Foo</h1></div> </li> <?php endforeach; ?> </ul> <a class="uk-position-center-left uk-position-small uk-hidden-hover" href="#" uk-slidenav-previous uk-slider-item="previous"></a> <a class="uk-position-center-right uk-position-small uk-hidden-hover" href="#" uk-slidenav-next uk-slider-item="next"></a> </div> This block (that can be shared across different projects and simply updated via git push/pull) could then be rendered in the theme like this: /site/templates/themeFoo/home.php <region id="main-slider"> <?= $theme->parent->render("blocks/slider.php", [ 'images' => $page->your_image_field, ]); ?> </region> This means that it would not be a problem at all if pages had different field names. I guess some of that is obsolet now? I think you also got the impression that I'm talking about WP-like themes?

Hi everybody, having worked mostly in the backend for the last weeks and having an upcoming project where I need some frontend stuff soon, I played around with a new concept of creating frontend themes for ProcessWire. That idea is not new... Nico built WireThemes back in 2014 and @teppo has recently launched WireFrame. I've also built two websites using this module (screencast) but that turned out to be too complicated and it was also working only with the uikit frontend framework. But still, it feels like I'm doing a lot of unnecessary work with every frontend project: Getting the framework Setting up the design Setting up the menu Setting up the correct dependencies (scripts, fonts, icons, etc) Setting up the config (markup regions etc) Setting up site settings (logo upload etc) etc, etc A lot of this stuff is the same for every site, so I'd really like to have a solution that is plug&play where I just have to do the customizations and not reinvent the wheel over and over again with every project. Also, I'd like to have everything in place so that I can just git clone a theme and share one theme across multiple projects (just think about the site header with favicon, seo and social tags!). Meet RockThemes ? As you can see in the video, the process is quite straightforward. Just install RockThemes and copy your theme to the templates folder (and set $config->theme to point to that folder, which was already in place in the video). The current status is quite promising: Themes stay entirely in the templates folder One year ago I decided to create themes as PW modules. That makes things complicated because assets are blocked by .htaccess from direct public access! Now themes live in /site/templates and assets are easily accessible for the public. The module uses Markup Regions by default They are great and offer so much flexibility and power. They are perfect for such a module ? The template files stay clean and easy, eg the footer file of the theme: <region pw-replace="footer"> <p>Powered by <a href="http://processwire.com">ProcessWire CMS</a> &nbsp; / &nbsp; <a href="/admin/">Admin Login</a></p> </region> Or the basic-page template (that gets the date from the site profile's template file and just populates the regions): <?php namespace ProcessWire; $sidebar = null; include("../basic-page.php"); ?> <region pw-replace="mainleft"> <h1><?= $page->title ?></h1> <?= $content ?> </region> <region pw-replace="mainright"><?= $sidebar ?></region> Themes are extendable This means that you can build one default master theme that you share across your projects and then create one custom theme per project that only contains the files that you need to change. The module supports any CSS framework I've built a base module that can be extended for every framework. The base module will consist functions that every project needs (eg for rendering favicon markup or SEO tags). The framework version will then extend this module with framework specific functions like rendering a menu or rendering paginations. Switching layouts is as easy as changing one file default.php <div class="uk-container"> <section id="header"></section> <hr> <section id="main"> <div class="uk-grid-divider" uk-grid> <div class="uk-width-expand"> <div id="breadcrumbs"></div> <div id="mainleft"></div> </div> <div class="uk-width-1-3@m" id="mainright" pw-optional></div> </div> </section> <hr> <section id="footer"></section> </div> colorful.php <section class="uk-background-primary uk-light"> <div class="uk-container" id="header"></div> </section> <section class="uk-background-muted"> <div class="uk-container"> <div id="breadcrumbs" class="uk-margin-top"></div> </div> </section> <section class="uk-section-small" uk-height-viewport="expand: true"> <div class="uk-container" id="mainleft"></div> </section> <section class="uk-background-muted uk-section-small" pw-optional> <div class="uk-container" id="mainright" pw-optional></div> </section> <section class="uk-section uk-background-secondary"> <div class="uk-container" id="footer"></div> </section> All other files are unchanged! This of course only works if the regions are named exactly the same. That would lead to the challenge of having the same region names across our themes. I guess that's the case for all CMSs that have theming support? I can remember the times when I worked with joomla (content-top, top, header-a etc). Would it make sense to create a master layout that can be used for almost every project? What regions are you using in your projects? I think such a frontend framework could open up a lot of possibilities. It would for example be a lot easier to develop helper modules for the frontend (think of RockTabulator or something like FREDI) because we would finally have at least a very basic standard how things are done (eg how to add assets to the <head>). It could also be easier to work on projects in a team, because everybody would know how things work. Though, I'm still not sure if such a module would make sense for the public at all. I'd be especially curious what @teppo thinks about that and how you see that approach compared to WireFrame (I wanted to use it before I started this module, but it did not feel right for me). Maybe that's exactly the problem: When it comes to frontend framework / theming approaches things just don't feel right, because everybody is so used to his workflows. So what do you guys think? Would such a module make sense to you? Would you be using it? If yes, what would be necessary features? What would be no-go's?

Hi @nabo See the example for changed order status here: https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks You know about Tracy? ?

Just played around with your example and did a little refactoring ? Thx for sharing your code! $this->addHookAfter('ProcessPageList::find', function(HookEvent $event) { $pages = $event->return; $excludePagesByTemplate = array('admin', 'basic-page'); $pages->each(function($p) use($pages, $excludePagesByTemplate) { if(!in_array($p->template, $excludePagesByTemplate)) return; if(!$p->editable() && !$p->addable()) $pages->remove($p); }); $event->return = $pages; });

The page add step is skipped because of your settings that you linked to above. Not really: https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks (2015 ? )

You can set the title and name after the page was added: // site/ready.php $this->addHookAfter("Pages::added(template=yourtemplate)", function($event) { $page = $event->arguments(0); $page->setAndSave('title', 'foo'); $page->setAndSave('name', 'foo'); }); You might want to make sure that the name is uniqe (https://processwire.com/api/ref/pages-names/unique-page-name/)

Hey @ryan I tried setting a different templates folder today but the result seems weird to me. Am I doing it wrong? I'd have expected that if I set the templates location to /site/templates/theme1 the homepage should show /site/templates/theme1/home.php but in fact it shows a 404 because /site/templates/home.php does not exist and the page is taken as not viewable... Is that expected?

Starting fresh and importing the old data might also be an option. When I think of sites that I built 5 years ago I'd definitely build them completely new ? If you have to redo the design anyhow that should not be too much work and you can refactor things easily and improve quality and maintainability.

The better the questions the better the answers. You cannot expect that forum members can remember the exact problem that you have posted several weeks ago. Describe your problem. Try to make it reproducable (eg by providing a site profile of a clean installation that shows the problem) and I'm sure there will be someone who can help you. Sometimes even describing the problem as good as you can brings you to the solution ?

I'd create a PHP script where you bootstrap PW and execute it from the command line: You have the same PW version that your live system runs on and therefore you have the same sanitizer methods. You can do a dry run and only echo the file name conversions before you really copy files over. And you can watch everything in realtime. +1

if($page->block_page) echo "{$page->block_page->title}";

d($page->children()->count); // 7 $foo = $pages->get(1); $page->children()->add($foo); d($page->children()->count); // 8 d($page->children('id>2000')->count); // 3 $page->children('id>2000')->add($foo); d($page->children('id>2000')->count); // 4 $pages->uncacheAll(); d($page->children('id>2000')->count); // 3

Now you can join any finder to any column of another finder. That's quite powerful but might also get complicated or slow... It's especially handy when you want to use RockFinder2 as datasource of a RockGrid, because RockGrid does not support the new concept of relations that where introduced to RockTabulator https://github.com/BernhardBaumrock/RockFinder2/commit/8c6b66ad3dda68de9c1008078420f13a034250bf

What happens if you replace this with the hardcoded url in the tracy example? Just replace block after block with working snippets and you'll find the problem or can at least narrow down where it is and tell us more about it ?

Could you please explain by example what you are trying to achieve? At the moment I understood you like this: Public users should be allowed to view all public pages, but not page XY User foo should be allowed to view ONLY page XY (template bar) but not all public pages Same here. Or I didn't understand you ?

No, I'm asking because if you are logged in and it works it might be because caching is disabled when logged in. On DEV caching is likely also disabled so that could explain why it works there. Is the not-working form somewhere online to check?

Do you have any kind of caching involved?

$page->closest() might be the slightly better option (or might not): https://processwire.com/api/ref/page/closest/

That sounds like a good solution. Are you not happy with it? RockFinder2 might be overkill here, but if you have it available it might be an option: "owner" is a regular single page field. Or if you need multi-page-values:

Did you develop that site or someone else? Maybe there are some hooks in place. Did you try connecting in an incognito window (without any cookies set)?

<div class="headshot center-block" style="background-image:url('<br /> <b>Notice</b>: Trying to get property of non-object in <b>/home/drumming/ams.staging.gooi.ltd/site/assets/cache/FileCompiler/site/templates/home.php</b> on line <b>214</b><br /> ');"></div> Not the reason but something I found twice in your code and you might want to fix ?