Ivan Gretsky

I would love to see that todo list) It might be a good way to create a github issue for each item and group them with projects or project boards. Should I create an issue based on this topic?

Thanks, got it! Please add your thumbs ups to the issue, so it gets more attention)

Good evening @teppo and everyone! I am getting acquainted with partials. I like the way to include them with chaining interface <?= $partials->common->summaryblock() ?> much better than the include way (opinionated ?) <?php include 'partials/common/summaryblock.php'; ?> One problem here is that I have to add those brackets, as without them I get the file path. IMHO the rendered markup should be the default to be more in line with ProcessWire way. But my main problem is that I cannot use dashes (or dots) in partial file names. Is there a way to get around this limitation? Maybe something like this... <?= $partials->get('common/summary-block') ?> In simple cases it is just a matter of changing preferences, but if we get to partials with arguments, that seem to be the deal breaker, as we cannot do this: <?= $partials->common->summary-block(['heading' => 'Hi!']) ?>

Good day, @teppo! I have two templates (a and b) with different controllers, but same view file. So I want to make a use b's default view file in the render process. How do I do it? I tried many things like the one below in the a's controller's init() method, but without success. $this->view->setTemplate('b'); $this->view->setView('default'); For now I am doing this in views/a/default.php: <?php namespace ProcessWire; ?> <?php include($config->wireframe['paths']['views'] .'home/default.php'); ?> But maybe there is a better way?

Good day, @adrian! I am trying to bd() $config->paths, but I can only see first 100 items. Is there a way to show more? Didn't find any configuration for this.

Did you define a ProcessWire namespace?

Hey, @Mats! Please create a separate topic as Wireframe now has a dedicated subforum. This way we can easier track issues. @teppo, do you think locking this topic would be the right thing to do? Adrian did lock the old monolithic Tracy thread. Sorry for being meta and not on topic)

Can confirm the issue. This topic would also be a great fit for this.

Sorry for necroposting, but this topic is relevant, so why create a new one? There was a request for a forum section for reporting processwire.com, forum and similar related issues. Right now I am having a minor issue related to open graph in the forums, and do not know where to put it. Time to time this kind of section would be necessary. @Petedo you think we should create it, or we do not need this? If not, where do you recommend to post such topics?

@ryan, I've got a 'shameless plug' too)) But of a bigger size))) I've been desiring the CLI PW installer for a while. Maybe now is the right time for this dream to come true? Christmas is coming, you're working on the installer script... ? With it we could easily automate the installation with different site profiles.

What is your monitor size?)))

I've checked it out. I turned out I was wrong, and tabs in VS code already do it out of the box (actually just like PHP Storm as on @Robin S's screens): and you can configure it even more)) But the paths look so small I didn't notice them. And sometimes they still are not explicit enough. But maybe I just need to get used to this.

Nice to have this conversation going on) Thanks @Jonathan Lahijani! The 1st approach There is probably a room for each of the approaches. For now I am always using the 2nd one. It is the easiest for non-technical people and I have them in the admin. I do not think that I will ever use the 1st approach as it is. It is too complicated and too closely coupled with the markup IMHO. Not unless we make it more visual. To do it, we need at least 1, 2 and 9 from this list. The 2nd approach I can see how the 2nd approach could be made more configurable. You said earlier you're using Mystique for the options. I would've build option sets for different option groups: Оne for the section, dealing with section background, margins, width and so on. One for the grid, making columns proportions adjustable (50/50, 30/70, 33/33/33, 25/25/50 and so on). That option set should be limited by the pre-defined number of columns for block, so you wouldn't have 33/33/33 for a block that only should be displayed in 2 columns grid. Option sets for image and text (for the example in the video). The easiest way to implement those option sets is having them in separate Mystique fields. But they also probably could be merged into one general options field using this (hope I understood it right, didn't try it). Using separate fields would bring the benefit of positioning options next to corresponding items (like putting image options next to image field). I understand that this could be a lot of work to configure those option sets, but that could pay off in the long run. The main downside to 2nd approach is that you cannot easily and visually change elements' position/order. Like making image+text field a field+image. Or adding another column making it text+image+text. The 3rd approach I like the idea of using the 3rd approach, but I do not like the implementation. It indeed looks kind of hacky. I would stay closer to RM basic functionality, though extend it. I think that there could be a neat way to make it if @ryanwould help us here. We would need to implement no. 1 (and 2)))) from this list (Make possible to define allowed children for the matrix types.) This would make 1s approach more solid, but also help us with the third. So we would only allow image and text block under image+text. We would need to make possible creating groups of blocks from add block button. So when we add image+text block image and text blocks are automatically created under it. Might be already possible with hooks. We need to think what happens when we move one of the child blocks somewhere else, so there would be only text under image+text and no text. Or make it impossible to move them out of that nesting. Or teach our content managers to not do it (worst scenario)) Well, lots of hacks needed too) But at least the text and image blocks are under the parent block and are manageable the same way as others. --- There are other possible approaches. Probably Johnathan already thought/tried them, but putting them here for more alternatives. The 1+3 approach Let's have only general section block with options (no rows and columns) and content blocks. Content blocks can (but not should) go under section. If they are NOT under section, they display as full width. If there are more than 1 content blocks under section, they are displayed in columns. If you add 4 - there are 4 columns. Widths are adjustable on the content block label. If there are more than 100% of total width, they are displayed in 2 rows. Still we need no. 1 and 2 from this list to not allow content blocks be nested under each other. The Repeater/RM inside RM approach The name says it. Image and text blocks are inside of a RM nested inside Image+text field. Lots of extra fields, lots of configs, but I do it sometimes.

