Jump to content

New post: New PW website ready


ryan

Recommended Posts

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. ?

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

10 minutes ago, adrian said:

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

image.png.f0deaf8fe6b7656fad3833ff532e85ec.png

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. ?

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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();

 

  • Like 6
Link to comment
Share on other sites

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/

  • Like 2
Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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 by ottogal
Deleted repeated part of quote
  • Like 2
Link to comment
Share on other sites

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).

 

  • Like 3
Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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 ?

  • Like 2
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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. 

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...