wbmnfktr

Ok, thought it's something a module shows you or something like that. As @dragan already said your site is actually quite fast. There could be done something with image-loading but that's it.

What is generation time?

Never really thought about that detail but in terms of naming... Clone = I'd expect the same created/modified dates Copy = I wouldn't be shocked if those dates would be different An option in the module settings to change the behaviour could be nice - at least in your case. I can't really remember a situation in which I used those date. I almost always rely on additional date fields.

Had this happen quite often in previous versions of ProcessWire. With 3.0.123 (I guess - maybe even earlier) it worked right from the start. In those prior versions I worked out a trick somehow. Therefore I created another textarea field, added it to the template, changed the field's settings to use the same myStyles.js and all of a sudden it worked. In some cases using another browser or private window, resetting the whole cache and cookies worked as well. And sometimes I just tinkered within the wrong fields, didn't save my files or was on a wrong instance.

Sounded good at first but ok... you worked it out in another way-

Can't test right now but does that help? returnRelative (bool) Make returned array have filenames relative to given start $path? (default=false) https://processwire.com/api/ref/wire-file-tools/find/

Ok... never dealt with that actually.

In terms of frontend stuff I always use /site/templates/styles/myCSSfile.css or as I use ProCache most of the time mySCSSfile.scss. Never had the need to make it dynamic as the folder is always the at the same place. In modules it might be different but as my modules are more or less quite basic and without CSS never had to deal with it there.

I challenged myself for something similar in the past but ended that due to my lack of knowledge in JS/AJAX handling. The thing I mentioned before was done with Angular JS - and a third-party developer involved to do that magic - and I re-created the JSON he needed in PW-page/queries. If it's ok I will dig through to my archives the following weekend and look for the templates/JSON I created for that project. It will not be perfect for your things but maybe it gives you an idea somehow.

Ok... I get it. Well... sessions are sometimes a thing on its own. In some settings my sessions live forever and sometimes they expire right away.

Same here... I just did my own thing then and created a template for that where I did what I wanted to create. I build the whole JSON based on the things I needed and it worked out quite well. It was easy to cache as well which was a benefit back at that time. I neither worked with sub-pages, nor AJAX but with a repeater field that contained a page reference (Occupation - in your case) and a text field (for more details about that if needed). Therefore I had everything in my object (a product in my case) and could iterate over every item (product) I defined by an URL. It looked similar to this: domain.tld/api/{object}/{identifier} or domain.tld/api/product/9876 Maybe I have still access to some of the files and post some snippets here. Just in case... what will be the result of this whole setup. Just to get in the right context.

What did you do in/with your hooks to mess with ProcessWire sessions?

Wow... that's way more text than you see on most Squarespace pages. ?

There is an example in the _main.php of the Multilanguage Site Profile. You can see it here: https://github.com/processwire/processwire/blob/master/site-languages/templates/_main.php#L65

That could become a problem then. You should add it as a requirement to the module nonetheless. ? Not needed when everything was set up correctly with this things in mind. You know about that and do the necessary things. I'm relatively new to this setup and had to work through this. Now I know too. It is. Actually it could make other things easier when debugging. As I see some weird strings instead of domain(.tld) now I don't falsely think of domain names and such things. I know right away it's something different and where it comes from.

An additional sitenote here: Changing the root name to something different than the domain is not enough. If that page name appears anywhere else at the end of an URL the hiccup is back. root = abelt Problematic page URL = /about-abelt/ Problematic page URL = /about/abelt/ Working page URL = /about-abelt-whatever/ As to make sure I don't run into any issues with this I changed my root page names to something a cat would write while walking over the keyboard. An additional sitenote here: Changing the root name to something different than the domain is not enough. If that page name appears anywhere else at the end of an URL the hiccup is back. root = abelt Problematic page URL = /about-abelt/ Problematic page URL = /about/abelt/ Working page URL = /about-abelt-whatever/ As to make sure I don't run into any issues with this I changed my root page names to something a cat would write while walking over the keyboard.

Keep an eye on that file. It will save you lots of time knowing about it. Believe me. ?

That did the trick perfectly! Changing root and the page names fixed it. Didn't really get that the page's name doesn't have to be the domain actually.

It works aside from that redirect issue so... I guess I will survive. ? PW 3.0.130, Multisite Module from Github (says 0.1.2), 3 domains, 2 languages on Linux (Ubuntu), Apache 2.4, PHP 7.2 Page tree: config.php $config->MultisiteDomains = array( "abelt.test" => array( // domain name is used to map to root page "root" => "abelt.test", // page name for the root page "http404" => 1031 ), "alexander-abelt.test" => array( // funktioniert nicht mit /en/ auf Home "root" => "alexander-abelt.test", "http404" => 1029 ), "kettenburg14.test" => array( "root" => "kettenburg14.test", "http404" => 1030 ) ); $config->httpHosts = array('abelt.test', 'alexander-abelt.test', 'kettenburg14.test'); // $config->httpHosts = array_keys($config->MultisiteDomains);

Ok... I see the problem. alexander-abelt.test shares one of the other domains abelt.test in it which I can't really avoid as these are or will be my domains (just with another .tld of course) I want to use later on. As this has no further effects on maintaining content, building menus and whatever so far I guess I can ignore that linking/redirecting issue for now. Thanks for pointing that out.

Maybe I'm missing something here but I ran into minor problems setting this up for domains that contain a hyphen. First of all the setup is multisite AND multilanguage. PW 3.0.130, Multisite Module from Github, 3 domains, 2 languages Link from ProcessWire Backend: http://abelt.test/en/alexander-abelt.test/ gets wrongly redirected to http://abelt.test/en/alexander- and not to http://alexander-abelt.test/en/. In this case it's not a real deal-breaker as it's only a setup I need for some of my domains and I know how to work around this but nonetheless I'd like to know if I have to change something or if it is a hiccup here.

Have you tried something like this? 'onsubmit' => "ym(53558719, \'reachGoal\', \'form_question\'); return true;"

Showing user-specific content based on an URL might not be that kind of a good idea. As your users are known and therefore must be logged in you should go the PW route and create pages->find() queries and/or conditional statements based on the user details you have. It's much more secure as well.

Maybe your lazyCron is locked. Look into your /site/assets/lazycron/ or in /site/assets/ folder. Don't know the exact path and name right now. There should be a lazycron file and maybe even a lazycron.locked file. The last one prevents LazyCron from working due to an error that occured before.

They want me to log in so I postpone this for a moment. I saw one or some playlists with similar content on YouTube a while back. Maybe I can find them. There are so many good curated playlists actually.