wbmnfktr

I don't want to downplay anything here but... how often do you all see FOUC in PW admin? I just started to look closer while admin pages load/reload... but to be honest... I see only some minor reflow issues here and there but nothing that annoys me. Right now I'm working on three different systems... local (Laragon) Remote (webgo) Remote (Dreamhost) While Dreamhost is remote and kind of slow only reflow issues appear on bigger pages there once in a while. No FOUC or something similar to that. Laragon and webgo are fast and those reflow issues are gone even before I really notice them. I don't use AOS, Tracy, Lister Pro or similar modules that may cause those... FOUC issues. Nonetheless... count me in for optimizing the backend to make it even better. Tested on: PW version 3.0.123 and 3.0.130

General thoughts on this... I never installed Matomo into a subfolder on a ProcessWire website. Therefore I can't tell if this works out of the box or if ProcessWire tries to protect that folder in some way. I'd suggest installing matomo somewhere else - a subdomain for example. https://matomo.domain.tld/ - would probably be the easiest way here. After that tracking should work - unless you misconfigured Matomo or block tracking with DNT or the Ghostery extension. But... there is one thing I don't understand. You are saying "place the map in the template folders" - what map?

I wouldn't call it a bug. It's more a one-time hiccup. Fixing it takes less time than thinking about it. Or in other words: I really don't care when this happens. I know that it happens. I know how to fix it. And I know it will fix itself with the next expired session. ?

Ok... yeah, thats everything. Just log out/in and it will be ok. That's the easiest of all fixes I know for this.

The menu... which part of it? Everything or just parts? I've seen it a lot of times that I have to log out and log in again to have a full translation.

<div uk-lightbox> <?php foreach($page->images as $image): ?> <a href="<?php echo $image->url; ?>" data-alt="<?php echo $image->description; ?>"> <img src="<?php echo $image->width(120)->url; ?>" alt="<?php echo $image->description; ?>"> </a> <?php endforeach; ?> </div> I'd go this way. The first DIV shouldn't be in the foreach() loop. You also want to take a closer look at the different output strategies ProcessWire provides. You are using the delayed output method which can be confusing for beginners. Look at the direct output strategy instead. That's where my example came from. https://processwire.com/docs/front-end/output/

So.... now it works. It was an easy fix. Remove the first/namespace line from your file and it works.

Just installed the module, deleted compiled files, tried {these} {tags} in several places/templates but without success. I haven't read the whole post yet but I guess there is some small detail which is key to this feature.

Windows 10 with Brave (Version 0.62.51 Chromium: 73.0.3683.103 (Official Build) (64-bit)) and Chrome (Version 73.0.3683.103 (Offizieller Build) (64-Bit)). It works in Firefox (66.0.3 (64-Bit)) and EDGE (latest).

Just found this headline... Never mind. ?

I have never used it but you could try to hook into the fields visibility via API in some way. https://processwire.com/docs/fields/dependencies/

I like the concept and the cascade-type of navigation even though it totally confuses sometimes while clicking through the site. But that's probably just me. ? What I'd like to see - which would really help me to find my way through the site - a sitemap and a breadcrumb navigation.

Just a quick thought... Create a date field add it to journal-entry field settings: Input > Default to today's date Output format: whatever you want Change journal-entry template settings to Advanced > List of fields to display in the admin Page List > {date} Create a hook that alters the page name based on the page's date field value right after saving or publishing that page. Add additional conditions to enable custom URLs/page names. Downside would be... you have to count the days somewhere else.

Let's face something I had to deal with lately in a similar way. When it comes to things like payment, customer data and reliable processes that end in a contract of any kind... I need a solution and partner that is reliable and liable. Don't get me wrong here. I think you are good developer with lots of skills and experience but lets say someone uses one of these modules/profiles and there are critical problems with it. Either payments don't work properly in any kind, privacy flaws or whatever. Who is to blame then? Who is in charge? Where would you see yourself and your modules in this? a) Foundation/base for further development b) Full out-of-the-box ready-made solution c) Somewhere in-between I ask because of potential risks on your site. So it's absolutely not against you or your ideas but something I personally would be careful with.

Your ideas sound more like complete site profiles or ready-made applications than modules. ? Which is fine btw. As soon as there are ideas in my mind I'll post them here.

1. Try rendering the menu without $options. $menu = $modules->get('MarkupMenuBuilder'); echo $menu->render('hauptmenu'); If the markup is fine then something within your $options doesn't work or 2. Look into your menu settings within the builder. There could be some settings too. I just tried it with version 0.2.5 (which seems to be the latest version) and my menu markup is fine.

Woah... ?

Good to know. ? If I remember correctly Twitter has had a widget which did exactly that. Maybe you could take a look at their code. https://publish.twitter.com/

Well then... build your own URL shortener. You could build the links to your comments like this: https://yourdomain.tld/shortener/pageID/commentID or https://yourdomain.tld/rdrct/1123/987 Either done with a new template using URL segments that look for a page with given ID and then redirects to the full URL: https://yourdomain.tld/path/to/page/#Comment987 Maybe this is even already possible with Jumplink's wildcard/group feature.

Maybe Facebook looks for the URL's og:url and therefore changes your shared URL to the official URL. <meta property="og:url" content="http://example.com/some-category/post1"/>

Be careful here @Autofahrn and @psy. @VeiJari is talking about init.php and not _init.php. init.php ready.php finished.php Just to keep this in mind. https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/

I'd support the /site/ready.php solution as well. It seems to be the better place for hooks that don't end in a module. But there is another thing. Your hooks is tied to the published state or the action of publishing it. While testing this you have to unplublish the page first to test your hook. Had this testing issue a while back, too. ?

It could be my eyes but... ? in your second example I can't spot any difference.

That's indeed kind of a strange behaviour. What setup do you use? Laragon, XAMP,... It could be interesting to spot the root of what's causing those problems. I had once problems with Laragon while re-using previous used database names. But that's long time gone now. Regarding that setlocale mistery... there will be an upcoming multilang project and I will keep an eye on it. But for now I really can't remember any issues.

Microsoft Edge arrived in its Chromium-flavour version. For those who want to give it a try already. Right now you can download the DEV (weekly updates) and CANARY (daily updates) versions. https://www.microsoftedgeinsider.com/en-us/download/ Windows 10 needed. Windows 8.1/8/7 and macOS will follow soon.