ottogal

Very interesting sites, thank you!

For me (on Win 10, Firefox) Segoe UI looks good. Of the Typekit fonts I'd prefer benton-sans too. There's a typo in the link to the Krub version above: https://processwire.co/newsite/?font=krub should read https://processwire.com/newsite/?font=krub

A direct comparison shows that typographically Kurb is way better than Barlow. Sigh.

An observation: The title of the newsite homepage is An open source CMS with a powerful API: ProcessWire CMS while it was ProcessWire CMS: An open source CMS with a powerful API before. Given that bookmark lists are using the titles (which often get truncated) the latter version should be kept.

Just stumbled over the fact that using this color attribute in the URL makes some links not working anymore. Examples: 1. On the page https://processwire.com/newsite/docs/selectors/?color=1144DD, clicking the submenu item Selector fields results in this bad URL: http://processwire.com/newsite/docs/selectors/?color=1144DD#fields?color=1144DD 2. On the page https://processwire.com/newsite/docs/modules/hooks/?color=1144DD, clicking the submenu item About hooks results in this bad URL: http://processwire.com/newsite/docs/modules/hooks/?color=1144DD#about-hooks?color=1144DD

Really overwhelmed by the incredible efforts by you, @ryan, and the community! Many thanks! My two cents on colors and contrast: Making the blue background darker would increase the readability of the white text on it (and of the h3/h4 headlines on white) - and it would reduce the irritation on totally blue pages like the blog. I'd propose https://processwire.com/newsite/?color=1155DD. And, please: Make the body color darker, say #333333. Reading text with too low contrast ist very tiring. Two more remarks: I like the font "Krub" - it's looking fresh and modern, like PW is - whereas the font "Work" looks oldfashioned to me. But of course, if a font is not rendered well on some platforms, it's not an option. I'm not sure you should show an image of the iMac (despite the pride owning one...). At least I would remove the foot of it, so it's brand is a bit less obvious. Again: Thanks and compliments!

Thank you @kongondo for this information. That shows the exemplary security awareness of @ryan in all his work! One of the reasons that makes us glad using PW...

@bernhard You're right, my comment really sounds a bit weird, and I apologize for that. (I became aware of that soon after having posted.) Of course, if someone uses a flag to indicate the German language, it's not "wrong" to take the Austrian one and not the German one - both are equally suitable for this purpose, or unsuitable. Just because of a possible ambiguity of this kind they both are unsuitable - that's the point of my remark. I also apologize to @Gadgetto: My intention was not to criticize, but to give some well-meant advice.

https://processwire.com/talk/topic/13196-adding-image-field-to-language/ containing a link to http://daily.unitedlanguagegroup.com/stories/editorials/inside-design-language-selector-no-flags https://processwire.com/talk/topic/16524-extending-languages-template/ containing a link to http://www.flagsarenotlanguages.com/blog/why-flags-do-not-represent-language/ https://processwire.com/talk/topic/14241-language-names-and-utf8-page-names/ Please take these concerns earnest.

Hi Gadgetto, two remarks: (1) Your very first animated GIF shows the wrong flag for Germany: It's the flag of Austria - a German speaking country, that's true. This is a great example for the following insight: (2) It is not the right way to distinguish languages by flags! There are some threads here in the forum where this question is discussed. When I find some link, I'll share it.

Done.

Thank you for the clarification. Shouldn't that response be replaced by a less irritating message?

Hi all, on the Module Information page of Process Tracy Adminer, when I click the link "check for updates" I get this message: What's going wrong? Thank you for hints. (PW 3.0.105, Tracy Debugger 4.14.11, PHP 7.0)

Maybe something like this:

That was not my intension, sorry. I never saw it like that - I always had to remove the unused profiles manually.

You select it by renaming the folder "site-blog-editorial" to "site". (The other site profile folders you may delete.)

I don't see the point here. Editing a page in PW, the page tree is just one click away.

Hi PhotoWebMax, this could be just a cache issue, I presume. BTW, there are quite a few former MODX users in this community (like me and you - I remember your contributions in their forums years ago - , and of course kongondo and others. What I'd like to say: Don't let you get discouraged in using PW just because of some fiddling issues with a gallery script which will be solved and have nothing to do with PW. Having found PW several years ago I quit using MODX from one day to the other and never looked back. Good luck!

Nope: That doesn't help since you are finding the tasks, not the projects. So instead of creating a new PageArray you better create a normal PHP array $matching_project_IDs and add the IDs of the matching projects: $matching_project_IDs[] = $task->parent->parent->parent->id;

If you have really many projects, to avoid loading them all into memory you should use findMany() instead of find().

Given your Page Tree structure, the following should be possible - assuming the Tasks have a common task_template with the field assigned_to_user: $matching_tasks = Spages->find("template=task_template, assigned_to_user=user1"); Smatching_projects = new PageArray(); foreach ($matching_tasks as $task) { $matching_projects->add($task->parent->parent->parent); };

Have a look also to the section on Sub-selectors in that doc. So this should do it: $matches = $pages->find("template=group, children=[my_int_field=0]"); And for the other case: $groups = $pages->find("template=task,parent=[closed=0]");

In the API Reference: https://processwire.com/api/ref/page/children/

Just guessing: The second scenario should be possible with $matches = $pages->find("template=group, children('my_int_field=0')"); And the first one (even more guessing) with $groups = $pages->find("template=task,parent().closed=0"); or $groups = $pages->find("template=task,parent()->closed=0"); Or, more likely: $groups = $pages->find("template=task,parent(closed=0)"); Not sure at all. (Couldn't test it by myself.)

About the distinction between a template and its fieldgroup you can read in the API Documentation: See the last section "Using Templates and Fields from the API" from http://processwire.com/api/variables/templates/.