New post: New PW website ready

[Robin S]

17 minutes ago, adrian said:

My only other thought is when would you want to actually set a field value to a formatted version? Could setting always apply unformatted values?

You wouldn't ever want to set a formatted value, but for a lot of cases there's no easy way for PW to detect if value X being set to field Y is formatted or not. Think of scenarios where the value being set to a field is some variable that has been built up earlier the dev's code. If the formatted value is a different type of data than the unformatted value (e.g. object vs string) then maybe PW could detect that but there are lots of cases where the formatted and unformatted values are both strings but with one or more textformatters applied to the formatted value.

I think we need another nice verbose documentation page explaining output formatting because it's definitely not a simple thing to get one's head around. ?

[Robin S]

10 minutes ago, adrian said:

I have an interesting scenario for you though. Say you try this:

It's sort of breaking a cardinal rule in the first line though. If people overwrite core API variables then confusing error messages would be just the beginning of their troubles. ?

[adrian]

2 minutes ago, Robin S said:

It's sort of breaking a cardinal rule in the first line though. If people overwrite core API variables then confusing error messages would be just the beginning of their troubles. ?

Of course, but even if you haven't overwritten $page, if you are using page() and you get a message to do $page->of(false) it is still confusing.

[Robin S]

5 minutes ago, adrian said:

if you are using page() and you get a message to do $page->of(false) it is still confusing.

True. Although the code suggested in the message would still resolve the issue so long as you haven't overwritten $page.

If things go in the direction that I think Ryan has hinted at of the Functions API being the new default approach then maybe we'll see message references to API variables start switching over to the Functions API equivalents.

[adrian]

I have mentioned this one before, but I think it's weird that we have a $urls variable, but not a $paths variable.

With the functions API we actually have both urls() and paths() which seems like a weird inconsistency to me. Is there a reason for no $paths variable?

