bernhard

Again: Are you sure? Well, I think there should be a rule that repeated asking of questions that are not directly related to processwire without going into the answers provided by the community and without reacting to questions directly pointed to the user in person should be a reason to ban an account. The user could always ask for reactivation. Not via an automatic password reset tool. Via a simple personal message. I'm not complaining. Just want to keep the quality of this forum high and I think in this case it is suffering. Sorry @Nvim if I'm wrong...

Yes, because the default theme has no hookable getCSS method and so it tries to load LESS and not CSS parsed by RockLESS. That's why my module sets the module in the site folder as default.

Nothing has changed in this regard. But we have Duplicator now, that might help you:

just wanted to say thank you @jmartsch I've needed your language pack for several sites in the last weeks and everything works great so far ?

Just wanted to let you guys know that I've just released my new module that we've discussed here:

---DEPRECATED--- Please use RockSkinUikit Just install the module and you can change the look&feel of your admin instantly by changing only one color: Download: https://modules.processwire.com/modules/rock-skin-uikit/ https://github.com/BernhardBaumrock/RockSkinUikit I'd be very happy if any of the CSS pro's could do some final improvements to the default.less theme - though I'm already very happy with the result! Happy Admin-Theming ? PS: At the moment this downloads a fork of the original AdminThemeUikit module because one method is not yet hookable. You can support this request here: https://github.com/ryancramerdesign/AdminThemeUikit/pull/77 and then I can update my module to pull the original theme from ryan.

RockLESS Download: https://modules.processwire.com/modules/rock-less/ Docs: https://github.com/BernhardBaumrock/RockLESS

Well. What if we defined an url to a readme file for every module? The initial data could be provided as one single json and the readme could be linked from there, eg: { classname: "FieldtypeRockGrid", readme: "https://raw.githubusercontent.com/BernhardBaumrock/FieldtypeRockGrid/master/readme.md", ... } For modules in the modules directory we could serve the readme directly when the module is requested via urlsegment, eg https://modules.processwire.com/modules/fieldtype-rock-grid/readme could serve just the raw markdown content of the module. Then we could request and parse details for modules via AJAX. But maybe @Soma has some input for us, as he worked on such a modules manager long time ago...

Maybe https://modules.processwire.com/modules/fieldtype-concat/ ? Don't know if that works only on runtime or also for selectors. You could also populate a separate field via saveready hook and then query this field if this does not work with the concat fieldtype (sorry, I've never used it).

Of course it is possible ? Just create a new folder and click reload on the laragon screen. If you enabled https it will even create the certificates for you. And you can even share your site over the web via ngrok instantly (eg for showing your work to clients). But of course you need to create a new database for every project as @jmartsch already mentioned. Well, I understand you, but those things happen ? But you have to be a little careful about your databases in general. If you mess something up, this can be a real nightmare to recover. I'd recommend you install https://modules.processwire.com/modules/process-database-backups/ combined with https://modules.processwire.com/modules/cronjob-database-backup/ . Then you'll always have db backups in your /site/assets folder. You'd still need to backup your files, of course. I wanted to use OneDrive for that, but it did not work well with laragon (too many files, too slow syncronisation, ...). I'm using GIT now for every project. It's complicated in the beginning, but it's the best solution in the long run. So, if you are willing to learn, there are lots of possibilities ?

In one of my RockGrids I have >3000 entries like this: { "id":"17627", "lists":"56708,59126,61021", "firstrevenue":null, "type":"2", "title":"John Doe", "prefix":"BA", "forename":"John", "surname":"Doe", "suffix":"MSc", "companyname":null, "tagsjson":"[9952]", "id":null, "short":null, "birthday":"xxxx-xx-xx 00:00:00", "mobile":"12345678", "tel":null, "fax":null, "email":"john@doe.com", "street":null, "zip":"1234", "city":"Wien", "country":"AUSTRIA", "poc":null, "provision":null "camefrom":null, "camefrom:title":null, "poc_id":null, "poc_short":null } The json file is 194kB gzipped and the grid performs well. RockGrid does already have a batcher feature built in. It would be easy to select modules and then click install and watch a progressbar while each of the modules is installed one by one. It would even be easy to define some kind of presets that should be installed (as it would just be an array of ids - or classnames). What could be a problem in this scenario would be the order of the modules. But I already have an idea how that could easily be solved ? RockGrid could serve as interface to select the wanted modules and then populate a ASM select field where entries would be sortable and then could be installed in exactly that order. A category filter would be a simple double-click. Not sure how we could treat modules that are not part of the modules directory, though. And on the other hand RockGrid is quite a beast and while I'd love to see it being part of the core (it could be such a great extended page reference field), as long as it is not part of the core it would be quite an overhead to the current version (regarding library dependencies etc). @Pete how hard would it be to offer a JSON that contains module data as an array of objects like shown above? [{obj1},{obj2},{obj3}]

I guess nvim is earning money in other ways... Still can't understand why nothing is done...

