Dev meeting 2017 08 22

Agenda

• 3.4.0 beta (@GawainLynch)
• UI clean-ups for 3.4 (@GawainLynch)
• Cryptographically signing release tags, i.e. not using GitHub web UI (@GawainLynch)
• Collating and publishing a list of companies/agencies building sites with Bolt — volunteer(s) needed (@GawainLynch)
• Update: Refactor of ContentType and Field Mapping #5914 (Ross)
• Dropping HHVM support from Travis (@GawainLynch)

e.g.

• Status on drop bear invasion (@YourGitHubID)

Actionable Items

Outcomes

• Cryptographically signing release tags, i.e. not using GitHub web UI

Log

[19:29] 
ping @bob @carson @gawainlynch @lenvanessen @ross @sahassar


[19:29] 
panda_madness Regarding extension menus: if the question is still relevant, how about let the site admin configure which extensions are top level and which are not? If it’s possible technically ofc


[19:29] 
ross pong


[19:30] 
panda_madness Oh meeting _runs away to not be a nuisance_ (edited)


[19:30] 
carson o/


[19:30] 
sahassar
Pong


[19:30] 
bob
pong


[19:30] 
lenvanessen
pong
Posted using /giphy | GIF by Cheezburger (2MB) 


[19:30] 
bob
@panda_madness You’re welcome to stick around, mate


[19:30] 
gawainlynch
OK, and easy one to roll with


[19:30] 
- Cryptographically signing release tags, i.e. not using GitHub web UI


[19:31] 
Mainly this is you & I, Bob


[19:31] 
But I am thinking we should start signing our tags


[19:31] 
bob
I'd be fine with that.


[19:31] 
gawainlynch
Yeah, just hate to have something so simple bite us in the butt


[19:32] 
bob
Will need to google how to do that, but it'll be fine :wink:


[19:32] 
gawainlynch
Oh, or I can do it at your place on the weekend … the GH page itself is dead easy to follow


[19:32] 
(already checked for you)


[19:32] 
bob
Sure thing


[19:32] 
Let's start doing that, then


[19:33] 
gawainlynch
OK, next one is related to beta, UI clean-ups for 3.4


[19:33] 
There is @lenvanessen's work and a few other things that need attention


[19:33] 
bob
I'll work on those.


[19:34] 
I really dig the improvements to the Files/ page, but I'd like to tweak some bits and pieces :slightly_smiling_face:


[19:34] 
gawainlynch
Yep, figured you would … and we've got it in "live" usage now, so annoying more people :slightly_smiling_face: (edited)


[19:34] 
lenvanessen Sure thing, didn’t expect to swing a hole-in-one the first attempt:)


[19:35] 
bob
@lenvanessen No worries.. Getting it _working_ is the bigger part. Just need to smooth a few things out :slightly_smiling_face:


[19:36] 
gawainlynch
@ross: Are you planning, or more importantly have time if you are, to land more setcontent fixes for 3.4 stable?


[19:37] 
ross I've got a work in progress atm


[19:37] 
I was planning on a few PRs as they come...


[19:37] 
gawainlynch
Sweet … figured you've been "having fun" with RL work


[19:38] 
ross nothing that I'm working on now will affect the stable though, as it only occurs behind the experimental flag


[19:39] 
gawainlynch
Oh, and were you planning on landing "Refactor of ContentType and Field Mapping #5914" or is that on the burner?


[19:39] 
boltissueball #5914 [open] [WIP] Refactor of ContentType and Field Mapping https://github.com/bolt/bolt/pull/5914  — assigned to rossriley


[19:39] 
ross no that'll bump to 3.5


[19:40] 
there was one thing that came up in my current branch... whether we carry on supporting both single and plural versions of contenttype in setcontent calls


[19:40] 
gawainlynch
Ah yeah!


[19:40] 
I meant to ask about that


[19:41] 
There is not a lot of consistency in our base templates for a start … which raises BC


[19:41] 
ross at the moment we only register to the contenttype name so `$app['storage']->getRepository('pages')` works, but `$app['storage']->getRepository('page')` doesn't


[19:42] 
gawainlynch
Looking at it (accidentally) it looks like we'd need to double the mapping alias?


[19:42] 
…or alias the alias :smile:


[19:42] 
ross yes, that's right... which we can do, just don't know whether we should mark that as deprecated...


[19:42] 
there's also the issue that we should be using contenttype name rather than slug too


[19:43] 
gawainlynch
Yes & yes IMHO


[19:43] 
ross so to be truly BC at the moment we will need to register aliases for name, slug and singular_slug


[19:43] 
gawainlynch
I almost had a Carson Level Trigger in #general before at the mention of using the slug name


[19:43] 
ross ha, time to dust off the /kick button


[19:44] 
bob
:runner:


[19:44] 
gawainlynch
Haha … Nah, just that it being promoted as correct … but to be fair, we haven't confirmed a way forward officially


