wbmnfktr

It's in the core.

Yet again curious but how does this differ to the Markdown/Parsedown Extra textformatter?

As much as I support @BrendonKozanswer... I really don't understand what you want to accomplish. Do you want to hide images from backend or frontend users? And if so... what should be the result to which? There is always the option to secure PageFiles. But.... does this fit to your task/question?

Ok... I didn't notice your usage of n in your query/selector but what @taotoo said is true. n is a placeholder for n=number/integer for the amount of entries/pages/items (however you wanna call it). It's the number of entries you want to see.

I really can't tell if this is a bug or feature, to be honest. I talked about this with @ryan and he wasn't sure either back when I found this issue. And yes, that was about at least 2 years back. So... right now... this seems only to affect PW-sites that were single-language and then were migrated to multi-language support. Which is probably the case here too. I almost never stumble over this, due to my profiles I use for new projects, but YES... it could and will be... kind of a show-stopper in a setup once in a while - as we see here. But here is the "easy fix"... never use title somewhere else outside of default templates. I know it sounds weird as re-using fields is such a common task nowadays (for good), but... I learned about the years that title is more or less not a field, rather a tool to define name-based default IDs (besides the regular page ID). I see the title field as something like fkTitle (foreignKeyTitle) which I used to use in Oracle DBs back in my agency times. Way less strict and only applicable with additional selector-queries, but... it's close enough in my use-cases. In my setups I ALWAYS use headline, subline, topline and similar fields instead of title. Especially in RepeaterMatrix to create unique jumplinks. tl;dr (my definition for the title-field) Use title in your templates but never in an ongoing or extended way like using it in RepeaterMatrix Blocks or similar. It's a system field for a reason. Almost like a human-readable ID. That how I handle it.

That's why this module is already on my TODO list to give it a try. Your website, the module, and docs look awesome so far and I can guarantee you I'll give it an in-depth look.

You can import a .sql dump into it. Or at least they say so on the website. https://announcekit.app/drawsql/changelog/import-from-sql-script-11eHo4

This could help here: https://processwire.com/docs/front-end/markup-pager-nav/#are-there-any-side-effects

Try if something changes when you disable either Autojoin or Global.

This might be the right starting point for your question: https://processwire.com/docs/front-end/include/ Never used it, but it's possible to use ProcessWire outside of its natural space.

Just an idea based on similar queries I used in the past... totally untested for your use-case. $templatesFromPages = new PageArray(); // we go from here foreach($pages->find("template=news|events|otherTemplates") as $myPages) { // add template from found pages $templatesFromPages->add($myPages->template->name); }; With this you might be able to look for this: $templates->find("name=$templatesFromPages");

It's hard to get started. It's either me or missing parts in the documentation. Not only writing the necessary code but to grasp the whole thing. I started using it and already broke a minimal setup with it - due to trial and error. So I'm learning. I probably won't need a real and fully supported GUI for that. These code hints do the trick for me know, even though they are quite verbose. Yet it won't work for most of my existing projects as I had to deal with so many fields and templates. That's were something like an initial-migrate.php file would come in handy. That's the part that's probably the most interesting for some of us as most migrations become difficult due to the missing feature that tracks necessary changes made across fields and templates. Writing each and every field and template in migrate.php feels and is super slow for me right now. Using the backend to create my fields is so much faster still. I can't image doing it for large projects to be honest. Maybe after practicing and working with RockMigrations for a longer time or after wrapping my head around it. I still feel I miss something yet I can't really say what's missing to fully understand it. Sure. But that would probably end in a ProModule of some kind and with a more broader approach in some aspects. Still we could talk about that and try to find out how this could be possible. ?

