Leaderboard

I've been using Tailwind for years, yet there are still both those days that I really enjoy using it, and others when I wonder if it really makes sense, so I get what you're saying. Also: even though we use it for just about all of our projects nowadays, we often combine it with "custom" CSS classes (mostly BEM style), simply because Tailwind isn't always the correct tool for the job ?‍♂️ Others have probably said it already, but for me/us the benefits of Tailwind boil down to... super fast development, particularly when mocking things up / designing in the browser, common set of tools and guidelines, which is very nice when working in a team (having to dig into an older project that doesn't use Tailwind is a bit of a pain), and superb efficiency — by which I mean that using Tailwind results in very small CSS files, in most cases much smaller than I would get by writing my own vanilla CSS. There are a couple of things I'd view as downsides: a) markup becomes entangled with styles, and b) sometimes it feels like I'm just learning alternative ways to do the stuff I would already know how to do with vanilla CSS. First one is something that, in my opinion, can't be completely avoided, but using components for shared sets of classes helps a lot. Second issue becomes less of an issue day by day. Other than that, I'm quite happy with Tailwind, and it suits my workflow very nicely. It's not the perfect fit for everyone (or for every project), and that's fine too ? "What about keeping the main layout styling in vanilla css and put only utility classes for final layout tweaking?" Well, we use a combination of custom CSS and Tailwind already, but the literal "layout" part is one that's actually so efficient to do with Tailwind that I wouldn't bother doing it in vanilla CSS anymore. In my experience changes to the layout are often easier to implement with Tailwind than with vanilla CSS, and the resulting markup is actually quite clean. "Having said that, how many percent of all the available tailwind utility classes are really going to be used?" It doesn't really matter how much of Tailwind I / we use. Thanks to the tree shaking logic the "compiled" result only includes what is necessary. There's zero overhead in having a large toolbox but not using each tool for every project. "That brings me to the idea to sort out only the most useful ideas and classes from Bulma, Spectre and Bootstrap and bring them in your own utility class framework. That would make things certainly more effective." Exactly how would this make things more effective? We're in the business of building custom sites and/or applications, so pre-built components offered by a front-end framework won't help much (if at all), at which point — from my point of view — all Bootstrap and likes can offer is a very limited set of utility-first tools. Sure, we use prebuilt tools elsewhere (Vuetify for PWA apps etc.) but for custom-built sites Tailwind is (IMHO) a better fit.

Hi! If you want to accept any numeric value, you can just use Fieldtype Integer, Float or Decimal. As long as you don’t choose the HTML5 input, it will accept spaces and strip them when saving the page. If you still need further regex validation, it may be interesting to add regex validation to the numeric field instead of using a text field and dealing with the spaces. If you want to use Fieldtype Text, your idea of hooking ProcessInput seems good. Perhaps also look into hooking Fieldtype::sanitizeValue instead. Or maybe Fieldtype::sleepValue. All of these options will remove the spaces once when saving and then never display them again. If you want to show the spaces to editors for readability, consider horst’s idea or (assuming they’re deterministic like thousands separators) put them back in somehow. Fieldtype::wakeupValue will work, I imagine. Fieldtype::formatValue wouldn’t be the right choice here, because, as you noted, it only formats for output on the page, not for input fields in the page editor.

Many thanks @horst, that's really helpful. I wasn't aware of the "sort" column. All pages use the same image field. The pages use three different templates, but the problem occurs in the same way with all three templates, and the field settings are the same on each template. I'll investigate following your suggestions and report back.

@BillH You may have a look into the DBs table of an image field and check what numbers are set in the column "sort" before and after you opened, changed and saved or reopened a special page. If you have no DB viewer app at hand, you also can use a little debug script (cli script) to check this. Example script for CLI access, given the images field is named "images" and the page id of one problematic page is "1234": <?php namespace ProcessWire; include('./index.php'); $tablename = 'field_images'; $pages_id = 1234; echo '<pre>'; $query = "SELECT data, sort FROM {$tablename} WHERE pages_id={$pages_id}"; $pDOStatement = $database->query($query); foreach($pDOStatement as $row) { echo "\n{$row['sort']} :: {$row['data']}"; } echo "\n\nReady!"; exit(0); You may check if all image entries have a value in the column "sort", if it is a valid value, starting from 0 and is up counting, if it changes and when, etc. This may help a bit on coming closer to the issue. Do the older pages use the same images field and also the same template then the newer pages? If not, are there different per template settings for the images field? ...

