Ivan Gretsky

One easy way would be to buy ListerPro. Once you have that, you can configure selector for the user list too. The configurations are not available to everyone, so they can't change them back.

I've used dokuwiki for documentation stuff. But now switched to BookStack as @szabesz. We already have met in its github too) Redmine for project management. Zulip to chat with distributed team. For now I have not installed it (use free SAAS for now), but it is possible. HestiaCP for dev and staging environments.

Wire-cli can do that (as a successor to Wireframe). I use it to script PW installation together with RockMigrations. I've written to @ryan about PW cli installation out of the box. Asked him if he would be interested to implement it. He didn't decide to work on this task yet, but he gave me this advice. I think he wouldn't mind if I repost it here:

It might be a great idea to extend this fieldtype with another 2 inputfields: One to be able to store images / files in a another field, selected in inputfields' settings. And to strore some kind of reference to that field. Not quite sure how to get it via API though. This way we can still have images manipulated from the custom fieldtype. Another one is json-based repeater. Something like Textareas or Multiplier. It will cover most of the repeatable needs for me at least. Will Textareas or Multiplier work in custom fieldtype by the way? the did not in Mystique.

I am with you @EyeDentify when you praise PW's simplicity and easiness to start to get around. But PW is also great being a powerful framework. Ryan always managed to balance things perfectly. New cool things like custom page classes never disturbed ones that didn't need them. So I am sure we can easily move forward making PW more suitable for larger projects, multi dev on the same project, more best practice compliance without sacrificing simplicity for the newbies.

Hmm. As far as I understand, none of the proposed goes straight into next major version roadmap. Or am I wrong? @ryan, please direct us. Should we write more proposals? Which direction should we move?

Thanks for this topic @ryan! Great to have a chance to look into the future and maybe even influence it a bit. I agree with @Jonathan Lahijani, but we surely need to expand on that. I can understand his point quite well. ProcessWire taught me be a (somewhat) ambitious developer, that is ready for bigger projects. And some of those grew big enough I started seeing the limitations of PW. And though I think that PW might be not the best choice for some projects (bigger web apps, as Ryan himself pointed out before), it can have its sweet spot in between regular CMS and web frameworks like Laravel. I will try to point some of the ways I see to improve PW to move further into that sweet spot. For now I can throw in this one: A better way to build custom user admin area. Reusing existing admin сomponents, but without the need to hide lots of stuff with permissions and hooks. So we could build something like /user-admin with limited functionality, but still using page edit module.

Hi, @Robin S! Just came to say thanks for this module. It is so cool to have when you need it!

Good day, @adrian! Hope you're just fine! I am using Mail Interceptor option to debug LoginRegisterPro. It sends mails with codes and links. But Mail Interceptor output window doesn't let me copy from it. I can see that all Tracy windows are like that, but this is probably the place, where this behaviour is extremely undesirable. Could we fix this without breaking everything else?

Double Commander is the best. I use it on Windows too. Powerful as... itself!

Great article, @FireWire! I would add that Wireframe is another great way to start working with PW in a more MVC-frameworkish-OOP-kinda-way. So check it out too.

I think that redmine is still the best open source solution. The best PHP based thing I ever came across is kanboard. This one looks ugly at first, but is extensible (themable in particular) and can do lots of things. If you only need tickets look through this list or something similar.

Great stuff! Thanks for this @ryan! I think that another great thing to have would be custom repeater item actions. As far as I understand, we now cannot add any of these. But they could be as useful. Especially for repeater matrix based content builder setups.

Thanks for this @ryan! Great to see something becoming free in the days that so many simple things tend to become paid on the contrary. The ProFields pack is still clearly a must have and worth its money for sure)

As the error message says, check site/templates/_uikit.php on line 830. This file calls for data you've removed, therefore the error.

Hi @rooofl! What are your goals? Is SEO a conсern? Best practices should always help achieve a goal. Anyway, let me add some options to go under "something else": Create a template for projects and out put nothing there but a link to the main page. Optionally restrict its indexing. Make sure no links point to that page (take care of breadcrumbs if you have them). This way noone but freaks who like to modify the url bar in the browser will ever get there. Same as 1 but add a redirect. You could put it in the template file for projects with something like this. Maybe with 303 or 307 code. If you really care about the beauty of the urls, could make use of url segments and make your project pages be accessible as home/project1. But that would require some work. You could put something useful on the projects page' Like a search box.

Ok, if it's time for claiming rights for abbreviations I will put PATU here. It is unpoly instead of htmx. Umpoly is more close to PW way of doing things being an opinionated but more full fledged solution. More to that, Ryan once said he liked it more. And it is not such a buzzword as htmx nowadays, quite in the spirit of PW. I even have two logo ideas for that to choose from: 1 - https://en.wikipedia.org/wiki/Patu_digua 2 - https://en.wikipedia.org/wiki/Patu The only small thing left is to actually build something meaningful with it))

Good day everybody! How are you doing @teppo! Wireframe\Controller has int() and render() methods. Their docblocks say that inti() is to perform early checks and render is the place to pass vars to view. I've been working with this a while but still do not quite grasp how to use them together. I either use one or a another. Demo repo doesn't have any examples with both methods. Could plrease someone in the know share their wisdom (or opinion) on this? And a more specific question. If I use them together and put checks into init(), how do I avoid triggering render, if those checks do not pass? For example, some fields are empty and regular render should not happen, but an error should be shown instead. Thanks!

@bernhard, is that module not deprecated in favor of migrations tweaks? If not, shouldn't we be encouraged to develop the Tweaks module instead? Does it have its own support thread?

I really like the idea with a tweaks pluggable collection. But I would prefer its usage was separated from the RockMigration module, so one could use tweaks without the more developer-centric migration tool. I thought that @bernhardstarted a dedicated module for that, but not sure if it is still alive.

PW doesn't work with SQlite, so no PW based nativephp apps possible) This is PW forum, so my first reaction is to explore possibilities of every tech mentioned concerning PW. I am sure the DB is not the only limitation though) But nativephp is something cool to know about anyway. Thanks, @szabesz! P.S. I've seen @flydev following static-php-cli which is a dependency for nativephp. Maybe he can share his wisdom on the topic.

Looks cool! PW based desktop apps on the way? Ahh... SQLite not supported... Probably not.

@Chris-PW, the module looks pretty cool. But using it without github and modules repository is kind of hard and limits the possible audience for it. And it is harder to contribute. Could you please reconsider @netcarver's advice?

Hey, @Michael Lenaghan. The setting() function might be a fit.

As it is all urls and html content at the end the answer is yes to all of those questions. The difference is that you don't get a unique page object for a urlSegment as you do for a regular page. The urlSegment can show data from some other page though (as you mentioned). You need to code all this. And there might be only a little or a lot of code. You need to start solving tasks one by one to find out all the answers. I do not see any difference where to test it at. Surely, most of the time it is done in some sort of a test env. Locally is totally fine. But maybe there is some sort of a limitation at your external data provider. If so, elaborate on this and we will answer in more detail.