Ivan Gretsky

Just checked it, and everything seems to work fine on 3.0.199 when creating new page:

Great news! Having a recent master version is always a good thing. And maybe it is a good time to think about the roadmap for the future? Maybe even about those breaking changes, that could make 3.1 от even 4.0 a necessity? Something that revolutionize PW dev once again. I remember when 3.0 was planning. I didn't even understand what namespaces are back then)) But now I can't imagine staying at 2.x and love that that move was made on time. What is the next step?

Good day, @andrewbauer! I suggest you take a little time and dig deeper into how ProcessWire works. After that your question will be solved by itself) You can start with one of these written tutorials or watch this rather old, but still conceptually relevant video.

Hey, @Aleksey Popov! First of all you need to create a field to store page views data, and collect the actual data with a script. And then just use sorting in selector. Look at this topic or at this module.

Good day, friends! I am back to using the mighty ARB and this super useful addon to it. Thank you for your time and talent! The old issue @adrian, it seems like you didn't find time for it yet. Is there a chance you come back to this in the near future? The new issue I just found that the changes that ARBS adds to the Page List also apply to the children tab on the page edit screen. I see this is an unintended side effect that looks like a bug. @teppo, is there an easy way to change this behavior? P.S Created github issues (this one and this one) for your convenience.

Are you planning on "component namespaces"?

Good day, @teppo! You answered in the other thread, but not here. And the posts were made on the same day... So just bumping this one to make sure you didn't miss it)))))

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?