Leaderboard

LyriChord is a Fieldtype, Inputfield and Markup module that lets you input a song's lyrics and optionally chords. You can input these manually or by importing from your clipboard. Inspired by the challenge posed by @oscarale in this thread: The markup module is optional. You can output your song the way you wish. For the HTML I prefer to use tables as they make it easier for things to be aligned properly without having to play around much with the CSS. Planned Features IMPORT XML HTML JSON CSV OCR PDF Other? NOTATION Staff? Guitar Tabs Solfa BOOKS Song books Pagination? EXPORT OTHER Support for syllables Transpose ??? Project + Download TBD soon. I need to cleanup a few things Quick(-ish) Demo

Ever needed a color picker on some kind of settings page? Didn't want to install and setup a full-blown colorpicker module? Here's a quick and dirty hook to change a regular text field into an <input type="color"> type of input: Before: After: <?php public function init(): void { wire()->addHookBefore('Inputfield::render', $this, 'changeFieldType'); } public function changeFieldType(HookEvent $event): void { $f = $event->object; $colorFields = [ Site::field_col_primary, Site::field_col_secondary, Site::field_contrast_primary, Site::field_contrast_secondary, ]; if (!in_array($f->name, $colorFields)) return; $f->attr('type', 'color'); } So right before the text input is rendered we change its "type" property to "color" and the browser will render a default color picker 😎 It once more shows how versatile ProcessWire is. And maybe it helps someone... 🙂 PS: Be advised that with that hack you only modify the optics of the field. The field will under the hood still be a regular text field, which means you'll not get any sanitisation or such from it and you might have to take care of that on your own. In my case it's a superuser-only settings page. So it is no issue at all.

Hi folks, I've been approached but a potential client that needs a PW developer to take over and existing site. My schedule is full at the moment (very thankful for that) but I said I would try here to see if anyone was available to take it on. I'm not taking anything, just passing on details as a favour. I've had a quick look through the site so far just so I can describe it but did not develop the site myself. The main site has been built on PW and the core has been upgraded to the latest version (3.0.246). The front end uses alpine.js a fair bit and there is a Shopify integration for commerce. The eCommerce has not been launched yet. Immediate jobs appear to be: Several module upgrades need to be run, ready for... PHP version on hosting needs to be switched from 7.x to 8.x Shopify integration needs to be tested for launch soon then upgrade to meet Shopify changes later in Q2 If interested, perhaps you could either DM me on here or leave your own website URL in the chain here and I'll forward everything. Cheers for now.

Hey @FireWire thx for the report! This was partly intended and partly not. The intentional part was that it SHOULD log something if migrations are triggered but disabled (to make it obvious if somebody expects migrations to do something and nothing happens). What was also intentional is that the file does only reset when migrations actually run. The idea was to save disk read/write operations. What was NOT intentional though is that this logging took place on every single request, which obviously means a small performance penalty on each request when using RockMigrations - even when it is disabled. I just pushed a fix for this to v6.8.2 https://github.com/baumrock/RockMigrations/commit/429ce68f3418aeedee108d80949fc14a224561a5 Now the logging only happens when $config->debug is enabled. I also removed the log regarding MagicPages, which was logging on every single request, adding an additional file write on every single request 😮 Thank you for making me aware of that!

@bernhard NICE!

Interesting approach, adding lines word by word would definitely be less error prone, but it seems cumbersome to input and update lyrics this way, as opposed to just writing it out in a textarea type field. I'll keep an eye on your project though it looks promising!

Maybe I am late to the party, because everybody is using AI for coding already, but I just wanted to mention: If you have a GitHub account and use VSCode for developing, try out the GitHub Copilot extension. 😀 https://code.visualstudio.com/docs/copilot/getting-started I have installed it a while ago and thought that I would not really use it, but recently I find it quiet handy. So far I only used the AI-powered suggestions, but its scary that the suggestions are mostly like I would code it. 😅

Either way it should not log something on each request. The goal is that RockMigrations does not slow down the site and only does something when it really needs to do something. This was obviously not the case here even though a single fileputcontents() might not be a noticeable penalty, but still...

I am considering open-sourcing Media Manager (and my other commercial modules). Please read and hopefully participate in the discussion in the Beer Garden (away from Google's prying eyes). Although the topic referred to is titled 'Padloper', the issues addressed equally apply to Media Manager. Thanks.

this still works in 2024 :) (answering my own question from 2013 haha)

The future looks bright! I'm very excited about the preview edition of GitHub Copilot. Finally someone putting AI to good use. Some of these suggestions are downright scary, they're so great. Write some code, a comment, then hit TAB. Boom. This is like Intellisense, but on steroids, and then some. Anyone else tried it? Care to share your experiences?

Hi @joe_g $pages->addHookAfter('added', function(HookEvent $event) { $pages = $event->object; // The page that is being added $page = $event->arguments(0); // If the page passes some kind of test if($page->template == 'your-template-name') { // Set the sort value for the new page to zero (sibling sort will be automatically adjusted) $pages->sort($page, 0); } }); Put this piece of code into the ready.php. Hope this help. Gideon

Or you can use the original Autosize Textareas module (sorry I didn't remember :)).

One of my older module just got some love! So, just wanted to mention that the Module was updated to v2.0.0 with some changes. 1. Its now compatible with PW2.4+ and PW3+. 2. Some changes were made to how it works. It was replacing core function to create the page list labels thus some newer features were missing. Which was kinda pain in the ***. Now it's just hooking after and prepends the image. Done. 3. It also now is not enabled/configured through the template custom label anymore. You can configure templates via a textfield on the modules configuration screen. Just enter template names along with the image field you wish to use: basic-page,image Or basic-page,image.landscape document1,image.portrait 4. It now supports also FieldtypeCropImage (v1) FieldtypeCroppableImage (v2) FieldtypeCroppableImage3 (v3) ... Thanks @adrian for the patience to fix some old problem, and give a hint at new PW3 menu issue. Strange looking at it after years

$config->httpHost should do the trick