Leaderboard

I didn't want to create a topic for this, so I decided to use my existing thread , as mentioned, I am creating some Youtube tutorials around Processwire, I feel a video is much more easier to help people getting started with Processwire. So I did a first video introduction, However I quickly realized my dilemma with self expression skills when talking, so I am working on that but here is the first video and I hope to drop a Video per week or more depending on how fast I can get things out but I am also open to covering other complex topics too around Processwire. Thanks and I hope this helps out a lot of people. NOTE: LOL Working on how I sound too ?, bear with me Love from Nigeria

Relative to ProcessWire 3.0.161, version 3.0.162 contains 24 commits that continue upgrades/improvements to selector operators, fix various minor issues, add new API convenience methods, improve documentation, optimize and refactor various portions of code and DB queries, and much more. For full details, see the dev branch commit log as well as last week’s post. Next week I hope to finally finish up a new version of ProCache and continue with some additional core to-do items. By early August my hope is that we’ll have the next master branch version ready. Also added this week is a new dedicated documentation page on this site that covers all of ProcessWire’s selector operators, including all the newly added ones here: selector operators. Thanks for reading and have a great weekend!

?‍♂️ Makes sense. I've added this to my todo list, will take care of it soon. Again, makes sense. I'm personally not a huge fan of tutorials — it's just not my thing. I prefer to learn by finding a project to work on, or alternatively by digging into existing implementations. Probably explains why there's no tutorial available for Wireframe either. Another item on my todo list ? Yes. On a very minor note the API for redefining component view would look like Wireframe::component('foo')->setView('bar'). Also: I typically choose the view in the component, i.e. the constructor picks the most suitable view based on the params it received. Both approaches are fine though, depends on the context! ? Interesting idea! I can definitely see value in this, but I'd still like to give it a bit more thought. It's easy to add features, but hard to remove (or significantly alter) them, so I prefer not to rush things ? Out of interest, how do you see this comparing to Markup modules using render method(s)? For an example: <!-- RockSearch with partial --> <section><?= $packages->RockSearch->partials->searchform() ?></section> <!-- SearchEngine --> <section><?= $modules->SearchEngine->renderForm() ?></section> One benefit would be that if I wanted to use the default search form as a starting point and start building on top of that, I could just copy the file to local partials directory and change the reference in the layout. This would, obviously, mean no more easy updates, so it's a double edged sword. In SearchEngine I decided to go with a set of interconnected render methods, each tasked with some specific part of the markup. I felt that this provided the best balance between reusability and customization: one can get pretty far by modifying config settings, but if that isn't enough, it's also possible to make more drastic changes using hooks. All in all I really like the idea, but it will require a bit more thought and probably some experimenting to strike the perfect balance ? Hopefully I'm answering the right question: Controllers and views are specific to a single template. Controllers' job is to accept arguments, process data, and pass processed data to the View layer. View — which consists of layout(s), view files, and partials — is there to output said data, so it should be as "dumb" as possible. View doesn't need to know anything about what's going on behind the scenes. Partials were originally just "include files" without the ability to accept params or a dedicated approach for processing data. They were great when you had a relatively static block you wanted to repeat in multiple templates, but if you wanted to pass them params, you'd have to define them in the parent context, etc. Components were added to fill this void. There's always a class that can accept arguments and process data, and usually there's at least one view file meant to render output. (Components can also render output directly by implementing the render() method, or they might not produce any markup at all, so technically component views are optional.) ... and then things changed a bit when partials also got the ability to accept params. Now the biggest difference between components and partials is the class: I prefer not to mix code with markup, which means that if I need a reusable "thing" that needs to, say, fetch data from an API, it's a component. On the other hand if I just need to reuse a block of HTML and perhaps iterate/output some variables in there, most of the time I go with a partial. In my mind controllers + views (and layout(s)) are the typical way to use Wireframe. Components are handy when you need an element that should be reusable across multiple templates. I guess they're sort of "template-agnostic miniature controller + view" bundles ? Note: how you actually use Wireframe may vary. Your site might not have any controllers, relying on components instead. Or you could produce all the markup in the layout and have no other files (apart from the bootstrap file). What I've described above is just the way I prefer to do things ?

More about the "happy" side of coding ?

