Leaderboard

Same place where we've always been, and where we're ultimately going to be with any dependency management solution, automated or manual: risk assessment. Any time we depend on third party dependencies we're making a choice to trust the vendors of said dependencies (and by extension anyone they trust, and also anyone who might have access to the "pipeline" in between us and those vendors). Whether the benefit is greater than the risk is what matters. (Sorry for going a bit philosophical with this ?) As for Composer vs. npm, my opinion is that the situation with Composer is slightly less problematic, simply due to the ecosystem. I don't have numbers to back this, so please take it with a grain of salt, but in my experience relying on numerous interconnected dependencies is more common for npm projects. ProcessWire modules, for an example, tend to have relatively few dependencies, which can be a good thing (in this particular context). One solution, mentioned in that Reddit discussion as well, is roave/security-advisories. I would recommend adding it to your setups, just in case. It's a super simple package that defines a list of "conflicts", each of those being a package + version with known vulnerabilities. When running composer install or composer update, these conflicts crash the process. This may well be the only "positive use case" for conflicts I've come across ? It's not a fool proof solution, but a good start — and pretty much a no-brainer, in my opinion. Another thing that can help is private packagist, which provides automated security audits, alerts, and more. Private packagist is not free, but for commercial users it's definitely something to consider (and not just for the security features).

Yes - will do asap - should be working on that site again today or tomorrow... Thanks!!!

Just released version 1.0.0 which makes it possible to set both the main color plus the logo url from within the module (without going to AdminThemeUikit settings): AdminStyleRock Easily style your ProcessWire backend with two simple settings: Or via RockMigrations: $rm->installModule("AdminStyleRock", [ 'rockprimary' => '#0069B4', 'logo' => '/site/templates/img/kollar.svg', ]);

New version 0.0.9 at https://github.com/MetaTunes/FieldtypeMeasurement This has lots of bug fixes, plus a much neater way of doing conversions 'in field' : You can choose to enable the magnitude value to be automatically updated when you change the unit selection in a field - the options are to 'Always' convert, to 'Never' convert or to 'Ask' whether or not to convert each time the unit selection is changed (note that, if conversion is chosen and the unit is changed to 'no selection' then the magnitude value will be blanked). Many thanks to @kongondoin getting this working via HTMX (and also to @Robin Sfor modifying SelectizeAll). This version has been tested quite extensively, but only in one environment. Different PW versions, modules and your own code may affect it differently. It is therefore not recommended for use in production sites unless you have fully tested it in context first.

No. All migrations will run again, but if you don't change anything they will likely not do anything. The good thing about this is that if something changed for whatever reason, the migration will change things back to the state that is defined in code. So for example if someone changed a field setting by hand, the migration would revert this change to what is stored in the migration. To make it more obvious that it might not be the best idea to change field or template settings by hand the new version stores a trace of the migration for every field and template and shows a warning on the field/template editor:

Aah. I see. In that case, yes, you are right. You will need a 3rd-party or custom PHP solution. I don't think there's currently a module in the Modules' directory to do this.

There is an “upgrade” function defined in the Module class you can use (same as “install” / “uninstall”). You don’t need to use a hook for this. https://processwire.com/api/ref/module/ (here’s an example in a module I made)

@Macrura and @Ivan Gretsky - I haven't seen the exact issue you are seeing, but I did have a site that pulls in data from another PW instance that wasn't showing the debug bar. I fixed it by adding: if(class_exists('\Tracy\Debugger') && Debugger::isEnabled()) return; as the first line in the module's init() method. I'd love if you could test that please and see if it helps your issues. Thanks, Adrian

Ah, good point. Thanks for the clarification. Looking forward to seeing what you're coming up with.

All working fine now. Many thanks for your help @kongondo (and @Robin S). New version 0.0.9 of FieldtypeMeasurement is now on GitHub https://github.com/MetaTunes/FieldtypeMeasurement Do you think this is worth adding to the modules library?

A couple of potential things - I think getByIDs would be more performant. And also, if you have JSON in the meta, then using JSON_VALUE might be helpful.

Only option I know is plain SQL: <?php // populate test value $pages->get(1)->meta('foo', 'foo'); // find pages $result = $database->query("SELECT source_id FROM pages_meta WHERE name = 'foo' and data = '\"foo\"'"); $ids = implode("|", $result->fetchAll(\PDO::FETCH_COLUMN, 0)); db($pages->find("id=$ids")); If you use this with user input be sure to properly sanitize the data and maybe use prepared statements!

Great! ?. I'd say this is the trivial bit. The repeater items already have your hx-attributes, so they should target the right repeater item. Alternatively, you can find out about the item in the this that you pass to htmx.process() above.,

Oh...kay... now I get it. Sure this could happen in some way in or with Composer as well. The r/thread is a nice read. This whole scenario was always the reason why I rarely used and use NPM or Composer - it's so often a big blackbox.

This week's commits are primarily focused on resolving reported issues (via GitHub issue reports). While that doesn't make for exciting reading here, it's an important part of working towards our next master version. Though I am working on various other projects including client websites running in ProcessWire, ongoing updates to Pro modules and development of other ProcessWire modules. One module I've been working on this week (and last week) enables you to export translations for multi-language fields into JSON or CSV files. These files can be read into other translation systems, edited, and then imported back into ProcessWire. So if you need all the content for a site translated from one language into another, it provides a very convenient means of doing so. More details on that one soon. That's all for today but stay tuned and thanks for reading. Have a great weekend.

I'm surprised you have so many template variables to declare. You might like to take a look at Markup Regions because that should greatly reduce the number of variables you need to hold markup. Does the below work? (P.S. parentheses are redundant for include, include_once, etc because they are expressions rather than functions) include_once './_func.php'; include './_header.php'; include './_sidebar.php'; include './_footer.php'; include './_buttons.php';

The main difference is how migrations are triggered. On the old module I've used the "fireOnRefresh" approach which fired migrations on every modules refresh. On the new version you can add files to a watchlist and migrations will automatically fire if a file changed. That makes a huge difference when working with the module as you'll only need a page reload and the new data will be there ? Also I've improved logging so that it's easier to see what happens and the module handles same cases in the same way (the old one sometimes threw exceptions, sometimes did early exists). Other than that it's quite the same as the old one as I'm really happy with how everything worked there. I've refactored all methods while transferring them from the old version to the new one.

Am I right in saying that this module is less about migrations and more about automation? As using methods to do work using handy functions in a linear way sounds like automation to me, where as migration is something I want to do when I have a bunch of stuff that has happened to the environment that needs replication for some reason (i.e exporting and importing fomr staging to live). I only mention it as ideally you would work on your PW install (in the admin or in code) and at certain points take a migration of the changes... and therefore not need to hand write the migrations at all, as they're actaully artifacts of changes to the db? Bit meta, but I like using the admin, and would rather migrations were something that happened, not that needed writing. (this is coming from some experience with a migrations module in Drupal 6... yes i know! That did just as explained)

I use a slightly customised version of this useful module and found that the page list additions weren't looking so good in the new Tree dropdown menus, and they aren't needed there anyway. Solution was an early return if the 'noTags' option is set... public function addPageIdLabel($event){ $page = $event->arguments('page'); $options = $event->arguments('options'); if(!empty($options['noTags'])) return; // return if this label is for the Tree dropdown menus $event->return .= " <span class='helper-info'>($page->id, $page->template)</span> "; }