Good evening (at least here where I'm at))! Wireframe has a lot of files named the same way (default.php). When working with multiple files in an IDE (read "all the time") it is hard to distinguish between tabs as they are all named the same. At least it is in VS Code due to this issue. I am used to give files meaningful (bul long) names. I used to have templates/views/home/home.view.php instead of templates/views/home/default.php. Files are better searcheable this way too. Do you know any workarounds? Could it be worth it to have default filenames in Wireframe have configurable patterns, so that something like templates/views/home/home.view.php was possible?

In the project I am working on right now login and logout are handled with simple procedural code in _init.php on page reload. What would be the best way to do this in Wireframe? Put this code in bootstrap file (templates/wireframe.php)? This doesn't look pretty and in line with how everything else is structured. Have a common controller and subclass it? How would this work for templates that do not have controllers? Use built-in custom classes? What would you suggest?

Thanks for the thorough answer, @teppo! For now it is done in the code. As I said, I've been using a variation of Wire Render Pattern approach. The template file in this approach is kind of like a controller. I've set layout and sublayout vars in _init.php to the most used values and overrode them in template files. In _main.php I've passed template-specific content string to sublayout and then the whole thing to the layout. Most of the times I only had one layout - a skeleton with html, head, body, script tags + counters and a place to include a sublayout. Everything else went to sublayouts and views. In my current project this makes a lot of sense as there is completely different markup in different areas of the site (including different header and footer), but the assets (css and most of the js) are common for all areas. So it is comfortable to have common things in the layout, all the variable chrome in sublayouts, and template-specific stuff in the views.

Maybe css vars could help. Thanks for the insights. I finally understood that colors can be set as primary instead of blue in the config) But still all examples I've seen do use named colors. I guess it is a trade-off of using utility-first approach.

Nope. I was talking about the ability to apply different styles to the same markup for easy customization. Like you have your primary color as blue and the client wants to have it green. Or you want to override color just for a part of the site.

Is tailwind suitable for theming somehow? Same markup, different styles? I would guess it is not. But maybe I am missing something?

I've searched the API reference for $pages and couldn't find the description for $pages->newPage(). Should it be there?

Good day! I am getting into Wireframe and liking it a lot. But I still have a lot to figure out. Before Wireframe I was using something I called a sublayout. My <head>, opening and closing <body> tags and all the stuff before the latter, like 3rd party marketing tags and js, were all in a skeleton.layout.php file. This file was common for all pages. Templates had their views, but they were not included directly in the skeleton.layout.php but rather in one of the few sublayout files, which also held some extra markup, common to groups of templates. I usually had at least 2 of them - one for the homepage, and another one for all the rest. But sometimes there were more of them. I came up with this concept trying to imitate twig's template inheritance feature. I am not using twig and do not want a templating language in my projects (yet?), but want something similar. And sublayouts was my approach to it. I also did research things like plates, but never used nothing. Now I am thinking, what would be the best approach to handle this with Wireframe. I can see these options: Using twig via renderers. But I am still not sold on bringing it into my projects. Making 2 or more layouts and including the upper and lower part as partials. But I do not like to have this base template code split around a few files. This way it seems harder to deal with the code. But just maybe there are other options to configure Wireframe to do what I am after using its hidden powers?

I am running this action just like any other. But it does end up with an error (which I am trying to debug) and a Bluescreen (Redscreen would be a better term here))). I do not see this on any other actions I run, though I didn't try to make them end with an error. I does show only when I am running it and get an error.

Just sent it in a PM.

Good day, @adrian! I am debugging an Admin Action (yes, another module of your's)). I get an error and try to debug with bd(). I can see the Tracy bar and the dumps count appear. But then I hover the cart with dumps popup doesn't show. Actually no popups in the bar work. I get this message in the browser dev tools console: I also notice, that the Tracy code is added to the document twice: Why can that happen? Tracy seem to work as it should on other pages.

Hello, @horst! What a great module you've presented us, the community, with! I've got it on each and every of my sites, and it is working so good I rarely think it is there. Only when you have questions you remember it exists. So this is the time to express gratitude. Thank you very much! I am now moving my dev environment to the cloud to a VPS server. I want to have all my mail from that server to be caught and not to be sent away. So I started searching for solution and found MailHog. I've setup this program with the instructions from here. As far as I understand it, I've replaced sendmail with a substitute (mhsendmail) via sendmail_path setting in my php.ini file. That substitute program should redirect smtp messages to MailHog instead of the intended target. When I test sending smtp from the cli, it works as I was expecting. But when I send real forms from dev site, it does not. My understanding of what is happening when WireMail does its job is close to non-existent ?. Could you please explain, should WireMail use this sendmail_path setting, or does it work some other way and it does not affect it? And do you know any other way to achieve mail catching that I described earlier on a dev server? Thanks! --- P.S. I really think that 15 pages of great answers is too much for anyone to handle. Recently @teppomanaged to move his Wireframe's support to a dedicated forum thread. I am sure this module should have one too. Ask @Pete if you agree.