Mike Rockett

Working on some modifications with the front-end before I get to the back-end side of things. Part of the new front end has an informative process that helps you select a module license (super helpful for beginners). My question is this: Should I select MIT or ISC as the default license? They are functionally equivalent, however ISC removes redundant wording from the text, and so my inclination is to lean towards that. Thoughts?

Hi Marc Much prefer this name - makes more sense. Will test it out (functionality-wise) today. You don't need to namespace it if you're maintaing compatibility with PW-legacy. I don't namespace my module files, but only everything outside of them. For example, Typographer uses two namespaces: Rockett and Typographer, both of which are imported via the PW class loader. Everything should work fine in legacy, so long as you don't use any features that are only available after 3.0.62 as legacy will probably only be brought up to speed when the next 3.x stable comes out. In terms of PHP compatibility, I make it a rule to support only 5.6+, as it is currently the oldest version with security support. With that said, my phpfmt (mentioned below) is configured to use PHP 5.4-style arrays. Some other recommendations from my side: Be consistent with spaces/tabs. Tabs are generally frowned upon on the PSR side of things, but it's really up to you, provided it's consistent. I use four spaces for indentation, and I also use phpfmt in Sublime to automatically format my code. in processForm(), you're pulling in the page title within the walls of a translation helper. As far as I know, this doesn't work, so you'll need to use sprintf to import the page title: sprintf($this->_('Saved: %s'), $this->wire('page')->title) wire is imported into the Process, so can use $this->wire(…) everywhere that doesn't have a static scope, instead of the wire() helper. Hope that helps. ?

Now that is an excellent component.

Bumping the following issue here: https://github.com/wireshell/wireshell/issues/63 - is anyone around to have a look? Seems like Distill cannot rename the file?

Can't wait to use this for something... Now all I need is a nice big client that needs multiple sites. ;-) In this boat as well. Vue is awesome! Somewhat of a paradigm shift, but fine - just the reactivity system on its own is great!

Only thing is that it is still a user experience issue because the chances of someone scrolling into the gif and seeing it half way done are pretty high.

And done. Just need to add core modules to the shared modules list that the app uses to populate drop downs. Here's a gif: https://storage.rockett.pw/~pw/modgen-gif1.gif (Edited: Inline gifs are cool, unless you can't start/stop them like in Twitter ?)

Here's a screenie of the front end:

I'm in the process of learning vue, webpack, etc, and thought this might be a good thing to work on. So I'm building a new generator. At the moment, I'm simply replicating the functionality that already exists, and I have an operational front-end working. As I dive into the back-end, I'll work on the changes mentioned above. Quick question: Currently, selecting Process as the type of module enforces it to extend Process. Should I provide the ability to extend other Process modules?

Hmm, something went awry on my blog after an upgrade from .72 to .79: Call to a member function get() on null at /site/modules/AdminThemeUikit/init.php:121: $classes['item'] = 'Inputfield {class} Inputfield_{name}' . ($adminTheme->get('useOffset') ? ' InputfieldIsOffset' : ''); Although, it must be because I updated the core before the module...? Edit: Indeed, that was the case. All fixed.

Also true - though passphrases and passwords are different beasts in themselves, and one would use them differently, in the context mentioned anyway. I generally like to have passphrases generated, and then saved to my local wallet (and then synced to my cloud wallet). As for a JS lib, I did find some, but they were a bit hectic, and one of them requires a user dictionary (doesn't come with a stock one)... Anyways, was just an idea.

Very nice - would be awesome if we could somehow integrate these kinds of passwords (for easy memorisation): https://untroubled.org/pwgen/ppgen.cgi

I see, makes sense indeed. Pity it's so difficult to style things with Tracy... Hoping we can all work on it and maybe submit a PR to Nette. Integrating it will be messy, I'm sure... bluescreen.css bluescreen.stylus

Anyways, the stylesheet attached below is an improvement over the default. It uses system native fonts, a darker header, and full-width panels: bluescreen.css

Your styles override when a panel is loaded. Here's a vid: pw_tracy_style_glitch.mp4

Have been working a new stylesheet, and noticed a small bug. The debug bar renders by default with rounded corners and a drop shadow. When you hover over it, the rounded corners disappear, along with the drop shadow, and the panel titles reduce their size... At first I thought this was my doing, but it seems to happen with the default stylesheet too...

Actually, the one just before that (240). Was pointing in the direction of you not wanting to make updates to Tracy itself every time you updated. ;-) Also true - wasn't aware he was lead on the project. So I think maybe we should approach them then...