[19:45] 
Mainly what was triggering me was the 1.2.1 slug issue that we're still untangling :smile:


[19:45] 
But my vote is for CT keys, support BC for v3's lifetime, deprecate and update docs consistently and clearly


[19:46] 
ross cool. we can do that then


[19:46] 
gawainlynch
The docs is the hard part … it is a lot to dig though


[19:46] 
@bob, @sahassar, @carson thoughts?


[19:47] 
bob
Well, I always urge people to set the "key" the same as the `slug`. If you do that, this change will be of no consequence to you.


[19:48] 
I'm not sure how many people it'll bite in the arse, though


[19:48] 
gawainlynch
Oh yeah … more as a v4 goal though


[19:48] 
sahassar
I'd prefer the slug...


[19:48] 
Since then the URL and the setcontent query match, which seems a bit easier for newbies IMO (edited)


[19:48] 
bob
Valid point


[19:49] 
that is in fact how i once thought it up


[19:49] 
gawainlynch
I'll give it to you, you raise a good point


[19:49] 
carson I think it is confusing


[19:50] 
sahassar
carson: With the slug?


[19:50] 
bob
dropping the keys entirely from contenttypes.yml will make the file a lot less readable, though. Otherwise I might favor that.


[19:50] 
carson If content types are a mapping, then the key of the value should be the key. If we want to use a property of the value then we should change it to a list in yaml


[19:51] 
gawainlynch
Which is where my head is at


[19:51] 
ross yes, but slugs can change, contenttype names shouldn't


[19:52] 
carson So we are talking about two different things here


[19:52] 
The CT key and the CT slug.


[19:52] 
ross yes


[19:52] 
currently we can also use the singular_slug too


[19:52] 
carson So we should deprecate accessing the CT by the slug (programatically not URL)


[19:52] 
ross correct


[19:53] 
carson I am all for that :100:


[19:53] 
bob
I've switched my opinion. `slug` should be the main identifier, and the key irrelevant.


[19:54] 
sahassar
The slug should be the primary identifyier IMO


[19:54] 
bob
added this Plain Text snippet
dummies: # <- this is the key
  name: Dummies
  slug: dummies # <- this is the slug
  singular_name: Dummy
  fields:
    title:
      type: text
      class: large
      group: content
    slug:
      type: slug
      uses: title
Add Comment Collapse



[19:54] 
carson So what happens when the slug changes?


[19:55] 
bob
^ just to be certain, we're talking about this, right?


[19:55] 
sahassar
carson: We trigger a db update and the template needs to change


[19:55] 
gawainlynch
We have `slug` and `singular_slug` though


[19:55] 
carson @bob that’s what we are talking about yes


[19:55] 
bob
If the slug changes, you'll break all your links.


[19:55] 
carson That’s besides the point


[19:55] 
bob
I don't think it is.


[19:56] 
gawainlynch
The problem is we have 3 potential mappings per CT


[19:56] 
`key`, `slug` & `singular_slug` (edited)


[19:56] 
carson ^


[19:56] 
sahassar
Remove key (ignore), use singular slug only for record urls and slug for the rest IMO (edited)


[19:57] 
gawainlynch
Part of my point though, @sahassar, is that it gets more confusing (at least to me) as to which to use


[19:57] 
carson “ignore” makes it…^


[19:57] 
bob
@sahassar "removing" the key from the yml isn't really feasible. It looks messy


[19:57] 
sahassar
bob: Yeah, I meant ignore, not remove


[19:57] 
bob
Ok.


[19:57] 
carson Ignore is confusing too


[19:58] 
sahassar
It'll be consufsing no matter what we ignore, right?


[19:58] 
My point is that matching URLs, setcontents and other parts makes it as consistent as we can make it (edited)


[19:59] 
carson Well no. I think CT have a key. Which is how you access them in code. They also have slugs which are used only for routing


[19:59] 
bob
.. and in "setcontent"


[19:59] 
carson No.


[19:59] 
That’s code


[20:00] 
By default, they can be the same though (edited)


[20:00] 
sahassar
How about we force the slug and the key to be the same then?


[20:00] 
carson Why?


[20:01] 
sahassar
Because then we have a single key for how to access content. templates might be code, but it is still code written by folks who don't have much experience with this, and having a single keyword for accessing a certian contenttype is easier than separating it


[20:02] 
carson We should just tell people to make them the same. But there’s no reason to force it if more experienced people need to make them different


[20:03] 
bob
Why would you need to make them different? what's the usecase for that?


[20:03] 
carson new and old content.


[20:03] 
`books-v2` content type which points to `books` slug so the url doesn’t change (edited)


[20:04] 
bob
Which one is leading, currently?


[20:04] 
sahassar
Isn't that what custom routes are for? customizing the routing?


[20:05] 
bob
^ that's how i've done it.