Even the docs (https://processwire.com/api/ref/functions/paths/) suggest:

// basic usage
$paths = paths();

 

[adrian]

No idea why, but https://processwire.com/: results in a 404 page without any loaded assets. In fact a semi-colon in any url causes the same result.

Actually it seems like it's a procache issue based on the pwpc errors in the console.

[Robin S]

In the API documentation, for some reason all the methods under any of the Core Classes (e.g. Fieldgroup, Template) are trying to link to pages under the "Page" documentation - often linking to pages which don't exist.

For example...

Fieldgroup::getTemplates() links to: https://processwire.com/api/ref/page/get-templates/

Templates:getNumPages() links to: https://processwire.com/api/ref/page/get-num-pages/

[adrian]

Hey @ryan,

Just wanted to say a big thanks for making all those API examples on the home use the same approach, eg $page and $pages, and also for changing the image and save ones so they will work without errors. 

Thanks for listening to the community on this and sorry if it seemed we were hassling you ?

Just one possible suggestion, although I am really not sure if this is a good idea or not. What do you think about:

$page->headline_OR_title

or:

$page->{'headline|title'}

or:

$page('headline|title')

instead of:

$page->get('headline|title')

For some reason these just seem to fit better to me when it comes to accessing a page's field values because I think of "get" and "find" as being more about getting a child/children of the page with a selector, rather than output a field or property of the page.

Maybe it's just me though ?

Did you have any thoughts on the idea of a sandbox console for users to play with?

[ottogal]

4 hours ago, adrian said:

$page->{'headline|title'}

or:

$page('headline|title')

 

I'd prefer the first variant over the second, because the "->" is more suggestive if concatenating in several steps like  $page->{parent}->{'headline|title'}.

(This concatenation syntax, adapted from JQuery, was it to draw me into PW some years ago, because of its intuitive comprehensability.)

The second variant instead could be, I think, even confusing, since it differs from the function version  page('headline|title')  just in the $ character.

[ottogal]

@ryan  On the Docs' page The $pages API variable, the first red link $pages API methods  is linking to the page itself

(instead of https://processwire.com/api/ref/pages/ ).

[adrian]

5 hours ago, ottogal said:

The second variant instead could be, I think, even confusing, since it differs from the function version  page('headline|title')  just in the $ character.

Just in case you weren't aware, the second approach of $page('headline|title') already works. It was documented in a blog post some time ago, but I can't seem to find it at the moment. It even works like $pages('template=basic-page') etc. Basically variables that act like a function.

The other option we have which I had actually forgotten about is:

$page->headline_OR_title

 

[adrian]

@ryan - just found another "Internal Server Error" on the new website for you:

https://processwire.com/search/?q=%24page(

You can get to this by typing:

$page( 

in the live search and hitting Enter

[ottogal]

1 hour ago, adrian said:

You can get to this by typing:

$page( 

in the live search and hitting Enter

It's the same with any search term ending with the open bracket, f.e.    config(  - with or without $.

Edit: Not an issue of the missing closed bracket: Same with   config()  etc.

[ottogal]

1 hour ago, adrian said:

Just in case you weren't aware, the second approach of $page('headline|title') already works. I was documented in a blog post some time ago, but I can't seem to find it at the moment. It even works like $pages('template=basic-page') etc. Basically variables that act like a function.

Wasn't aware of that - but found the blog post:

https://processwire.com/blog/posts/processwires-roadmap-in-2015/

 

1 hour ago, adrian said:

The advantages of using this _OR_ syntax are explained in this blog post:

https://processwire.com/blog/posts/processwire-3.0.40-core-updates/#getting-one-field-or-another-from-a-page

Edited January 23, 2019 by ottogal
Deleted repeated part of quote

[KarlvonKarton]

The new website is OK, but the docs are unreadable for me.  The contrast of the black code background with the white pages make my eyes hurt like crazy...  Fix that please!

[szabesz]

38 minutes ago, KarlvonKarton said:

The contrast of the black code background with the white pages make my eyes hurt like crazy

I have already mentioned this in the comment section of the very first blogpost of Ryan showcasing it. Luckily I use the Dark Reader chrome extension to browse most sites anyway, but it would be nice to see a lot less contrast. Better yet, a native dark mode for the site would be welcome. We have just been presented with a nice example: https://processwire.com/talk/topic/20584-schwarzdesign/ (click the sun icon of the site in the top right corner).

 

[psy]

Found this today: Wild, weird and out there, it's a big bonus to making PW sites more accessible... https://websitevoice.com/ 

Talk to me ProcessWire ?

[adrian]

@ryan - unfortunately the reply nesting / order of comments on the blog posts has been messed up during your import to the new site which makes things hard to follow. it would be great to get these reimported in the correct order and with the correct parent comments.

[teppo]

20 hours ago, psy said:

Found this today: Wild, weird and out there, it's a big bonus to making PW sites more accessible... https://websitevoice.com/ 

Talk to me ProcessWire ?

That's a nice find, and I believe that a tool like this would indeed be a nice addition for users that don't generally require a screen reader.

That being said, those who do require such assistive technology will already most likely have their own individual setups, and a separate tool won't really help – so the accessibility argument is somewhat questionable. Perhaps even misguided, since it may give some folks an impression that this is enough to take care of all screen reader related accessibility needs.

Accessibility, particularly referring to screen reader users, is not just about enabling "text-to-speech voice for the relevant content" (at least the way I understand their selling point), but rather about making sure that the entire user experience takes screen reader users into account. In other words: providing a read-out-loud button for the main content is not enough, if some users can't even navigate the site with ease ?

[psy]

@teppo totally agree. It's definitely not the answer to accessibility for the visually impaired. All sites should be readable by screen-readers. It's just another tool in toolbox and a nice addition ?

[adrian]

@ryan - not sure how many of these there are, but I think there are possibly lots of broken links from the PW admin to the new website, for example:

The "how to use this" 404s.

 

[adrian]

Also, on https://processwire.com/docs/fields/dependencies/ you have a couple of links to the form builder module, but these are linking to http://modules.processwire.com/modules/form-builder/ instead of the new https://processwire.com/store/form-builder/

[dragan]

1 hour ago, adrian said:

The "how to use this" 404s.

I can confirm this. Just stumbled over this today myself.

@ryan

I wonder if there's a central place where we can report such outdated links? (like a JIRA ticketing system)

I pointed to a (probably forgotten) Hanna-Code in the docs a few days ago, which was supposed to load an iFrame or screenshot from somewhere (but nothing was rendered anymore), but I guess it was overlooked.

On another doc page there is a TOC link which isn't valid anymore*; where can we post such issues and can make sure you will actually see it? I fully understand that a scattered bunch of forum posts is not the ideal way to handle such scenarios.

* Example: https://processwire.com/docs/fields/dependencies/#themes - the corresponding chapter is not there anymore.

[ryan]

Quote

I wonder if there's a central place where we can report such outdated links? (like a JIRA ticketing system)

Feel free to keep reporting here. I am checking in here for errors like this every few days and then fixing them as they come up. I'm guessing not too many more of these will turn up, as I've been continuing to update the logic in our 404 hook, plus logging 404s in ProfilerPro to catch any others that might have been missed. 

[dragan]

Here are some minor glitches whenever you use <pre> for mixed HTML + PHP code: https://processwire.com/blog/posts/functional-fields/

html probably shouldn't be visible before <button> ...