Absolutely - and that's what makes Tracy great. I'm not a huge fan of Whoops’ sidebar style (when the left gets too long, the scrollbar breaks the dark colours between the two panes). I do prefer the Tracy layout in general. It's just a matter of making it more clean and modern.

Something about the way in which Nette operates tells me that they wouldn't accept the PR, especially due to a comment in that issue I linked to about it being non-relevant. <rant>In that thread, it is said that "Tracy has quite polished appearance", and I beg to differ. Apparently, it's also not supposed to look colourful. Red is a colour. And for some people, like myself, red is just far too vivid. Wish they'd learn something from the likes of filp/whoops.</rant>

@adrian - Thanks, didn't think of doing it like that. Though, being a 'clean coder', I still feel it's hacky, even if we were to occupy the panel... I find it really weak (for lack of a better word) of Nette to now allow changes to the design. I saw in a pull request that you mentioned making changes to the source (and that you didn't want to do it, but let's skip that part for a second). I wonder if we shouldn't use our own Bluescreen class and simply make the $bluescreen service public. Tracy releases don't seem to be all that frequent, and so changing this when you update shouldn't be a hassle. The service class could then be changed to use our own templates, which would be based on the existing ones (copy-paste-modify). For me, this seems far less hacky in terms of the output. In such a class, we could make the adjustments required (and add the PW logo in there somewhere). On another note, I see that the index.php exception handler appends the stack to the error message itself. So, when a new WireException is thrown, that red bar (or whatever colour we change it to) extends out. I'm wondering if there's a way to inspect each exception message and pass the stack into a panel, leaving only the original message in the top bar. Thoughts?

Seems that the 'blue screen' template can't really be overriden without completely overriding the $blueScreen static with our own class. :-( Edit: nope, can't override it that way either - $blueScreen is private. Edit: This issue has reference to the topic.

Thanks, but that would mean multiple scripts where there are multiple fields that use Typographer. I'd like to keep it clean, where the scripts are appended at the end of the rendered page. Now that you mentioned it though, using formatValue would actually add the hook more than once anyway (when a page contains multiple fields in use). So perhaps I'd need a hook that runs on page render and checks the page for fields that use Typographer. Also might be best to have a separate module for that to avoid autoloading the textformatter.

Awesome - will have a look-see now. I'm sure I can whip something up.

With Typographer, I need to be able to inject a script into a page but only if that page has a field that has the Typographer formatter applied to it. The module needs to apply the hook if two conditions are met. The issue is that the hook is indeed added, but it is never called. The only thing I can think of is that it might be too late to add the hook. Here's how I'm doing it: /** * Textformatter formatValue (Typographer handler) * @param Page $page * @param Field $field * @param string &$value * @return void */ public function formatValue(Page $page, Field $field, &$value) { // ... vendor stuff // Run Typographer and return the converted input. $value = $this->typographer($value); // If configured, add the clipboard-cleaning script if ($this->cleanClipboard && !empty($this->hyphenationLanguage)) { $page->addHookAfter('render', new CleanClipboardHook()); // $this->dd($page->getHooks()); // ^^ this dumps the hooks so we can see that our new hook is there (see below) } } And here's the hook data from the dd call above (collapsed for post-brevity): I've tried using a both a normal class-method (..., $this, 'hook') and a closure instead of the self-invoking hook class, but it's the same result. Have also toyed around with priority, but to no avail. Is there perhaps a better way to handle this? Or I am missing something incredibly small and simple here?