Jump to content

New post: New PW website ready


ryan

Recommended Posts

Hey @ryan. I'm wondering if it would be possible to set up a repository for the new site, so that we could submit pull requests and report issues there?

Personally I'd still like to suggest some usability / accessibility related changes and fixes, but currently that's a bit difficult to do – and it basically requires me reporting the issue, and then you having to figure out how to fix it for the site. If there was a repository, we could a) reliably keep track of issues that have been fixed or closed for other reasons (avoiding duplicate reports), b) submit changes so that you don't have to do everything yourself, and c) experiment with the site with ease.

If the site has features that can't be made public, a repository containing partial site profile would of course do, but the best solution would imho be a full site that we can install locally, makes changes to, build, test for regressions, and so on. Or perhaps you could only share access on a case-by-case basis, since even GitHub now supports private repositories? ?

Thanks for considering this!

  • Like 6
Link to comment
Share on other sites

Hi @ryan, could you please add some more detailed documentation for the $page->render() method to the API docs? Currently the details are quite minimal (the method doesn't have it's own page but just a short entry on the $page documentation) and doesn't cover all the options that you describe in this post:

I guess the docs for $page->render() need to somehow pull in the PhpDoc comments from PageRender::renderPage().

  • Like 6
Link to comment
Share on other sites

The "hookable" icon in the API methods listing is almost invisible - I think it's missing a width rule:

2019-02-09_102541.png.8ffc77719903ab7e33e336d730855d22.png

Besides the size glitch, I think it would be helpful to make the meaning of this icon a bit more obvious - the single note at the top about it's meaning probably is not enough. Some ideas:

  • Add a label for the column in the table header
  • Add a title tooltip that explains the meaning of the icon on hover
  • Use a different icon than the thunderbolt - didn't the old site have a "hook" icon in this place?
  • Like 4
Link to comment
Share on other sites

  • 2 weeks later...
On 2/2/2019 at 2:39 PM, teppo said:

I'm wondering if it would be possible to set up a repository for the new site, so that we could submit pull requests and report issues there?

Any updates on this? I've been occupied lately, but spotted some details too. A seperate repo would be awesome. I've referenced the Ember kind-of-way before (including their awesome RFC process), but I also like their approach to a volunteer based website on github. Also checkout the README with other public repositories too. All community / PR merge request based.

  • Like 3
Link to comment
Share on other sites

On 1/19/2019 at 7:25 PM, Robin S said:

I might have this wrong, but isn't the important thing that output formatting be off when you get and set values? It's not enough that it simply be off at the moment the page is saved.

Doing the following doesn't solve the "problem" of output formatting...


$page->foo = $page->bar . ' baz';
$page->of(false);
$page->save();

...and so likewise some feature that automatically turned off output formatting within the save() method wouldn't be a solution either. Output formatting has to be turned off earlier in the process of getting and setting values and PW can't automatically know when to do that, so it has be done manually by the developer.

Edit: to clarify regarding getting values - output formatting only needs to be off if you are going use that value in a field you are setting.

I find that the need to set the value of one field to another field is so rare in practice that it cannot possibly outweigh the time, frustration and possible security flaws that dealing with turning off and on output formatting has caused me over the years. It is not hard to use $page->getUnformatted('field') in the rare instance when that is what I actually want to do. At least if I am unintentionally saving formatted values to other fields, it is just a mistake and not a potential security concern like outputting fields to the page that are not entity encoded is. And it certainly doesn't seem like it should be an application-terminating error.

One example I recently ran into was calling a function to send an email while in the midst of editing a page via the api. In such a case you need to remember to turn off output formatting and back on again before calling the email function (and then back off again before doing your save), or your email will be outputting unformatted fields. it took me ages to figure out why the dates in my emails were sometimes coming out as timestamps.  I use setAndSave() now wherever I can, but I do wish I could use the regular object setting syntax sometimes.

I think this is why people say that "global mutable state" is dangerous.

  • Like 2
Link to comment
Share on other sites

  • 4 weeks later...

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