bernhard

That's because there is none. Or there are three - depending on the point of view. Some classes come from jQuery UI, some come from UIkit, and to make it even more flexible the new default admin theme comes with its own classes, conventions and technology (CSS variables instead of additionally to LESS). There is a readme for AdminThemeUikit here. If you are using the new default theme by konkat many of these instructions are obsolete. In that case I guess your best bet is to look for information they provided spread across the forum and the blog. But to be honest from what I read this is all just fancy marketing blabla with screenshots how nice the new theme looks, but nothing answers the questions you just raised. I basically asked the same questions here and got no answer. Maybe you have more luck! Oh, and if you expect that you can use regular UIkit markup in AdminThemeUikit you might be interested in this thread as well.

Great, thx. Merged into v2.0.1 master 🙂

Hey @Stefanowitsch I think this should be fixed on the dev branch. Can you please confirm? Note that you need to create new events as old events might have some messed up end dates in the database! There was an issue in how those timestamps have been calculated and thus we had wrong dates in the database, which makes sense that your selector also failed to return the correct events.

@Jim Bailie I don't know and since you mentioned me: I'm not the one to ask this question.

Thx for narrowing it down @Stefanowitsch I'll try to have a look.

@Stefanowitsch have you tried an inRange selector like shown in the docs? https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/daterange/#finding-events-in-a-date-range

Thx for your support! Hope the modules will be useful for you. It's public now, thx for letting me know! 🙂 I have released my first open source PW module 9+ years ago and I have realised that nothing of what you mentioned pays my bills 😉 And all you mentioned is equally true for paid modules - the difference being that making money allows you to dedicate more time and thus provide even better solutions/docs/support. Or tackle problems that would otherwise not be possible to tackle. I think PW and all of us would benefit a lot more if we had a working ecosystem for paid modules and a larger market to sell the modules to. I just don't see that happen and that's why I had to give up and find another way. So I have a bit of a problem calling it "inspiring". I hope it is not and others find a better way. Open sourcing my modules was really just about minimising damage (for myself and my clients). If others benefit from that decision, that's great - but it was not the reason and I would not recommend anybody to take this as inspiration. 🙂 Thank you 🙂 Hey @Ivan Gretsky thank you very much. I think your post is spot on and you are asking some very good questions. Some very important questions. The problem that I have is that I think that those questions are not only important to you but would also be important for the PW project. I'm not sure who you are asking for? If you are asking for PW and try to push it forward, I'm sorry, I can't answer that here in a public thread unless I'm asked from an official source and get the feeling that the people in charge are interested. I hope you understand, but I don't want to burn my energy 🙂 If you are asking for yourself, though, I'm happy to share anything I have learned, observed, experienced in a personal chat with you. Just drop me a line and we can meet and talk about it. Would be nice to meet you after such a long time!

Thx! seems I forgot this one. Will fix this after my vacation 😊 Thx @cwsoft still here just not as active as before. It has always been a dream to push things forward and spend even more time with PW and provide top notch quality and support. but I realised I'm on very thin ice. Also I was really really busy with my startup which we launched last October 😊 thx for your wishes! Greatly appreciated (and needed 😅)

As some of you might know from my monthly newsletter I have been struggling with how to proceed with my commercial modules. It's a long story, but last year I reached a point were something had to change. The main problem is that building and selling modules for ProcessWire has never been sustainable for me. Not even close. It has been a lot of work to build the shop. It has been a lot of work to provide proper docs. It has been a lot of work to create videos about the modules so that interested people can get an idea of my modules. That's fine. I knew it would probably not be easy. But I wanted to try 🙂 You never know if you don't try. And I've had hope that it is possible. Unfortunately I don't have this hope any more and that's why I have to draw a line under it. That's also fine. I've learned a lot and I'm really thankful for anybody that has sent some Euros to a stranger that they have never met in person and that excludes any refund 😄 So for me the decision was taken. It took me quite some time to get there, but here we are. There was just one problem left: My clients. They have put trust in me and I didn't want to disappoint them. Just drawing a line might be a good solution for myself but might be a terrible solution for them (and their clients as well). Just not providing updates and keeping selling them is also not my style. With open sourcing my modules I try to find the best solution for everybody involved and I want to especially thank @FireWire for helping me get there 🙂 What does that mean? I'm using my modules in many of my own projects, which means that I will likely keep them alive for some time. On the other hand I don't plan to develop a lot of websites any more and many modules are somewhat feature complete as @FireWire helped me to realise, so there are no bigger updates planned for any of my modules at this time. Also, none of my modules is tested with the new admin theme. If you want to help out on that front, I'll be happily merging PRs, but as I'm not using it myself I'm not going to fix any issues or adding support for it in my spare time. So if you want to keep using my modules: Go ahead and have fun! 🙂 If you find the modules helpful it's always nice to let me know. Hope this is a good solution for everyone! Thx for reading and all the best.

