PW 3.0.60 core updates

[ryan]

This week we have ProcessWire 3.0.60, which is likely to be our next master version. We’ve also got a few more Pro module updates, as well as a major update to our online API reference…

https://processwire.com/blog/posts/processwire-3.0.60-core-updates-and-more/

 

[Robin S]

Thanks for the documentation updates!

The text/background contrast in the code blocks is a little low - could the background be lightened, or text colours darkened? Or maybe switch to a dark theme for the code blocks? Thanks.

[adrian]

@ryan- the API Explorer has some space issues:

For example, "directly on" from the docs below is getting displayed as "directlyon"

     * This is the same as calling `$pages->save($page);` or `$pages->saveField($page, $field)`, but calling directly
     * on the $page like this may be more convenient in many instances.

This is obviously just one of many instances like this.

[adrian]

@ryan - another thought - could the API reference docs on the website link to the appropriate lines in the code on Github? Obviously the link would have to be to the exact commit that was used to generate the docs, but I don't expect that should be hard to implement.

Also, even though I don't have the API Explorer module, I would still like to suggest implementing an editor protocol handler link so that users could click to open to the appropriate link in the code in their favorite code editor. I do this with the Captain Hook panel in Tracy and find it fantastic.

[szabesz]

Minor stuff: https://processwire.com/download/ is still displaying 3.0.59 DEV

[asbjorn]

When clicking on Save + View , the system adds ?s=1&c=0 on the end of the URL. Is that related to some changes in 3.0.60?

[adrian]

18 minutes ago, laban said:

When clicking on Save + View , the system adds ?s=1&c=0 on the end of the URL. Is that related to some changes in 3.0.60?

?s=1 has always been there, but yes, c=0 is new:

https://github.com/processwire/processwire/commit/75a969bafbd95143013f015c3e726d82087cc68a#diff-18988bf581321686eb798ec4f657506fR1455

[asbjorn]

I've only ever seen ?s=1 back-end when saving before, not front-end when clicking Save + View.

[adrian]

2 minutes ago, laban said:

I've only ever seen ?s=1 back-end when saving before, not front-end when clicking Save + View.

Ah yes - sorry I missed the importance of "View" - that definitely seems odd and a bug - do you agree @ryan ?

[ryan]

Quote

For example, "directly on" from the docs below is getting displayed as "directlyon"

Thanks–fixed.

Quote

another thought - could the API reference docs on the website link to the appropriate lines in the code on Github? Obviously the link would have to be to the exact commit that was used to generate the docs, but I don't expect that should be hard to implement.

The API reference is already showing all the docs available for each method, so linking to line numbers would focus in on the actual code/implementation behind the method, rather than the documentation. When it comes to docs, it's about the interface, not the implementation. The interfaces rarely change, whereas the implementations change all the time. Coding towards something other the method's interface could be problematic. That's why I think the code-behind-the-method probably shouldn't be part of the documentation, except maybe in cases where the docs suggest looking at the method directly. 

Quote

Minor stuff: https://processwire.com/download/ is still displaying 3.0.59 DEV

This refreshes once every 24 hours. 

Quote

I've only ever seen ?s=1 back-end when saving before, not front-end when clicking Save + View.

This is not intended, I'll fix this–thanks. Btw the "c=" indicates number of changed fields when possible, but mainly c=0 means no changes, and c=1 means there were changes.

 

 

[Michael Murphy]

Why are the modules not listed on the public reference page? for example the MarkupPagerNav is listed (under Additional) but the MarkupPageArray, and many more of the core modules are not (although they can be browsed in the Pro module). 

Also I agree with @adrian - the ability to see where the file is located and quickly open it would be helpful for learning  (see @adrian implementation in the Tracy debugger module). If the API explorer could be used to document our own templates, CSS, SAAS, JS etc. files, this "edit / open file" feature would be useful when collaborating with other developers and might also be a good way for new users to learn about PW from site profiles.