Hi @teppo First I have to say: WOW! I took another look at your module because I got again frustrated with my setup and I wanted to build something on my own. Luckily I remembered your module and came back to the docs before developing something on my own ? Thx for the docs, they are great! Some suggestions: It would be great to have < prev | next > links on each page at the bottom. I almost missed all the other great pages when reaching the bottom of https://wireframe-framework.com/docs/ (the menu is not visible in the sidebar on such long pages) It would be great to have a simple hello-world walkthrough for setting up a custom wireframe template (instead of providing a full-blown site profile). It's always easier to understand something if you start from scratch than finding your way around several files not knowing which pieces came before and after another. And then something more advanced and more important: I think it would be great to get a little more (or different) control over where Wireframe does look for files. I read about the config settings, but IMHO they are a little limiting. As far as I understood one can define a path for every type that Wireframe is based on (views, controllers, components, etc). And as far as I understood it is possible for components to define custom view files via Wireframe::component('foo')::setView('bar'); Is that correct? The problem with that approach is that it is not possible to load components from outside of the wireframe folder structure. That's a quite big deal, because if that were possible, we could ship custom components/views/partials (I'm planning on working on styles using RockLESS) directly within our modules and that would just be awesome! Take this example: module RockSearch lives in /site/modules/RockSearch |- Wireframe | |- js | | '- search.js | |- less | | '- searchform.less | '- partials | '- searchform.php '- RockSearch.module.php What if we had a new Wireframe type called "package"? This could be included in any Wireframe layout like this: <?php $css = RockLESS::css([ $packages->RockSearch->less->searchform.less, $packages->MyGreatModule->less->style1.less, ]); ?> <html> <head> <link rel="stylesheet" href="<?= $css ?>"> <?= $packages->RockSEO->partials->meta() ?> </head> <body> <section><?= $partials->header() ?></section> <section><?= $packages->RockSearch->partials->searchform() ?></section> ... </body> </html> Finally we'd only need to tell Wireframe about the packages: $config->wireframe = [ ... 'packages' => [ 'RockSearch' => $config->paths->siteModules."RockSearch", 'RockSEO' => $config->paths->siteModules."RockSEO", ], ]; // or something like this Wireframe::addPackage($config->paths->siteModules."RockSearch"); This would finally bring some standards to the ProcessWire frontend which would make a huge difference regarding reusability! If we found a bug in RockSearch, we could directly fix it in the modules partials which would make it instantly available to all projects using it after a simple modules update! Thx for your great work again! What do you think? PS: Defining different views/partials for RockSearch should also be possible making it easy to support different frameworks or framework versions, eg $packages->RockSearch->partials->uikit3() or ->bootstrap4() etc. PPS: I didn't quite get where the differences between using controllers+views or components+views/partials are?!

Quick heads-up: SearchEngine 0.25.0 was just released. This version adds support for the new selector operators added in ProcessWire 3.0.160, and also adds a new details section below the selector operator setting. If someone has defined the operator in site config ($config->SearchEngine), that's still a valid option and new operators can be used there as well.

Hi, for better readability and more stability in edge cases, I would use the $config->paths->get("NameOfMyModule") syntax to get the exact matching path to your modules root directory. This is working even if someone, for example, dropped in the module from zip from github and the directory name became something different like "NameOfMyModule-master". I only would use this in front- and back end. $includeFilename = $config->paths->get("NameOfMyModule") . 'css/style.php';

A huge shout out thank you to all the PW developers who have, and continue to help me.

For a basic approach: $breadcrumbs = $page->title; foreach($page->parents() as $parent) { $breadcrumbs = "<a href='{$parent->url}'>{$parent->title}</a> / " . $breadcrumbs; }

@fruid I'm using this function for /** * Render breadcrumb navigation * */ function renderBreadcrumbs(PageArray $items, Array $options = []) { $page = wire('page'); if (!count($items)) return ''; $index = 1; $defaults = array( 'class' => 'breadcrumbs__list', // class for the <ul> 'a_class' => 'breadcrumbs__link', // class for a item 'a_active_class' => 'breadcrumbs__link--active', // class for a active item 'liclass' => 'breadcrumbs__item', // class for li item 'active' => 'breadcrumbs__item--active', // class for active item ); $options = array_merge($defaults); $out = "<ul class='$options[class]' itemscope itemtype='http://schema.org/BreadcrumbList'>"; foreach ($items as $item) { $class = $item->id == $page->id ? " class='$options[liclass]" . ' ' . "$options[active]'" : " class='$options[liclass]'"; $a_class = $item->id == $page->id ? " class='$options[a_class]" . ' ' . "$options[a_active_class]'" : " class='$options[a_class]'"; $title = $item("bradcrumbs_title|title"); $url = $item->url; $out .= "<li $class itemprop='itemListElement' itemscope itemtype='http://schema.org/ListItem'><a $a_class href='$url' itemprop='item'><span itemprop='name'>$title</span><meta itemprop='position' content='$index' /></a>"; $out .= "</li>"; $index++; } $out .= "</ul>"; return $out; } Then in template file $breadcrumbs = renderBreadcrumbs(page('parents')->not('template=categories|products')->add(page()));

You're right, thanks for letting me know. Links should be fixed now. I just switched to a different GitHub username and hadn't come around to updating the links yet. The docs can be found here now: daun.github.io/processwire-dashboard/

Unfortunately not. The mysqli wrapper uses the object oriented interface, so there isn't even an easy point to add that part in the core library between instantiating the module and invoking mysqli_real_connect(). Your best bet is to look at the stack trace to see which module causes the dump (enable $config->debug in site/config.php) and either find a replacement or post an issue in the module's git repo to get it converted to PDO.

Is the repeater set to Ajax load? If yes, you may have to look into the network tab of the browser's developer console for the ajax request. The server's response to that should give you more of a clue.

Since your Page::changed hook is called, trackChanges already appears to be enabled. Have you tried getChanges(true) inside a saveReady hook? Also, the change information should be visible in arguments 1 and 2 in a Pages::saved hook.

My interest lies in philosophy and hence I like books on this subject. Right now I am reading this Meditations Book by Marcus Aurelius.