Jump to content

d'Hinnisdaël

Members
  • Posts

    214
  • Joined

  • Last visited

  • Days Won

    8

d'Hinnisdaël last won the day on October 24 2023

d'Hinnisdaël had the most liked content!

1 Follower

Profile Information

  • Location
    Vienna, Austria

Recent Profile Visitors

2,848 profile views

d'Hinnisdaël's Achievements

Sr. Member

Sr. Member (5/6)

351

Reputation

  1. @TomPich The sprit of the module would be to keep it simple, and create the more complex pieces as separate admin pages. The canonical solution would be the ListerPro module, but this can be done without commercial modules using just the built-in Lister process module that is the basis for ListerPro.
  2. @TomPich Nothing built in, so far. Philosophically, I've seen the dashboard as a jumping-off point for users to get oriented, then go off somewhere else in the admin to do more serious work. My suggestion would be configuring a separate admin Lister page with filters, or building a custom Process module if you're feeling adventurous. That said, there are ways of doing this manually: Option 1: render a select input using a `template` type panel, with some JS to auto-submit the form on change. In your php file defining the available dashboard panels, you can then use that input parameter to pre-filter the results. This only works smoothly with selects where a full page reload is acceptable UX, so text inputs would require a different solution. Option 2: create multiple panel tabs, one tab for each available filter option. Still, not very useful for text inputs.
  3. @TomPich I see. Glad you got it solved. This might easily break your setup when updating the module, though. If you feel strongly about re-enabling the custom date formats, feel free to open an issue on the GitHub repo!
  4. @TomPich If the "date" field is an actual date field type (as opposed to an integer field storing the raw timestamp), this should work out of the box. The module knows about date fields and how to format them with using a custom format. If you're storing the timestamp as an integer, I'd suggest switching to an actual date field and getting the raw timestamp from that date field in the frontend instead: $page->getUnformatted('date') will usually get you the non-formatted timestamp as integer.
  5. @da² There's an official Twig-2-Latte converter that's really useful if you aim to compare both engines side-by-side. You can try it out online as well.
  6. @da² Latte doesn't have those issues since Latte code is compiled directly to PHP. There's no magic methods and no funky business with dynamic properties. Everything should work as you would expect it to work in a plain PHP file. There's a short but relevant section in their docs on using PHP in Latte files. I've never seen a project where Latte was a performance bottleneck — it's compiled to PHP and cached, so it should be just as fast as a normal PHP file. Usually, it's the amount of database queries and lack of granular caching that slows a site down. If the template engine is the biggest contributor to load times, you probably have a pretty fast site already 🙂
  7. Setting $view->template is perfectly safe, it's currently undocumented but that's how I'm using it in every project so it's not going anywhere. Uncommenting the $compiler line is fine as well — required, actually. The line was left over from the previous version but only works with Latte 2. In Latte 3, that line will cause an error. I'll take a note to remove that line in the current version to avoid tripping people up.
  8. @videokid Sounds like the composer dependencies haven‘t been installed. Have you installed the module using composer? Merely installing via the admin UI won‘t work as it‘ll be missing the dependencies.
  9. Appreciate the detailed explanation @bernhard and @gebeer, I was unaware of some of the finer points. Looking forward to trying the module again in the future. A brief philosophical note among the technical discussion (the thread seems to have gone off track a bit 🙂) — RockMigrations is a great tool and people seem to be enjoying it. And not everybody has to agree with its way of doing things. We were merely expressing our views on what a good solution looks like. Choosing to use a particular tool is about preference and previous experience. It's about finding what works best for each of us, and that might change over time, or it might not. Neither is directed against you or a critique of your work. I have no doubt that the features I referred to as "a few things too many" are valuable in your workflow. That's the beauty about creating your own modules – you're free to tailor them to your needs and include whatever saves you time. My personal opinion is that these features shouldn't be part a migrations feature. You seem to disagree, and that's fine.
  10. @ShadowByte You can add a sort order to your selector: template=news, limit=10, sort=-date
  11. I can't quite see how WEBP images are different from JPEGs or GIFs in this regard, and why they shouldn't be allowed as source images. All these formats are lossy and have the potential to look fantastically terrible when set to high compression rates, so there's really no ideal input format apart from TIFFs and lossless PNGs. The browser and OS support of WEBPs is such that we should allow them as source format if the server is configured to resize them. From what I've seen, most GD and Imagick installations these days handle WEBP just fine. With websites now outputting WEBP files, a growing number of PW users will expect to keep working with them as they've always been working with other common formats.
  12. @MarkE Sounds interesting! Keep us posted about new releases and let us know if you need beta testers.
  13. Welcome @Rasso! While ProcessWire doesn't have built-in support for migrations or version-controlled field definitions, it already supports export and import of field definitions via JSON, albeit only manually via the admin interface. However, it being JSON-based should be a good enough base to start automating some of this, e.g. by saving and reading the JSON from disk. That would also make them version-controlled as well. I agree this should be part of the core. Most CMS have solutions for this and it'd be a useful feature to advertise. The landscape of modules here is somewhat splintered. The module that integrates best with the core, Migrations, has unfortunately been deprecated. I haven't fully tested RockMigrations yet, but from what I've seen it seems to be doing a few things too many (snippets, "magic pages", "files on demand") and I'd prefer a module that limits itself to migrations, if not just for performance. +1 for a ProMigrations module from @ryan to ensure the best level of integration into the core.
  14. In the meantime, I've found a fix that kind of works: rename the repo to ImagePlaceholders, register the module in the registry, the rename it back to processwire-image-placeholders. Since GitHub will indefinitely redirect any requests to the new name, this should be somewhat future-proof, but very hacky and not my preferred solution here 🙂
  15. @ryan Thanks! Could we convert kebab case to pascal case in general? That way we'd cover all use cases. I've tested the following snippet below and it's working great. Currently conforming names will be left untouched: PageEditLockFields, ProcessWireUpgrade, etc. Any kebab case names are converted to valid module names: processwire-template-engine-latte → TemplateEngineLatte. function guessModuleNameFromRepo($repo) { $module = str_starts_with($repo, 'processwire-') ? substr($repo, 12) : $repo; $module = str_replace('-', '', ucwords($module, '-')); return $module; }
×
×
  • Create New...