Dev meeting 2017 01 31

Agenda

• Bolt 3.3 beta status (@Bob)
• Local ext replacements
  • Mainly, what's needed to get #6327, #6324 in? (@Bob)

e.g.

• Status on drop bear invasion (@YourGitHubID)

Actionable Items

Outcomes

Log

<gawainlynch> ping Bopp carsonfull rarila rossriley SahAssar slick0_ rixbeck gawainlynch 
<SahAssar> pong
<Bopp> pong
<gawainlynch> Looks like it's you and me mate, maybe we should go for #beer instead 
* [BoltIssueBall] $this->app['bartender']->setDrink('beer')->setTab('gawainlynch')->serveAll();
<rossriley> i need beer too
<SahAssar> hehe, at least the bot can handle some of todays meeting
<gawainlynch> Indeed … OK, key players signed in, lets roll
<hExDJ> there's a meeting? :-)
<gawainlynch> beta
<gawainlynch> Local ext replacements
<gawainlynch> Mainly, what's needed to get #6327, #6324 in? (@Bob)
-[BoltIssueBall]/#boltcms- #6327 [closed] Base Directory Fixes for Local Extensions https://github.com/bolt/bolt/pull/6327 
-[BoltIssueBall]/#boltcms- #6324 [open] Add support for extension definition in bolt.yml file https://github.com/bolt/bolt/pull/6324 
<Bopp> Build process works like a charm again. 
<Bopp> one of the two is in. 
<rossriley> I’m done
<rossriley> just working out how to handle the error exception
<Bopp> Noice !
<gawainlynch> Ah, would it be better to class_exists() and throw the exception ourselves?
<gawainlynch> Oh, just thinking about it too, Ross … don't worry too much on PHP 5 about the error, if debugging is on it gets converted anyway 
<rossriley> ok, fair enough… but there’s also an error if it doesn’t implement the interface...
<rossriley> but yes, you can call class_exists with an autoload flag too
<gawainlynch> Yes, that point we'd could throw an exception
<gawainlynch> Without going all CDO on it, really what we want to achieve it to make it easy to see your own mistakes, as you're already over the rest 
<gawainlynch> But yeah, get that in and move on
<gawainlynch> Oh, and a big thank you to rossriley & Bopp for stepping up to take over BoltForms & Members for me
<gawainlynch> Does anyone have anything to raise?
<rossriley> nothing urgent….
<Bopp> Nope, 
<carsonfull> here!
<rossriley> I want us to have a serious attempt at phasing out Templatefields in Bolt 4
<gawainlynch> Oh, I heard back from CodeClimate and Scott is going to PR us the base configuration file… and probably jump on Slack at some point to touch base with us
<gawainlynch> #karma rossriley 
<[BoltIssueBall]> Sorry but karma can only be added for channel members, rossriley isn't here and they lose out!
<gawainlynch> #karma rossriley 
<[BoltIssueBall]> Sorry but karma can only be added for channel members, rossriley isn't here and they lose out!
<Bopp> when this is in, i'll do more monkeytests on beta 3. 
<carsonfull> Wait we don't like template fields?
* gawainlynch frowns at the bot
<Bopp> and I'll add a bunch of stuff to the docs for local ext replacement, to make them dummy-proof. 
<Bopp> So that even I can work it out. 
<gawainlynch> carsonfull: They are a troublesome PITA
<carsonfull> Crap we use them at GMO a lot
<rossriley> I obviously want to make sure everyone has the same functionality
<rossriley> not just delete and leave people high and dry
<carsonfull> We need something for the "one-off pages"
<SahAssar> carsonfull: #5545
-[BoltIssueBall]/#boltcms- #5545 [open] [RFC] Successor to templatefields https://github.com/bolt/bolt/issues/5545 
<carsonfull> k
<SahAssar> It's looking awesome
<carsonfull> Ah ross you beat me to some config changes
<rossriley> oh carsonfull there’s a tiny bug in the syncAssetsDirectory method
<rossriley> let me just look it up
<gawainlynch> I think I fixed that in a PR yesterday 
<gawainlynch> No, that was Env
<rossriley> ah ok… Environment::syncAssetsDirectory()
<rossriley> $source = $this->boltPath . 'app/view/' . $dir;
<rossriley> needs an extra slash before app I think….
<gawainlynch> #6329
-[BoltIssueBall]/#boltcms- #6329 [closed] Add a missing slash https://github.com/bolt/bolt/pull/6329 
<rossriley> ah, excellent
<rossriley> ignore my tardy bug reoprt then
<gawainlynch> We were thinking the same thing :-)
<carsonfull> https://github.com/bolt/bolt/pull/6331
<[BoltGitHubBot]> [bolt] CarsonF opened pull request #6331: Extension tweaks (release/3.3...extension-tweaks) https://git.io/vDtX4
<carsonfull> I have concerns about the error handler leaking debug info in production. Can we talk about it?
<gawainlynch> Just looking over it
<gawainlynch> But fire away 
<carsonfull> Separate from that PR
<Bopp> *pew* *pew*
<gawainlynch> #karma Bopp 
<[BoltIssueBall]> Sorry but karma can only be added for channel members, Bopp isn't here and they lose out!
<Bopp> Haha
<gawainlynch> Ugh … 
<Bopp> @carsonfull In 3.3 still? I've made a bunch of changes to that. 
<carsonfull> No not that exception stuff
<Bopp> Ah, ok :-)
<carsonfull> We set debug=true error handler in bootstrap.php and Application. The debug only gets turned off at boot
<gawainlynch> Yeah, I've not figured a away around that either 
<carsonfull> So any error in registration loading gets thrown with debug info
<carsonfull> Also the DebugClassLoader which is not as performant
<carsonfull> Open to ideas but we need somehow to to force the user into it
<carsonfull> not to*
<carsonfull> Also for multiple runs (like tests) it doesn't make sense to add the error handler
<carsonfull> So I'm thinking at least removing it from Application / Service Provider
<carsonfull> And if I need to run a custom bootstrap to prevent the one in bootstrap.php from firing I can do that too
<gawainlynch> I gotta fire up PS
<carsonfull> It's a hard problem, because we need to know basically immediately we are in debug or not
<gawainlynch> Yeah, hence why Symfony don't do what we do 
<carsonfull> You're talking about separate entry points?
<gawainlynch> Yep
<carsonfull> Can we do that? 
<carsonfull> index.php == production
<carsonfull> dev.php == debug
<carsonfull> That doesn't break current installs, but defaults to secure and performant mode
<SahAssar> That sounds good to me
<gawainlynch> carsonfull: That would only be relevant for pre-boot handling, correct?
<carsonfull> Yeah
<carsonfull> I think
<carsonfull> Well no
<carsonfull> just depends
<gawainlynch> Sound more like a break to certain groups (as much as I like the idea)
<carsonfull> Only with error handling
<gawainlynch> Error, or exception or both
<carsonfull> right
<carsonfull> both
<rossriley> bopp, one for you to look at: https://github.com/bolt/bolt/pull/6096/files#diff-b0666fa264092eada1a5d5a18c75a4faL45 in that PR the call to the unique helper got removed…. was that just accidental or some more behind it?
<Bopp> @rossriley Checking..
<gawainlynch> So I would put my archive on a shared host, not have a crucial PHP extension enabled or the like, don't know how to alter the index file … but I should know how to add /dev.php to the URL
<Bopp> @rossriley I think that was accidental, but would need to verify.. Are you bumping into issues? 
<rossriley> what that did was pushed the selected values to the top of an array of options, so that sorted/selected values stayed in the order they should be
<Bopp> Ah, ok! I'll open a quick issue, and restore that line.
<carsonfull> @gawainlynch how to archives get updated?
<rossriley> eg, if you had selected and sorted [f,e] and the available options were [a,b,c,d,e,f] then the options were rendered in order [f,e,a,b,c,d]
<carsonfull> @gawainlynch what about an env variable? if BOLT_DEBUG=true 
<gawainlynch> carsonfull: Depends … some people might rename the composer.json.dist file, some people just unpack an archive file on top
<gawainlynch> carsonfull: Well, that's the thing while I was rambling my response out … really all they'd need to do is move from http://example.com to http://example.com/dev.php
<[BoltGitHubBot]> [bolt] bobdenotter opened issue #6332: Removed `unique` in options needs to be restored. https://git.io/vDtyq
<carsonfull> Yeah but that's gross. I don't want the urls to change
<gawainlynch> Me either, and we couldn't have it in the web root 
<gawainlynch> (by default)
<carsonfull> Have what?
<gawainlynch> dev.php
<carsonfull> Why not?
<SahAssar> cause then we'd leak debug info for everyone using the default structure, right?
<gawainlynch> Because every time you updated your Bolt install you'd ^ that
<carsonfull> Ah right
<carsonfull> env var then
<gawainlynch> No shell on the host
<SahAssar> But the env var will have to default to true then, which leaves us back on square one for 95% of people
<carsonfull> env var file then
<carsonfull> no the env var will default to false
<gawainlynch> Early read of config.yml
<carsonfull> Nope. path is configurable and way too much logic before error handler
<gawainlynch> Fair call
<gawainlynch> .bolt.yml
<gawainlynch> (just brainstorming btw)
<carsonfull> I thought that too, but then the file has to have logic to change between dev and production
<gawainlynch> Darn it, when did I ask you for logic? :-P
<gawainlynch> As in replying with sensible logic 
<carsonfull> I know lol
<carsonfull> Ok so there are lots of options for people with multiple environments. They can configure their own web servers and blah
<carsonfull> So the problem is people with one env and no shell access
<gawainlynch> Yeah, a sizeable chuck of our novice user base
<carsonfull> Let's default debug to false and then have it overriddable to true in .bolt.yml. 
<carsonfull> Doesn't change between envs but they don't care about that
<carsonfull> Then for us that can control then environment we use an env var
<gawainlynch> Bopp: You've been very silent on this … thoughts?
<Bopp> As far as i can follow it has no real impact on my common usecase, right?
<carsonfull> With my current thought, you would have to opt-in to debug mode now
<Bopp> Hmm, kay.
<carsonfull> I mean I guess we could flip it...
<SahAssar> Well, pre-boot debug, right? After boot the config setting takes over, right?
<carsonfull> Yeah
<Bopp> That means beginners would see _less_ errors, and be more confused.. I don't think i'd like that
<carsonfull> Ok let's change the key name too as debug would be confusing
<Bopp> Can it still "default" to true _after_ pre_boot? 
<Bopp> if so, it'd be no problem for those users.
<carsonfull> .bolt.yml can have dev=false which then would look for BOLT_DEBUG env var
<Bopp> yeah, but adding options makes it more confusing to all. 
<carsonfull> Yeah I mean anything preboot would be autoloading errors or errors in PHP service providers
<Bopp> ok
<carsonfull> So novices could still run into it
<carsonfull> Also if extensions have problems
<Bopp> but, wait.
<carsonfull> actually that's not true
<carsonfull> extension come after
<Bopp> no, wait, this is not an issue.
<carsonfull> ?
<Bopp> https://github.com/bolt/bolt-distribution/blob/master/include/functions.sh#L165
<Bopp> During the packaging I set some setting for the .zip and .tgz version for the novices. 
<Bopp> I can easily flip the debug: false to true in there too 
<carsonfull> Right but those aren't even applied at this point 
<SahAssar> Bopp: But that's only post_boot
<Bopp> Then it can be false in the repo, and composer installs, and true for those users. 
<carsonfull> no, we can't use anything in config.yml for this
<carsonfull> But I'm thinking
<Bopp> Ah, ok.. that's too bad. 
<carsonfull> There's way less happening pre-boot now in 3.3
<carsonfull> Previously config and other services were loading
<gawainlynch> :-)
<Bopp> heheh
<SahAssar> Isn't the root problem that we actually want the boot debug to be on during the first install, and off after we have verified that the install is working? So if we could check if a successful boot has already been performed that'd fix it, right?
<SahAssar> (for shared/crappy hosting that is)
<carsonfull> This may be a non issue now
<gawainlynch> Yeah, but first install can be on a working local machine, then transferred to one that isn't
<carsonfull> I don't think we need it pre  boot now
<[BoltGitHubBot]> [bolt] GawainLynch closed pull request #6331: Extension tweaks (release/3.3...extension-tweaks) https://git.io/vDtX4
<carsonfull> The only thing that could go wrong is the autoloader
<[BoltGitHubBot]> [bolt] GawainLynch closed pull request #6324: Add support for extension definition in bolt.yml file (release/3.3...fix/local-extension-fixes) https://git.io/vDT7X
<rossriley> beta time :-)
<gawainlynch> Just about to branch merge :-)
<Bopp> yay!
<carsonfull> Let's just remove those preboot error handler call
<carsonfull> s
<carsonfull> I'm doing it
<carsonfull> ...after lunch
<Bopp> :-)
<[BoltGitHubBot]> [bolt] rossriley closed issue #6319: [3.3] Local extensions don't get config settings.  https://git.io/vDUMI
<gawainlynch> WFM
<gawainlynch> OK, anything more and we'll sign off?
<carsonfull> @gawainlynch You ok with that?
<gawainlynch> carsonfull: If Bopp is, I am … my worry is only that group
<carsonfull> Nothing besides "request_error" and "validator.validator_service_ids" are the only thing called before boot
<carsonfull> Sounds like we are mostly in agreement. I'll PR actual implementation and we can continue from there
<SahAssar> Alright #meeting
* [BoltIssueBall] </meeting> Failed parsing XML: 'hug' expected, No 'love' shown for bot. Program 'meeting' terminated.
<Bopp> Yeah, i'm fine with that