Just wanted to share the simplest language switcher possible if you only have two languages: <a href="<?= $page->localUrl($languages->findOther()->first()) ?>">DE/EN</a> ??

Wouldn't it be a lot more efficient and easy to serve one json file with all modules? At the moment we have around 25x23 modules in the directory, that's 575. For example displaying those with RockGrid would be easy and fast and filters would already be there. Not saying RockGrid is the best solution, just throwing in a concept for discussion you might not have thought of yet (meaning doing the work on the client side and not on the server). And this JSON could be served via procache, so it would need very little resources.

thx @dragan and @kongondo it worked now ? I had an @import "custom.css" in my theme and this is simply wrong ? https://stackoverflow.com/questions/11196915/import-css-file-into-less-file @img-bg: fade(@tm-primary-color, 30%); .gridImage:hover .gridImage__inner { background: @img-bg !important; } .gridImage.gridImageEditing .gridImage__inner { background: @img-bg !important; } This is what I came up with. But this is an ugly !important override because the theme is loaded at the very beginning and the css files are loaded afterwards. In the InputfieldImage.css file there are also some other colors that seem to be not a part of any less (or I am missing something?). That's not ideal. I'll continue to work on that. I've also found out that there is this handy function: contrast(@my-background, @dark-color, @light-color) So it should be possible to just create one single theme file and adjust very few colors and everything else could be calculated automatically (even for light and dark colors) ?

Hi Adrian, this looks great, thank you! I'm sure it will save me lots of time and clicks, because I can often not remember the exact name and have to head over to google, click, click, copy, paste etc... I don't think so. Why should we rebuild what we already have? The modules directory is exactly for that purpose. I don't see any benefit in building a new UI here. I know what you mean and I partially agree. Just FYI I'm building a new migrations module right now. And this would make such things easy. Similar to the PW KIckstart recipe approach you could easily create a module that defines which modules to download and install. And you could also define your default settings - which would not be possible with your suggested approach (or at least would need another step to implement).

Thx, that didn't work somehow...

Thanks for sharing your opinion ? Thank you adrian ? He already knows about my module: https://processwire.com/talk/topic/18763-alpha-rockforms-flexible-fast-and-secure-frontendforms-for-processwire/?do=findComment&amp;comment=178767 and he also knows about FormBuilder (which would be a possibility for him to contribute to the project as it supports Ryan). I don't feel offended - I'm also happy to be here and thankful that I found PW (thx again @gebeer!) and that lots of people here are providing such valuable tools and helpful posts. Let's get back to topic...

I played around a little and came up with this dark theme: All you have to change are these colors: // ############################################ // ########## main color definitions ########## // ############################################ @tm-primary-color: #52227a; @tm-secondary-color: #22b7c7; @tm-text-color: #313131; @tm-muted: #e7e7e7; // ############################################ // ############################################ // ############################################ All reno variable definitions could be moved into a separate file (like dark.less), but for testing it's nicer to have colorization support in my IDE. Totally different look&feel of the admin with no effort: ? Also on small screens: I tried to use neutral grey colors wherever possible, so changing only the main color should be enough to get a totally different and still good looking optic: Nice, hm? ? Does anybody know how to change this color? Somehow I was not able to find the correct file where this is specified...

Hi bud, all instructions are in the first post, the video and an example is also in the readme of the project. It's still not stable, so if you are not experienced it might be better to use FormBuilder.

Hi @anderson, welcome to the forum! If you want to learn and improve this is a great place to be. ProcessWire is a little different to other CMSs, meaning it is a LOT more flexible, but it is also a little bit more "complicated". In other words: It is more tailored towards the needs of developers and not people who want a quick&dirty click-click-done website. Did you already do (and I mean DO, not READ ? ) the hello world tutorial? https://processwire.com/docs/tutorials/hello-worlds/ If you are looking for a good dev environment I'd recommend https://laragon.org/ (you need apache for PW) and https://code.visualstudio.com/. Have fun!

Thank you guys! Turns out that something in my database was messed up. I did a restore and $modules->install() is working as expected!

Hi everybody, today I had a very hard time with the LanguageSupport module ? I tried a lot, but I can't get it to install via the API: I've tried this: $this->modules->install('LanguageSupport', ['force' => true]); And this: require_once($this->config->paths->modules . 'LanguageSupport/LanguageSupportInstall.php'); $ls = $this->wire(new LanguageSupportInstall()); $ls->install(); Both execute without an error, but when I visit the modules page, I get this: No matter what I try, it will not install ? The weird thing is: If I install it manually by clicking the button, it works as expected. Am I missing anything? I'm actually not doing anything different from here: https://github.com/processwire/processwire/blob/master/wire/modules/Process/ProcessModule/ProcessModule.module#L261-L275 (at least I think so) Help would be greatly appreciated! Thx

Short: Yes - Easy: No ?

Thx! I guess for little adjustments hooks would be the way to go. If it is more then it might be better to create a custom theme. The goal of my module / workflow is really just to "skin" the current backend a little to feel more familiar for my clients.