Ivan Gretsky

This is my phpinfp() excerpt. I think it has all the right settings, but still doesn't remove those sessions(

Got same problem. I have co clean sessions table once in a couple of days, as it grows enormously. Had same thing with files. Sessions are a headache to me in either way(

Cool! And that is easily understood, as Tesla too uses processes that are totally wired)

Seems to be fixed.

That is just amazing news! Created a github issue about this enhancement so we can track it.

Done. I wish we could have the roadmap clearly visible in github. I you agree, maybe do start adding issues there. Thanks!

I have not thought about it) That would force us to use the templates root based partials all the time. This is an option. But it feels like too much of a deviation from the mainline usage. It seems to me that the best way would be distinguish between full and relative paths, so we could render a partial from a non-standard path time to time, leaving the defaults for common usage. Anyway, thanks @Zeka for digging in this and giving such creative options!

Thanks, @Zeka! That is option #4. Looks interesting! To make it easier to use and more universal, maybe we could modify both Wireframe Partial and Component API so they could render any file from any anywhere as a view?

Good day, colleagues! How are you doing, @teppo! I am building most of the page content with a builder built around Repeater Matrix (RM). With a great help from @Zeka I managed to make Wireframe get along with RM like this: I got the main ContentBuilder Wireframe component to render the whole content of a RM field. This component has no view of its own. But instead it generates the markup in its render() method. More on that below. There is a Wireframe component for each RM type (Type Components). Each Type Component has its view files. The main ContentBuilder component iterates through its items, determines each item's type, finds a corresponding Type Component for a type, renders it and adds the generated markup to its own output. I find it to be a great and flexible way to generate content from RM. But I got another need, which I an not sure how to approach. Often I need the same markup as I would get from a certain Type Component, but with the data coming not from the RM item, but from some other source (like a custom queries made in the Wireframe template controller or even from an inline PW API call). I want to reuse the view file I've got for the Type Component, but do not know how to do it the best way. Here are the possible options I came up with. Make view data generation in the Type Component conditional. So the component knows, when it is called from the RM context and uses data from the corresponding RM item. And when it is used in the other context, it uses other data. The context could be determined from the parameters passed to the component constructor. The question here is "Does it looks like too much for a simple component?" Make another component and make it use the same view. The question is "is it possible to share views between components and how?" Use Type Component view as a partial with parameters, passing in all the necessary vars. The question here is related to the discussion in this topic and it reads "is it possible to use a file not from the /partials catalog as a partial with parameters and how?" I guess, that this syntax would be perfect it would exist: <?= $partials->get("components/a/deafault.php", ['headline' => 'Hi!']) ?> <?= // Note the path is from the templates root. It could be an absolute path.?> I am leaning towards the 3rd option (if it was only possible))) But could you please share your thought on the whole issue. How would you recommend to handle it? Thanks!

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.