Seems this module has not had its own forum thread. Now it has. https://github.com/baumrock/RockIcons

Cool @snck very interesting read. Glad you found a good solution for your problem and glad that RockMigrations helps you as much as it helps me 🙂

Your $targetImage is not a Pageimage but a Pageimages object. That's the case when output formatting is off or you request the image via $page->getUnformatted('myimagefield') or similar. To get the Pageimage (singular) object from a Pageimages object you can do $images->first() or ->last() etc.; see https://processwire.com/api/ref/pageimages/ and as it extends WireArray also https://processwire.com/api/ref/wire-array/

If you want to implement this go ahead. I'm not going to do that, because it's a free module and I don't have any benefit in doing so, because I'm faster writing migrations by hand. It's very fast and it's very reliable. Any other steps involved add possible errors and there might be several edge cases to think of. But I guess this would be great for some people, that's why I said I'd love to have it work like this. From what I thought about it so far I thought it would make sense to have some kind of "check-in" where you click on "watch this field for changes" and then it stores the current config migration somewhere and only writes changed properties to the config migration file. But again - it's nothing that I need for myself. I guess you have some hardcoded ids in your config migrations. That's another problem with these automated exports compared to writing migrations on your own. If you write a migration on your own you can use template/field/etc NAMES instead of ids. That leads to a lot better readable migrations (field => "whatever" vs. field => 123). I guess you have a fieldgroup_id => 123 somewhere and that's the same id of the fieldgroup that your original template uses. In PW in the GUI you only define the template, but internally a template has a fieldgroup that defines the fields that the template uses. And multiple templates can use the same fieldgroup and this is what you are seeing. Please check out the docs. If you are missing something let me know. Yeah I have always tried to have some kind of starter profile / module that I can reuse, but in reality most of the time I start over from scratch as it's fast and you don't get any overhead... But as soon as you have a feature that makes sense for more projects just create a module for it and migrations will be your best friend.

You can check out this module: https://processwire.com/modules/breadcrumb-dropdowns/

me too 😉 I'd love to have a feature, where you add/setup fields via the GUI and then click a button "save as migration file" with all the changed properties that differ from the default. But unfortunately it's not so easy (because some properties have slightly different syntax or you might get circular references or such things). And we have snippets, which makes it very easy to create fields. Once they are in place (when using VSCode/Cursor/...) you create a new file with the name of the field/template/etc.. and you type "rmf-text" and you'll get the code for a textfield migration. Then you chance all the settings that you need (or do it via the GUI and copy things over) and that's it. You have to remember maybe 10 properties/words to get 90% of the migrations that you need (columnWidth, label, type, notes, collapsed). -------- Not sure what is going on in your screenshot. Looks like it's using the fieldgroup of another template. Don't know why that's the case but it's nothing that I see in any of my projects. Regarding the prefix: Not sure if your migrations need to be part of a module? You can also place them in site/RockMigrations and there a file whatever.php will create a field called "whatever", not "someprefix_whatever". Then you can just copy and paste the templates and fields that you need over to the next project. But as soon as you want to make things more isolated and want to have migrations in a module the prefix makes sense as it will make sure we don't get naming collisions (eg multiple "body" fields or such). Hope that helps.