bernhard

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.

Update: I've released a preview that everybody can use to play around with and hopefully contribute to this project: Here is the LESS theme that I used: This is basically the reno theme file of the original AdminThemeUikit, but I introduced the "tm-primary-color" variable. In the reno theme there are several variables with similar colors and it would be nice to have those colors dynamically calculated. Maybe some of the CSS and design experts can help here? @tpr @renobird Who else? My goal is to have a theme that we can use, where we would only have to change two or three main colors and the look&feel of the admin could fit our clients' CI. Maybe we would also have to define contrast colors for text (if the background is light, the font color needs to be dark). Maybe we could create two themes: One for light backgrounds, one for dark? Only thing that I'm not really happy with so far, is that the AdminTheme is not listed in the modules upgrades list, because it is not yet listed in the modules directory. I guess that would be easy to change. In the video I'm using a fork of Ryan's version, because I need one method to be hookable. Please support this PR on github: https://github.com/ryancramerdesign/AdminThemeUikit/pull/77 PS: I'm using https://processwire.com/talk/topic/17860-preview-processwire-kickstart/ if anybody wonders ? PPS: Here are the github repo links: https://github.com/BernhardBaumrock/RockLESS.git https://github.com/BernhardBaumrock/AdminThemeUikit.git

That's why I mentioned it. That might be a feature or a drawback - depending on the situation.

RockGrid has this built in, so it would be a lot easier to just use RockGrid instead of using DataTables + Queue. Only difference is that horsts queue works on the server side and RockGrid batcher works on the client side. Sending emails is another interesting decision to take: do you want to send them via the server or via a transactional service? This would need different implementations..

Thx for sharing your learnings @Chris Bennett I've also customized colors of the admin via CSS once, but that was a pain IMHO. Changing LESS would be a LOT more readable: @reno-text-color: #354b60; @reno-link-color: #ffae00; @reno-link-hover-color: darken(@reno-link-color, 10%); @reno-dark-background: rgb(0, 94, 202); @reno-muted-background: #f0f3f7; @reno-muted-text-color: #8d939e; @reno-muted-text-color-alternate: #6c8dae; @reno-primary-background: #1a0ce7; @reno-secondary-background: #e2e9ef; @reno-success-background: #8bccde; @reno-success-color: @reno-text-color; @reno-warning-background: #FFD15E; @reno-warning-color: @reno-text-color; Ideally we would have two skins, one skin for dark main colors (like blue, dark orange, red etc) and one for bright colors (yellow, light green etc). Then we could just choose between light.less or dark.less and modify the color to fit to our client's CI. Then change the logo and boom, we have a completely customized admin that feels like home for the client.

Maybe I'm missing something, but styling via CSS would mean that you'd have to find ALL expressions relevant to your desired color change and list that in your CSS, wouldn't it? Whereas using the LESS theme you would only have to change one variable setting, as shown in my video.

Everything fine now, thx.

Exactly ? I'm just not sure what would make the most sense. Using Inputfields would be the most comfortable, but I'm not sure if that would make sense at all. Because the question would be which options (colors) to make available via Inputfield and which not. Then I think it's better to leave everything in LESS. So one has also the benefit that it is possible to control all other aspects as well (like paddings, margins etc). https://github.com/oyejorge/less.php That would make live changes possible/easy. But I guess we would need to rewrite all the LESS files? (edit: more below) @Robin S you are right, it already works if you download the theme via github, setup a parser, save the css, set PW to use the new theme, set the theme to use a custom css file. And then there is an update to the repo and you have to do everything again... That's way too much effort imho! I want to install PW, adopt the main colors to fit my clients CI, save and go. I plan to build the less parser as a separate module, because I'm using it for a frontend module as well where I need the same features (parse less and create css, but cache the result if nothing changed). New idea: What if we extracted only those LESS files and images into a folder. Similar to the existing "main css file" Inputfield we could have a "main less file". I've already done this in my current module: Putting this in a separate folder we could zip them and share them with the community without the need of installing a new admin theme, changing only the SKIN (I like that wording, thx @adrian ). But I guess that would be too much... for me it would already be enough to adjust the main colors.