In case you are looking for a nice and easy replacement for Pages2PDF as you might face problems with it due to PHP 8 - this might help you to get started and helped me today to get a site up and running again. Thanks to @bernhard for this module. <?php namespace ProcessWire; // file: templates/invoice.php $pdf = $modules->get('RockPdf'); $pdf->settings([ 'mode' => 'utf-8', 'format' => [210, 297], 'img_dpi' => 300, 'default_font' => 'DejaVuSans', ]); // Pseudo header $pdf->write(wireRenderFile('pages2pdf/_header.php')); // Footer $pdf->set('SetHTMLFooter', wireRenderFile('pages2pdf/_footer.php')); // Body content $pdf->write(wireRenderFile('pages2pdf/invoice.php')); // Styleshee $stylesheet = file_get_contents('pages2pdf/pdf.css'); $pdf->write("<style>$stylesheet</style>"); // Actions $pdf->show(); In this example I re-use my already existing pages2pdf-templates and even CSS. It's a super simple PDF, so I really don't have to deal with page margins and such in this case. So you might want to read the docs of mPDF and RockPDF to get this working in your project. There is a lot more you can do in terms of settings and such which can be found in this post for example:

The fields- is very nice to know. This would actually do what I was expecting when adding my fields to a template. But I also understand why it doesn't by default when just using field. In regards to the question you have shown in the video, the user was actually asking a bit more. Something I asked myself as well. Let's say I want to start using RockMigrations within one of my projects it would be nice to have a migrate.php file that contains already all fields, templates and fields in templates with their settings. With that file I could copy the migrate.php file over to a new instance, make my changes and run the migration. With this in place I could clone my existing structure of templates and fields right into a totally new and clean installation. Right now I have to copy the code hints from all of my 100 fields over to the migrate.php and that's something I'd probably never do unless really necessary. For now I would export all fields the PW-way and import them in the project. The same for the templates. If I remember this correctly you had a demo of exactly that functionality in the past somewhere. RockMigrations was watching for all changes that were made and wrote it into a file. Maybe it was in RockMigrations1 or a proof-of-concept. I don't know.

Just a bit of feedback: Tested the latest version on two different sites with both template sets I work with and so far no issue or unexpected behaviour. Awesome. Thank you!

@bernhard shows us how to do this with Custom Page Classes here:

There was a similar question a few weeks back and we got it fixed as written here: In your case this would probably look a little bit more like this: // define today $today = strtotime("today"); // make $yesterday match the saved date format // in this case: dd.mm.yyyy (depends on your settings) $dateForOurSelector = date('d.m.Y', $today); // get our pages $events = $pages->find("template=eventTemplate, limit=7, eventDateField>$dateForOurSelector, sort=eventDateField"); foreach($events as $event) { // do whatever you want } Slightly different approach but should do the trick.

Now that you say that I can remember this issue. Especially when sending mails. Absolute valid point!

It doesn't work in a clean installation either. So it's not your setup. It works pretty fine without the hook though.

Look into Aliases in Google Mail - they should do the trick as well. There is a nice guide about it over on ImprovMX.

That's awesome. I hope to have time tomorrow to check it out.

Everything that offers SMTP would fit here. In case you don't send hundreds of mails a week you could just send it from your server, or setup a very own mail account on your hosting and send mails - with WireMailSMTP of course. With WireMailSMTP you could use a lot of services via SMTP - even Mailgun. Some others would be Mailjet, Sendinblue, Sendgrid and some others. Some are easier to configure than others. I personally use Mailjet's free tier on small or personal projects. The limits are totally fine with 6,000 emails/month or 200 emails per day. In client projects I most often stay with Mailjet but on a paid plan starting at around 15 EUR/month.

Just a thought/idea but... Wouldn't it be a nice addition to make the cookie banner only show up when more than the "necessary cookies" group is set in the settings? At least in Germany (which is super strict in terms of cookies and such) you don't have to accept those but only additional tracking cookies or whatever 3rd party-cookies. Do I miss a thought here? Or would this be a great addition for all?

That's what we call development here. ? A quick try for now... and it seems to work. I will try it with the old code tomorrow and let you know. Don't worry about this! I got it fixed with a different markup already. But so, if the fix works out well, this feature and most default MJML templates will work again.

Ok, so not a setting, but Regex magic. I'll look into it and will see if this fixes the issue. If so I might send you a pull request. It's not that urgent as the 1.1.2 runs pretty fine still. Update: Formatting works fine now with this change. ✓ The issue with <mj-body background-color="#efefef"> seems to come from L:366 and L:413.