Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/11/2024 in all areas

  1. This week I've bumped the dev branch version to 3.0.241. Relative to the previous version, this one has 29 commits with a mixture of issue resolutions, new features and improvements, and other minor updates. A couple of PRs were also added today as well. This week I've also continued work on the FieldtypeCustom module that I mentioned last week. There were some questions about its storage model and whether you could query its properties from $pages->find() selectors (the answer is yes). Since the properties in a custom field are not fixed, and can change according to your own code and runtime logic, it doesn't map to a traditional DB table-and-column structure. That's not ideal when it comes to query-ability. But thankfully MySQL (5.7.8 and newer) supports a JSON column type and has the ability to match properties in JSON columns in a manner similar to how it can match them in traditional DB columns. Though the actual MySQL syntax to do it is a little cryptic, but thankfully we have ProcessWire selectors to make it simple. (It works the same as querying any other kind of field with subfields). MySQL can also support this with JSON encoded in a more traditional TEXT column with some reduced efficiency, though with the added benefit of supporting a FULLTEXT index. (Whereas the JSON column type does not support that type of index). For this reason, FieldtypeCustom supports both JSON and TEXT/MEDIUMTEXT/LONGTEXT column types. So you can choose whether you want to maximize the efficiency of column-level queries, or add the ability to perform text matching on all columns at once with a fulltext index. While I'm certain it's not as efficient as having separate columns in a table, I have been successfully using the same solution in the last few versions of FormBuilder (entries), and have found it works quite well. More soon. Thanks for reading and have a great weekend!
    2 points
  2. Yes, using VSCodium. Running smoothly for the last 3 years or so. Prefer that over the original binary from Microsoft that comes with all their telemetry shenanigans. Only drawback is that some extensions from the official MS extensions store are not (yet) published at https://open-vsx.org/ which is the default extensions source in VSCodium. But you can still manually download the vsx file from the official store and install. Other than that, I'm very happy with my telemetry-free VSCode experience. Depending on your distribution, you can find the package in the official repos of your distro or in the AUR for Arch (which I'm on btw). Cannot confirm that. On my end it feels ok. But then, I don't have the comparison with MS windows. Can only compare it to Cursor which (unfortunately) is only available as AppImage. And those are not as well integrated into your OS as native packages are.
    1 point
  3. @Juergen great work. I’ll be using this for upcoming landing pages for a sales/marketing company. Thank you.
    1 point
  4. Great! You can also add one file _globals.php or something that would be called at first and there you could place things that need to be done first, eg creating some fields where order matters: <?php // _globals.php $rm = rockmigrations(); $rm->createField('field_z'); $rm->createField('field_a'); // field_a.php $rm->setFieldData('field_a', [ // something that references field_z ]); // field_z.php $rm->setFieldData('field_z', [ ... ]); Migration order should be _globals.php field_a.php field_z.php _globals.php should always be loaded first (because of the underscore) and therefore as soon as field_a.php is included field_z already exists and the settings can be correctly applied. You could also add a file zzz_final.php or something that is done at the very end.
    1 point
×
×
  • Create New...