Ivan Gretsky

Not sure how it goes and if the whole thing gets deleted for the good)) But I can agree with some points laid out and wish we could talk them out and improve on them. Just today I was chatting with a client representative on a project she works at for more than 2 years. And she said that she still cannot imagine doing strings translations by herself as it is way to hard in her opinion. This is a 10+ langs multilang project, so it matters. I admit, she might not be very bright, but everybody else on the team is trying even less)) Maybe it is because we are using lots of included and rendered files and so on. But the case exists. Managing multilang images is kind of not so easy too, but it can be done with something like image tags.

I am a bit confused as I didn't see @MoritzLost's post to be insulting. Maybe it is my week English skills. But I am pretty sure he was not writing it neither to show any kind of disrespect, nor to promote another commercial CMS. He is not a native English speaker either. And a much younger person than me (as far as I can tell by the photo)) I wish we could see through wording and get to the points that he was trying to make. And I am sure he is making them in an attempt to make his beloved CMS better. I know he enjoys PW by his thoughtful posts here, his modules and his processwire.dev website. It is so easy to misunderstand each other. And sometimes it is hard to see ways to improve in criticism that sounds unfair. But if we can't handle it here, in our friendly home community, then who can?

Totally agree. ProcessWire is so amazing I wish I could grow with it in larger scale projects. I am sure that @MoritzLost's proposals could bring it much closer to this task. We should at least discuss that. Maybe, there could be a not-so-hard way to achieve that. Most of the configs are json already, so they could be stored in files instead. Moving to a better composer integration will bring us closer to what is considered mainstream php development nowadays (many PW gurus already tend to provide composer-based installation facilities). We do not want to sacrifice the PW way of doing things, but maybe now we can marry it with composer and git based workflow and move it to new heights. What do you think? Maybe it is time to start planning ProcessWire 4?!

As of PW 3.0.173 we can use URL hooks for that.

Great writeup, @MoritzLost! You nailed many pain points of ProcessWire. And actually spotted the main reason of why they are not being prioritized. Which is @ryan being the only one conceptualizing and deciding upon the architecture, the feature list, the roadmap, marketing... and actually almost all things ProcessWire. And he probably does not see them as pain points, as he doesn't face them in his workflow. I guess that the reason that Ryan stays almost the only PW core developer is his personal experience. His way of work determines this. not the lack of finance, which could be established. And that is something that we cannot change from the outside, but should try to convince him to consider changing. I am really grateful to Ryan for his work and attitude. I will love and use ProcessWire either way. I perfectly understand how hard it is to move from being a solo developer to a head of a team, as I am in the process myself. I do love everything perfect and checked by myself. And actually because of all that I suggest we think about the way to have some collaboration on ProcessWire development. Maybe we could start with some kind of conversation about it, if @ryan will find this idea worth trying. A messenger chat, a video call... Thinking forward we could have roadmap discussions, GSoC events, paid feature development by either core or subsidized developers, community supported docs and translations, crowd funding/marketing and even foundation... But we need to start with a discussion. I would love to be a part of this better organized community and take action towards collaborative PW future under Ryan's lead. But that is just an option to consider. ProcessWire is fine the way it is already. Maybe limitations laid out by @Robin S are the wireframe (sorry for the brand misuse, @teppo) that keeps PW sustainable and are to be taken as is.

Good day @bernhard! My question is not directly related to the module, but rather to admin theme UIkit customization in general. This place seems to be the right one for that too. Is there a way to assign different admin uikit styles and less customizations to different user roles?

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?