Dev meeting 2016 09 13

Agenda

• How to fix our install procedure for Frontend Developers? See #5752
• Approach across Bolt for converting configs > arrays > traversable collection objects. What can we merge in from @carson's dev branch to share across the project.
• State of the Underscore™. Any news, or "steady as it goes"?
• Bolt 3.1.2. Should Bob do a new release? (after #5748, #5755 and #5756 are merged. And perhaps even a fix for #5759)

Actionable Items

• Release 3.1.2 — Approved
• @CarsonF to share Config work and collaborate with @rossriley

Outcomes

Log

<gawainlynch> ping carsonfull rossriley SahAssar Bopp gawainlynch rarila phillipp rixbeck sliick0
<rossriley> pong
<Bopp> pong :-)
<phillipp> i might be here
<gawainlynch> carsonfull: No stress
* slick0 (~slick0@infonomicon.net) has joined #boltcms
<gawainlynch> OK… anyone have any thing to raise from the con-call?
<gawainlynch> slick0: Your timing!
<SahAssar> pong
<slick0> Yes… Sorry it was only a 30 min call!
<Bopp> gawainlynch: My vague plans for refactoring the backend.. 
<slick0> Speaking of timing!
<Bopp> concerning that.. 
<gawainlynch> Bopp: Yeah, it's coming from a few angles :-D
<Bopp> Derk (and I) have been working on splitting up the CSS as a first step.
<gawainlynch> Yes, and awesome progress btw :-)
<Bopp> should I perhaps sometime sit down and write out my plans for that. 
<gawainlynch> (Derk showed me)
<Bopp> It'll realisically 
<rossriley> Twig needs pulling apart into much smaller blocks I think to make the backend extensible
<gawainlynch> Bopp: Yes … I think we need to do more of that
<Bopp> <realistically take a while to get done, but still
<gawainlynch> What rossriley said!
<gawainlynch> Also, we need to rip the f'ing business logic out of Twig 
<Bopp> Actually, as long as we allow to override or extend stuff, I don't even think that's vital.
<slick0> Yea, being able to override at a block level in twig for certain things would be huge
<gawainlynch> That's a huge blocker too
<Bopp> business logic should go, though. :-)
<SahAssar> We still have way too much in twig... The select field is a nightmare.
<gawainlynch> Bopp: Yeah, but it gets ugly fast … and I only say that from having to touch some of it in 3.0-dev
<Bopp> LET'S PORT BOLT TO MUSTACHE!
<carsonfull> Way too much in twig
<Bopp> You guys should've seen Bolt 1.0. 
<phillipp> yeah select field is a monster
<slick0> Bopp: Don't you go and suggest that _other_ template language now!
<Bopp> basically app.php, and a bunch of twig files. ;-)
<gawainlynch> #karma phillipp 
<[BoltIssueBall]> BoltKarma for phillipp is now 13
<phillipp> karma for what? all i did today is get us two grumpy
<gawainlynch> OK … so is anyone wanting lead on this?
<gawainlynch> phillipp: The case study 
<phillipp> ah
* gawainlynch hugs phillipp
<phillipp> :)
<gawainlynch> #5752
-[BoltIssueBall]/#boltcms- #5752 [open] [RFC] Improving the installation procedure for Frontend Developers. https://github.com/bolt/bolt/issues/5752 
<gawainlynch> Bopp …
<Bopp> Ok, so the past few weeks, and mainly last weekend, 
<slick0> And incase I forgot to say during the meeting: Thank you all for taking the time today to meet up with is
<Bopp> I spent some time digging into what "Frontend devs" bump into, when getting set up with Bolt. 
<SahAssar> slick0: And thank you for the invitation :)
<rossriley> slick0, gawainlynch I’m happy to look at the Twig refactor…. or at least co-ordinate it from this end… 
<Bopp> There are some mayor painpoints in there, that will need addressing in different ways. 
<gawainlynch> rossriley: Lovely … I'll add to the roadamp
<rossriley> since I’m also managing an embedded product that needs it quite a bit
<gawainlynch> Ah!
<Bopp> Since I took on the role of getting more into the community prt of Bolt, i'm going to be pushing towards improving these painpoints
<gawainlynch> Bopp: Nicely validated :-)
<carsonfull> +1
<Bopp> I'm convinced that improving these will grow the adoption of Bolt. 
<SahAssar> Do we have some way to get data on if these solutions are applicable? For example, how many of the frontenders have/use the CLI?
<Bopp> And yes, i _am_ going to suggest changes that will be unpopular for the people with in-depth knowledge of the code, 
<Bopp> but i'm sure we'll be able to reach middle ground on all of these. 
<rossriley> yes, I was gonna raise that… almost the dividing line is that most frontenders in my experience wont use cli
<gawainlynch> What is unpopular is changes that don't make sense
<Bopp> *cough* changing .gitignore *cough* 
* gawainlynch RAGES!!!!! :-P
<gawainlynch> What?
<gawainlynch> ;-)
<carsonfull> changing what?
<gawainlynch> Those additions to .gitignore
<Bopp> rossriley: Some of the things i want to tackle will also help those people
<carsonfull> what additions though?
<Bopp> carsonfull: and _removing_ things from the gitignore you get with the .zip and .tgz. 
<gawainlynch> #5752
-[BoltIssueBall]/#boltcms- #5752 [open] [RFC] Improving the installation procedure for Frontend Developers. https://github.com/bolt/bolt/issues/5752 
<Bopp> carsonfull: Let's not go into detail here.. I am working on a proposal with concrete examples, and we can argue^H^H^H^Hdiscuss then. 
<gawainlynch> ^ this
<SahAssar> Look, I don't think that adding a nut command or any other CLI stuff will help the intended audience for the fix, but I might be wrong. I just wanna know if the people we want to help know what we mean when say to run a couple of commands.
<carsonfull> cool
<gawainlynch> rossriley: You still here?
<carsonfull> jw if you wanted to commit the vendor folder
<rossriley> yes
<gawainlynch> rossriley, while carsonfull is here … config pooint "Approach across Bolt for converting"
* gawainlynch can't copy/pasta
<rossriley> yes, carsonfull from the branch you got started on for config refactor, anything you can PR in so I can share
<gawainlynch> SahAssar: Yeah, problem is we have anecdotal evidence and nothing but :-/
<Bopp> Anecdotal, perhaps, but still pretty consistent.. 
<Bopp> I'll gather more data, going forward. :-)
<carsonfull> rossriley: Yeah which piece of it? It's very old at this point. There was a lot of work converting arrays to objects though
<rossriley> specifically I’m targeting contenttypes.yml mapping so it’ll be the Node / Nodelist or Collection classes
<SahAssar> Bopp: consistent as in pointing towards that the FE's you've talked to know/can run CLI?
<Bopp> SahAssar: Yes, i suppose.. 
<carsonfull> rossriley: Yeah I can take a look at that and PR something to master
<Bopp> Mainly people who do know basic CLI, use git and SCSS
<rossriley> cool, just save doubling up on the work if you’ve already got something started to build on
<Bopp> the RFC i wrote is primarily focused on the issues that they bump into
<carsonfull> rossriley: Yeah absolutely. Thanks for keeping me in the loop :)
<gawainlynch> Bolt 3.1.2. Should Bob do a new release? (after #5748, #5755 and #5756 are merged. And perhaps even a fix for #5759)
-[BoltIssueBall]/#boltcms- #5748 [open] Update bootstrap to check non-hidden config files https://github.com/bolt/bolt/pull/5748 
-[BoltIssueBall]/#boltcms- #5755 [open] Fix Markdown parsing in frontend. https://github.com/bolt/bolt/pull/5755 
-[BoltIssueBall]/#boltcms- #5756 [open] Fix/default allowed tags should include iframe https://github.com/bolt/bolt/pull/5756 
-[BoltIssueBall]/#boltcms- #5759 [open] [BUG] Filebrowser breaks when folder has files with certain filenames https://github.com/bolt/bolt/issues/5759 
<Bopp> :-)
<Bopp> Carson gave me some pointers on 5759.. 
<Bopp> When those are in, I think it's time for a release. 
<gawainlynch> OK… wfm
<gawainlynch> State of the Underscore™. Any news, or "steady as it goes"?
<gawainlynch> Steady, Bopp 
<Bopp> Ok. :-)
<gawainlynch> Anyone have final point to raise?
<Bopp> yes, i do! 
<carsonfull> Me too
<Bopp> Wanted to show my favorite tweet of the week: https://twitter.com/EFollender/status/775696761201491968
<Bopp> Over to you, Carson. ;-)
<carsonfull> Woot! Those tweets are awesome to see
<phillipp> remembers me that i have to read my feed for the last 22h
<carsonfull> I should RFC this, but I basically want to remove the file permissions and visibility info from the backend UI. It is confusing and misleading and I don't feel helps editors at all.
<SahAssar> +1
<carsonfull> Specifically "Permissions: -rw-r--r--" and the lock icon in file lists
<gawainlynch> :fire:
<gawainlynch> :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: 
<Bopp> 🤔
* gawainlynch isn't even allowed on the UI team
<gawainlynch> Bopp: Picture of?
<Bopp> :thinking face: 
<SahAssar> The thinking face emoji
<gawainlynch> Tack
<Bopp> I'm not sure, I'll need to think on that suggestion
* SahAssar only found out by googling the square that appeared :D
<gawainlynch> Bopp: Problem is that once you turn on a remote FS … it means nothing
<Bopp> You mac-less plebeians ;-)
<carsonfull> I think lots of people think "public" visibility == writable and this is not the case. files that are "private" can still be written too. So all of those visibility checks which disable modifications would be removed too
<Bopp> gawainlynch: Yeah, I figured.
<carsonfull> I have a mac :)
<rossriley> carsonfull: I agree that they are wrong…. you don’t get a private till you do something like 700
<gawainlynch> "We're sorry, but we we're unable to perform that action on the file an error has been logged for you." versus  `-rw-r--r--`
<rossriley> but what about keeping the Read Only / Writable distinction
<rossriley> that’s supported on most filesystems, even remote ones
<carsonfull> Basically what rossriley said. And we can't really confirm that what user the web server is. maybe it needs the group permission, maybe it doesn't
<Bopp> yup
<carsonfull> There is no read only / writable distinction
<SahAssar> right, makes sense. Also, do we have some way to check if a file is plaintext instead of checking file ext?
<carsonfull> SahAssar: for what purpose?
<carsonfull> SahAssar: You would ahve to read the whole file, which you don't want to do when listing
<gawainlynch> SahAssar: You have to seek the header of the file 
<gawainlynch> …unless remote … then what carsonfull said
<Bopp> everything is a text file, if you try hard enough. ;-)
<SahAssar> carsonfull: Currently the only files editable in the backend are the whitelisted extensions. but, say for example that I have an SVG, and that is not in the hardcoded whitelisted extensions list, but I still want to edit it with the backend editor.
<carsonfull> SahAssar: That's a different topic. And a security risk :)
<rossriley> to be fair the current implementation works nicely on normal filesystems, it’s just that the trigger mode is wrong...
<phillipp> yeah, better dont get hacked by an svg of a kitten
<rossriley> you have to make it not readable or writable to trigger the lock icon and the private label
<carsonfull> SahAssar: You should just update the list to include svg
<carsonfull> rossriley: But a file could be private and still writable...
<rossriley> not really, private means you can’t read or write i’d have thought
<SahAssar> I have updated it. But since it's in a backend .twig template it's not a recommendation we want to give people.
<carsonfull> Nope that's incorrect
<carsonfull> It means "other people" can read/modify it.
<rossriley> ok, lets just deal with local filesystem. at the moment we only have two states, editable or not editable
<carsonfull> aka a "user" file = private. or a "system" file = public
<rossriley> yes, but from Bolt’s point of view it’s private or public to Bolt, not to an individual user
<carsonfull> we can't just deal with local filesystem, that is breaking the abstraction. and with the abstraction we don't know eidtble or not editable (until after trying)
<carsonfull> right which is very confusing
<carsonfull> CLI could be a different user than web, etc
<rossriley> yes, I appreciate that, but we still have three states…. Listable, Readable, Writeable
<carsonfull> And how do you find that out?
<rossriley> other filesystems can implement those three states or not at all I guess… we don’t really need to worry about listable, since we should never see those
<carsonfull> How do you find out readable or writable?
<rossriley> well on the localsystems we read the file permissions
<carsonfull> And how do you access that from the fs object?
<carsonfull> There are no readable/writable checks.
<rossriley> I’ve lost it but we use somewhere the posix_get_uid and posix_get_guid to see if either a user / group can read or write
<carsonfull> But you don't know from that if the file would be readable by the webserver
<carsonfull> If they are different users
<gawainlynch> Yeah, there is not reliable way to know that
<carsonfull> and still you can't do that without breaking the abstraction
<rossriley> well bolt runs as the web server user
<gawainlynch> Not always :-)
<gawainlynch> FPM
<carsonfull> ^
<gawainlynch> Slight distinction I know, but still it can bite
<carsonfull> My bigger point is it breaks the abstraction
<carsonfull> If that's something we REALLY want to pursue I would want to bake it into FS somehow. 
<carsonfull> But I think just giving an error message afterwords is fine
<rossriley> ok, but it seems a shame not to provide that nice info to Local FS users which will always be 99.9% of Bolt users, just because some other systems can’t….
<rossriley> surely we just make the info optional
<rossriley> so filesystems that don’t support it, dont display it?
<gawainlynch> My thought being, the backender will CLI, these are for editors who don't know what it all means anyway
<carsonfull> rossriley: I hear what you are saying. It's a shame that we are limited here. 
<rossriley> it’s only really a small point, but it is a nice UI feature at the moment, if the file isn’t writable then the user sees a greyed out filename with a padlock next to it, they know they can’t edit
<rossriley> and when you allow non-technical people to browse the templates folder, but not edit, then they can understand that setup
<carsonfull> We still have a global check for editing files right? if not we could make one. 
* Bopp has quit (Remote host closed the connection)
<carsonfull> It seems like you can either write to all files or only read them based on setup. It doesn't seem like there's a need to grainular here. 
<gawainlynch> Can we make an assumption based on the visibility of the files/ folder tiself
<carsonfull> Would that be a solution?
<carsonfull> gawainlynch: no
<gawainlynch> Fires the iterator anyway?
<Bopp> I thought with Flysystem that we couldn't check if a file was writable until we actually try writing to it? 
<carsonfull> Bopp: exactly
<carsonfull> After that point though we can give a nice error to users
<Bopp> Doing that in listings makes no sense though.. too time consuming. :-)
<rossriley> ok, well I don’t really object, just make sure we think if a workaround is possible before removing an existing feature
<gawainlynch> ^
<gawainlynch> Alrighty then … anything more?
<carsonfull> Yes absolutely. I want to make it as nice as we can. Just trying to work around the limitations here. 
<Bopp> Nothing else from me. 
<carsonfull> And it seems like a minor feature this issue
<gawainlynch> SahAssar: Would you like the honours? 
<Bopp> I'll see if i can get a patch in for that one issue. 
<SahAssar> </meeting>