d'Hinnisdaël

April 4

If you're on PHP 8 and a new-ish version of Latte, you should be able to use the nullsafe operator to safely get the value:

<body n:class="$page?->category?->value">

On PHP 7, you can still use the similar nullish coalesce operator, which in this case behaves identically:

<body n:class="$page->category->value ?? ''">

February 10

@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.

February 10

@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.

January 28

@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!

January 28

@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.

January 1

@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.

January 1

@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 🙂

December 31, 2023

1 hour ago, kp52 said:
Since I prefer to have fewer templates and files, I often link various Processwire templates to the basic-page.php file, with a switch structure to select the required handling. TemplateLatteReplace allows me to link to the necessary Latte template via $view->viewFile, e.g.
	case $page->name == 'diary': 
		$view->viewFile = 'diary.latte';
More by guesswork than analysis, I found I can have the same functionality in TemplateEngineLatte with $view->template:
	case $page->name == 'diary': 
		$view->template = 'diary.latte';
Is that a safe thing to do?

I have a few custom filters defined in _init.php in TemplateLatteReplace via $view->addFilter(). I found the equivalent hook-based method in the TemplateEngineLatte docs, and tried it with one of my filters:
wire()->addHookAfter('TemplateEngineLatte::initLatte', function (HookEvent $event) {
    /** @var Latte\Engine */
    $latte = $event->arguments('latte');
    $compiler = $latte->getCompiler();

    // Add filter for compound dates & formats
	$latte->addFilter('e_dates', function($day, $last, $format) {
...
This causes an error: Call to undefined method Latte\Engine::getCompiler()

The filter definition works fine when I comment out the "$compiler = " line. Presumably it's there for a purpose. What would be the respectable way to avoid the error?

KP

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.

December 23, 2023

@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.

December 3, 2023

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.

December 3, 2023

@ShadowByte You can add a sort order to your selector: template=news, limit=10, sort=-date

November 28, 2023

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.

November 27, 2023

@MarkE Sounds interesting! Keep us posted about new releases and let us know if you need beta testers.

November 27, 2023

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.

November 22, 2023

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 🙂

November 22, 2023

@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;
}

November 22, 2023

@maetmar You don't need to call or render anything. That's basically what TemplateEngineFactory does for you behind the scenes. For every template.php, it will look for a corresponding view file, e.g. template.latte or template.twig. Looking at the module again, for that to happen, you need the mentioned option enabled: Enable automatic page rendering. Why this would interfer with your prepended _init.php, I don't know and is something to debug.

November 22, 2023

@maetmar It's probably best to ask this in the dedicated forum topic for the TemplateEngineFactory module. The Latte engine has no influence on this behavior, it merely renders the output.

For what it's worth, I have that option enabled and my _init.php is being called normally, so it might be something else.

November 20, 2023

@ryan Thanks a lot! That's useful to know. Is this something that could be reconsidered or changed in the module directory? I've recently started prefixing module names with processwire- on GitHub for better context and discoverability and have found that to be a great way of organi`ing projects. This makes it a lot easier to e.g. enter "processwire" into the repo search input and filter down a list to only PW modules.

@bernhard Sweet — I'll definitely need to try that as well! It's super easy to forget simple steps like version bumps when creating releases. Better to automate this.

November 20, 2023

I've upgraded the module to work with Latte v3. Note that this is a potential breaking change if you're defining custom macros and might require code changes on your end. Learn more about the migration to Latte 3 and upgrading macros to tags.

To upgrade:

composer require daun/template-engine-latte:^2.0

November 20, 2023

I'm having trouble submitting new modules to the directory, as well as updating versions of existing modules.

What's the best way to debug this? Is there some person I could ping from the core team to help me look at this? Has anyone had similar problems?

Here's the concrete issues I'm facing:

When trying to add the ImagePlaceholders module from this GitHub repo, it errors out with the message: "Unable to load module info from GitHub. Please make sure there is a getModuleInfo() function, a ModuleName.info.php file, or a ModuleName.info.json file". However, the module does have a .info.php file and is working fine locally and when installed via composer.
Trying to add the DatetimeCarbonFormat module from this GitHub repo results in the same error. This one also works fine when installed and has a getModuleInfo method defined.
An existing module, TemplateEngineLatte, seems to not get updated, even after successful refreshes. The version is stuck at 1.0.0, even though the GitHub repo has a recent 1.0.6 tag.

November 17, 2023

Great to see people adopting Latte 🥯

One potential issue with your example is that you're creating a new Latte instance for every single Page class instance that is created. And page class instances are created whenever they're pulled from the database. Meaning, when you're looping over a set of 100 pages, you're creating 100 Page instances and 100 Latte instances with it. That's rather costly for performance.

The advantage when using existing modules like TemplateEngineFactory or RockFrontend is that they take care to only instantiate a single instance of whatever renderer they use for generating template views.

November 17, 2023

Amazing, thanks for creating this! I agree this should be part of the core once it's been in use for a while.

October 26, 2023

@TomPich I can‘t look into this as I‘m travelling at the moment. If you create an issue with reproducible examples on the GitHub repo, I‘m happy to take a closer look in the next weeks.

October 20, 2023

Native AVIF support would be great for creating performant sites. When WEBP support was added to the core, it was done as a one-off addition. AVIF could be added in the same way by accessing an $image->avif property on the image object. However — I think @BrendonKoz touched on this above — adding more alternative output formats will probably require some rethinking to keep this part of the core modular. We'll definitely see more image formats being developed in the future, and it'd be great to access them from a single property or as a single parameter with formats and fallbacks, e.g. $image->url(300, ['format' => 'webp,png']).

Sign In

Profiles

Forums

Store

Posts posted by d'Hinnisdaël