Mikie

Just going to be brutally honest, this seems crazy to me. Markdown and its variants are standard for documentation, and open source docs are a solved problem. In 30 minutes you could have https://vitepress.dev set up and deployed to GitHub pages. In a few hours you could have your entire existing docs migrated and ready for contributions. You can rest easy knowing VitePress is backed and maintained by a massive, well funded open source team and is tailor made to solve every problem / requirement of static user contributed open source documentation. Why reinvent the wheel?

Nice to see movement in this space! One suggestion would be to add separate light / dark mode config for main colour, otherwise there will always be accessibility issues with contrast for buttons etc in one or both of light / dark mode.

On the ui kit theming topic here's a pretty wild project built on top of ui kit: https://franken-ui.dev

Sign me up please!

Hey @Robin S I think there is some confusion with the original non-pro version of the module. LoginRegisterPro has a support forum like the other pro modules, accessible with an active license like usual. It is also has a modules directory listing. Edit: or is that what you are talking about, support thread and listing for the original module?

Thanks Adrian that is perfect!

Hey! I have tried to search for this so apologies if I have missed it. Is it possible to set Tracy module config in config.php? Additionally, it would be great to be able to export current config for this purpose.

Ignore the above I just realised I can use the srcset and sizes methods separately. Man, responsive image markup fries your brain. Great module thanks!

Hi @nbcommunication, am just about to muck around with this module and it looks very robust, thanks! One question which may be premature, I don't see a way to customise attribute names for use with something like https://github.com/verlok/vanilla-lazyload#-demos. Ideally I'd like the following: "data-src", no "src", "data-srcset", plain ol' "sizes". I guess I could use the uk-img option and strip the stuff I don't need post render, but it would be nice to have these configurable both in module config and on the fly.

Hey maybe I am missing something, sorry if I am confused. In a current padloper site I have a multi page select field on the homepage so editors can select products and change them regularly. Also have something similar on editorial articles for “shop this story” style functionality on the front end. When you say this should be managed shop side what do you mean? Im not at all objecting to whatever technical decisions you’ve made, and a custom select field sounds like the right choice. can also envision the need for something more complicated, like a lister with multi filtering like lister pro to replicate the automated collection functionality of shopify. Eg editors can create a collection page and then filter products by any combo of tags, product types, price, sale status etc.

Hey @kongondo I think the question was a page select field for products, eg featured products on homepage.

Awesome cheers Ryan.

Just noticed the class name up the top in the blue banner as a sort of title. I still think the class name needs to be spelled out in the module info panel on the right. If you are new pw developer and see the instructions in "Add Module from Directory" section of the admin then you will visit a module page and look for the class name.

Heya, love to see module site in the refreshed look! Am I something here... where is the module class name and version compatibility info listed in each module? There is the user modules list on the left hand side which seems to output class name, but it quite hard to copy from and not noticeable at first.

I've tried using Tailwind but the verbosity of the classnames was a killer for me. Then I tried using tachyons which I much preferred but didn't like the lack of configurability. Tachyons (which came LONG before Tailwind) never pretended to be a holy solution for managing css, it was clearly defined as a quick way to get ideas onto the screen, with the view that you would slowly strip out all the utilities into regular css as your design system evolved. On the flip side, what tailwind did right for me was the theming system, however as a diehard stylus user I found it frustrating I couldn't use the theme variables in my custom stylesheets. Based on the above, I wrote my own utility functions in stylus that could 1:1 replicate tachyons or tailwind (or a mix of the two / whatever you wanted), with a theme defined in stylus hashes that could then be used throughout my custom stylesheets, plus mixins that replicate a lot of the utilities, eg px(2). Even still, I found that generally I would generally only end up using a few of the utilities like spacing, text-align, display etc. These days I follow a methodology mainly based on https://rscss.io and https://piccalil.li/cube-css/, with some ideas from https://github.com/ahmadajmi/awesome-itcss thrown in. I have a theme that defines defaults, still use some utility classes whilst developing, but basically break things up into: - theme (this is very simple similar to https://github.com/hankchizljaw/gorko, generally it just has: colours, breakpoints, media queries, fonts, spacing scale ) - mixins (I use some flex-box grid, media query and spacing mixins and that is about it) - base (resets, classless base styles etc) - elements (semi utilities for type, links, buttons, input fields, sort of like bootstrap) - components (pretty much everything is a component following rscss conventions) - utilities (rather than a separate utility stylesheet I now output the ones I want to use at the end of stylesheet and slowly strip them out) Currently this is working really well for me although I am sure it will continue to evolve. One thing I also do is try never to change classnames with javascript, but instead use data-attributes. This way you can very quickly parse what javascript is doing in your html.