I've found myself that the most useful classes are the ones dedicated to wireframe the layout itself, like margins and paddings. Using them in early stages of the blocking phase seem to be the most effective way for me. So I tend to do the opposite of what you are suggesting: utility classes first and layout tweaking with custom rules later (if needed). There is plenty of utility classes I never had to use, and that's ok. This is also true for vanilla css declarations as well, it all depends on the specific project. To me it's not about how many utility classes I would use, but how many of them I can reuse inside a single project, avoding inconsistencies all over the place. Having the ability to tweak them in one single configuration file is a bonus. Of course this is also true if you are smart enough to go with "pure" css custom variables inside the :root selector of your css. This is certainly an option, if you have found something inside Bootstrap, Bulma or whatever is missing from Tailwind. I don't see the point anyway, because with the new jit mode from Tailwind you will have just the utility classes baked inside your "dist" css, without any bloating useless css.

Nothing wrong with vanilla css at all indeed ? For me tailwind is just a tool that makes me quicker to write my css declarations and development in general. Take the above example: .btn { @apply px-4 py-2 rounded font-semibold bg-gray-200 text-black; } In plain css it would be: .btn { padding: var(--margin-tb) var(--margin-lr); border-radius: var(--medium-radius); font-weight: 600; // and this might be a custom property too if needed background: var(--bg-lighter-gray); color: var(--text-black); } It's more verbose I think. I've intentionally wrote css variables to slightly emulate what tailwind does: helping you to create and use a design system, with consistent values at disposal throughout the entire application. Not to mention purgecss, which is included out of the box, and for me it's a no brainer. It drastically reduce the size of the css to be used in production. That being said I always find myself in the situation where I have to write my custom css classes, where defaults values I set before are enough no more and need more control. There is this new option where you can set arbitrary values directly on the html markup (https://tailwindcss.com/docs/adding-custom-styles#using-arbitrary-values) but I'm not really sold and I still prefer to organize them by myself. Having another tool in the box might be convenient from time to time.

Thanks @Sebi - things are working for me properly now on PHP8. No rush on this, but I would like to raise @kongondo's suggestion of using PW's new URL path hooks (https://processwire.com/blog/posts/pw-3.0.173/#introducing-url-path-hooks) instead of the PageNotFound hook. I am not sure how much work it would be to change to this approach, but when I noticed the PHP8 issues in this module, I actually ended up creating my API via URL path hooks and it was really easy to implement with very little code. Obviously your module is going to be awesome for handling multiple APIs, multiple api keys, revoking access, etc, etc, so I will probably switch to it now, but it would be nice to not rely on that PageNotFound hook, because a lot of modules are using that and as well as feeling hacky, I feel like there are bound to be conflicts at some point with different modules and the order in which they are executed.

Thx, fixed in v0.0.73

@bernhard I found a bug in your RM update, this line https://github.com/BernhardBaumrock/RockMigrations/blob/master/RockMigrations.module.php#L1007 should be $data[$key] = $addFields; Data under repeaterFields option should be field ids, not names, obviously. Otherwise style and script assets are not loaded for inputfields in repeater (if not present in other places in the form). It took me quite a long time to figure out that ?.

@Orkun, in case you missed it, Ryan has fixed this issue: https://github.com/processwire/processwire-issues/issues/1482

When you say it's quite complex... ?

Thx @teppo It's option a) custom SQL queries ? I can't share details here but it's quite complex ? I mean... it's easy to use but in the background the module creates a quite complex sql query based on indices that I define for the search.

I know this is an old topic, but if you include wireframe-framework/processwire-composer-installer as a dependency for your project, it has a feature for overriding the default path in the root composer.json (which in my case is usually located in the site directory). This isn't documented anywhere, but technically this should make it possible to install modules and site profiles to any directory of your choice (relative to current working directory): { "require": { ... }, "extra": { "pw-module-path": "site/modules", "pw-site-profile-path": "", } } Also what I found interesting about Composer installers is that even if a package, such as an existing module, requires something like hari/pw-module as a dependency, if you define another "competing" installer in the root composer.json it overrides the one defined in individual packages. Most modules use Hari's version of the installer, but that's not really an issue for me, since my root package defines the wireframe version as a dependency – and things just work. Feels a bit hacky to me, but technically that's how it's supposed to go ?