[20:05] 
carson Yes you would need some of that too. But enforcing them to be the same would just be another place that the user would have to change


[20:05] 
bob
but, as an example.. Let's say i'm an idiot, and have this:


[20:05] 
bob
added this Plain Text snippet
foo:
  slug: bar
  …
bar:
  slug: foo
  …
Add Comment Collapse



[20:06] 
bob
What should `{% setcontent foo = "foo" %}` give?


[20:06] 
gawainlynch
IMHO the first one


[20:06] 
bob
IMHO the second


[20:06] 
carson First one


[20:06] 
ross i may be the odd one out here, but I can think of loads of occasions when a client comes along and says, can we change the urls from `about` to `about-companyname` and the thought of updating all the setcontent queries rather than just updating the slug seems weird?


[20:07] 
carson ^ No, I agree @ross


[20:07] 
gawainlynch
Same … been there


[20:07] 
bob
That's the exact opposite of how I view them in my mind.


[20:08] 
I associate them with `slug`, and not the key


[20:08] 
gawainlynch
Yes, and to be fair that has landed us in tonnes of hot water


[20:08] 
ross we had the same issue before where the database table was based off the slug rather than the name


[20:08] 
bob
Shall we park this one for now, and in the meantime I can ask a few end users how they see it?


[20:08] 
ross yes, it's not urgent for now


[20:09] 
carson Yes, just make sure to frame it correctly


[20:09] 
bob
Because, I think we've all said how we think, and for now we kindly disagree :slightly_smiling_face:


[20:09] 
sahassar
gawainlynch: Isn't the problem that it's inconsistent, not actually which we choose?


[20:09] 
ross just if we are going to remove it in 4+ then we should start throwing deprecation warnings soonish


[20:09] 
carson ^ agreed


[20:09] 
gawainlynch
@sahassar: Both


[20:10] 
That's not a firm argument on my part one way or the other, just summing up the "fun" I've had over the last few years with this problem


[20:11] 
bob
I think we all agree on that. Pick _something_ and make it consistent.


[20:11] 
gawainlynch
I've quite literally been beside myself at one point when this broke things really badly, and Ross' quick thinking busting out a hack got us going … but we're still carrying the legacy


[20:13] 
bob
Ok. Shall we move on for now?


[20:15] 
gawainlynch
What's missing in bridging the understanding here is that there is a valid defence of the beginner going on, and that's cool, but also there are people having to implement this … and while the Defenders of the Novice might feel like we're being purist, we're not, we're just trying to get a job done and done well


[20:15] 
We're the ones that get to pick up the bits that break


[20:15] 
bob
I think we all know that.


[20:16] 
gawainlynch
But yeah, save what Svante is responding with … I'm happy to move on until later


[20:16] 
sahassar
Yeah, I don't think that the "defence of the novice" is absolute, any point has downsides and upsides :slightly_smiling_face:


[20:16] 
gawainlynch
Oh yeah, I was aiming to be poetic so as not to look like it was a rage/rant


[20:17] 
OK … let's do our collective regathering and we'll cover this again soon


[20:18] 
I think at this point, I'll hand over for the final "anything to raise?"


[20:18] 
bob
Yes, i have one thing!


[20:18] 
gawainlynch
Going by your status icon, a tent?


[20:19] 
bob
Our friend @jmarsh has stepped up to work on improving the Bolt visual branding, and wants to continue after that with re-developing a new bolt.cm website.


[20:19] 
Here's a sneak preview of his work-in-progress:


[20:20] 
https://marvelapp.com/2f1eji4/screen/31618519
Marvel Prototyping
Bolt Website
Marvel Prototype for Bolt Website
 


[20:20] 
gawainlynch
Oh dear … he didn't change the backender screen … Texas Trigger :smile:


[20:21] 
bob
It'll probably change some more, if we also get a better idea of what we'll change in the UI for 4.0, but as a direction, I'm really liking what he's done so far.


[20:21] 
gawainlynch
Same


[20:21] 
ross this is great


[20:22] 
gawainlynch
Yeah, he's kicking goals


[20:22] 
@lenvanessen Also worth noting, it covers the get.bolt.cm line item that you had your eye on before you went away


[20:23] 
sahassar
:+1:


[20:23] 
gawainlynch
The quick and the :zombie: at the moment


[20:23] 
carson Looks awesome


[20:23] 
gawainlynch
OK, who'd like honours then?


[20:24] 
carson Although not mobile friendly. At least that preview


[20:24] 
gawainlynch
Nah, that's just the prototyping software I think


[20:24] 
bob
@carson It's a `.png` :wink:


[20:24] 
carson LOLZ

[20:24] 
gawainlynch
Or that

[20:24] 
ross pngs scale nicely on mobiles

[20:24] 
carson #meeting

[20:24] 
boltissueball </meeting> Failed parsing XML: 'hug' expected, No 'love' shown for bot. Program 'meeting' terminated.