Ivan Gretsky

Hey, @FlorianA! Read this topic if you will.

Good day, @teppo! I am trying to understand how to pass variables to views in different cases. I am a little confused, as I see different examples in different places. And more top that, some things seem to work depending on where they are used. Controllers In the docs you give example of passing vars to views in render() method like this: public function render() { $view->some_var = "some value"; } In the boilerplate profile and in the documentation site source you pass them like below in init(): public function init() { $this->view->hide_aside = true; ... } Can you please tell if there is a difference? And which and where should we use better? Components There is no example of components usage in the boilerplate profile. But there are examples both in the docs and docs site source code. They both say we should pass vars to views in __construct() method like this: public function __construct(\ProcessWire\RepeaterPage $item) { $this->title = $item->title; } But I did confuse it with controllers and did it like this (with $this->view instead of just $this) : public function __construct($page) { $this->view->headline = $page->headline; } And it still worked if components were included in templates served through wireframe.php. Bit didn't in case I used components in non-wireframe templates. Could you please give me a hint, why is that and where and how to pass vars to views for controllers. Why is that inconsistent with controllers and why in different methods?

Good day, fellow Wireframe users! @Zeka once asked about how to organize large number of components in subfolders of components folder. Since then @teppointroduced view namespaces (for partials ATM), which probably could be extended to support components. We have found another way to use components in subfolders - via the usage of php namespaces. In @Zeka's case with the Blocks subdolder it would work like this: <?php // In [wireframeRoot]/components/Blocks/BlockText.php // Note the namespace namespace Wireframe\Component\Blocks; class BlockText extends \Wireframe\Component { ... and <?php // In the view file <?= Wireframe::component('Blocks\BlockText', [...]); ?> I guess this is possible due to PSR-4 compliance of the autoloader used. Or maybe @teppohas added something since then. Do you see this as a valid usage? Do you see any drawbаcks?

Sorry, don't have a chance to reproduce that. At least not quickly.

Great news! I've been trying to import data to and from services like Weblate and Crowdin several times to establish a collaborative effort to PW core and main modules translations. I've spent quite some time to make it work, I did communicate with these services' support, but couldn't make it easy with the current PW translations exports. Hope, that this module will make this task possible to complete. I wish we could somehow support the continuous type of translation workflow, but not sure it is possible without some intermediate steps, as translation files are not in the repo. Mentioning it here just in case)

Whoa! That is something I was wishing to have for years! Thank you! Recently I posted about donations and @bernhard's paypal link was on the list. But to my regret I have not donated to him myself. I wish I could fix my mistake, but things happened since then that do not allow me to pay online abroad anymore ? Please be so kind to help me out here and start donating to Bernhard. I know he will appreciate it. And I will join you as soon as I find a way to.

I am eager to get my hands dirty with this stuff! @teppo, do you think you would ship it any time soon?

Thanks for continuing to think and work on it, @teppo! I really like the new partials methods. If there would be a way to call a partial from a custom path like layouts/sublayouts that would be almost it. The question I still have is whether the view placeholders will still work in those placeholders, so I can still use them where needed? --- The other way I can think of is defining a layout stack with an array, where 1st layout when rendered is passed to the second and so on. Each of the layouts from the stack receive all view placeholders, so they could be used anywhere. But this should be thought out thoroughly.

I was about to create a similar topic, but why do it if this one already exists))) Not so long ago I started donating to some ProcessWire modules' authors. And each 1st of the month I am looking at my Patreon receipt in my email with a kind of a pride. I think that this thing is my little contribution to the community I love so much and which gave so much to me for free. I do know that Ryan likes to receive his support with pro modules payment. But many modules really shouldn't be paid/pro as they are so essential to many (and so fun to build). But their authors still would be glad to receive some money to sustain their enthusiasm supporting them and creating new features. I am sure the appreciation itself is equally important, but what is an easier way to show it than ???))) The other thing is that I sometimes notice some great improvements that seem to happen to modules as soon as some support comes in. I am writing this to encourage everyone to support the PW ecosystem by donating to module authors. I will list the modules I know that clearly asked for donations. I am sure that is not an extensive list. But at least something to start with. Tracy Debugger Mystique and other modules by ukyo (please don't miss this one @Jonathan Lahijani))) Rock Migrations and a bunch of rock stuff by bernhard All the great stuff from teppo I really like the Patreon/OpenCollective/Github donations, but only 1 of 3 listed used them. Sooooo..... Start throwing money at these fine gentlemen)) Support yourself by making you favorite modules not go away. I wish we could bring back @tpr to support his AOS and wire shell by @marcus and @justb3a. Would they keep supporting their thing is they had some donations coming in? Who knows. And please feel free to list you other module authors that you know asked for support below. Edit 2022-10-27: added teppo's link

@teppo, should we lock this thread to encourage to create dedicated posts?

If you end up making this feature request I'll surely give it a thumbs up. I am so used to this "errors" count in the Tracy bar I do not even look at them anymore. How are you doing, @horst! I reeeealy like that color indication and LOCAL label. Could you share how you achieve that? I would use it on every site of mine.

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.