[4.0] Child templates by dgrammatiko · Pull Request #30192 · joomla/joomla-cms

dgrammatiko · 2020-07-25T22:20:26Z

Pull Request is the foundation for #30149

Summary of Changes

Introduces Inheritable templates solving numerous problem with the current state of templates. Read more on the linked issue above

This PR is complete in the sense that contains all the changes (even the upgrade path from J3) to introduce the new mode but without introducing the GUI and neither is moving any of the templates to the new mode. These can be done in following PR's

Testing Instructions

Do not try to test this with patch tester, it won't work.
Install the PR's installable, you can d/l it here (at the bottom of this page)
If you want to use git command lines or the desktop app make sure that you'll do a fresh install or apply the updates (sql files)

Make sure you have the browser's console open so you can observe any missing assets.

If this went smooth, then it's a good sign as the installation is a seperate application with it's own template and although this PR is not touching the installation template everything works as before. B/C check 1

Front End step 1

Go to the front end and vist the following urls:

/index.php/blog
/index.php/blog/3-welcome-to-your-blog
/index.php/author-login (login here)
/index.php?option=com_config&view=modules&id=109&Itemid=104 (or just try to edit the top left module)

Everything should be fine, no console logs or missinng icons, etc. B/C check 2

Front End step 2

Download this cassiopeia_overrides_v2.zip and extract the contents and copy them in the folder templates/cassiopeia/html. Revisit the pages of the previous step. You should see in the pages some plain text (that will also break a bit the design) Legacy Component view override. You have to look for Component, Module, Plugin and JLayout. If so then the cascading of the templating is working correctly, in the previous step there was no overrides in this one the overrides were treated as top priority. Also cassiopeia has some overrides for the static assets so that was already tested (if you want you might open a normal 4.0 version in another winndow and check the number of assets per page between the 2). B/C check 3

Front End step 3

Install the first new mode template (basically cassiopeia with another name: siteparent) from here siteparent_v2.zip

Go to the admin and make the siteparent template default and also assign all the menus to this template!!! Go to the front end and repeat the Front End step 1 and confirm that everything is as before. check 4

Front End step 4

Go with your filemanager to templates/siteparent and copy the contents os the folder xhtml to the folder html. Redo the ritual of Front End step 1 and confirm that all the parts Component, Module, Plugin and JLayout are there. check 5

Front End step 5

Although the child templates should be created inside joomla's env for testing purposes we will do it using the installer, so install this: sitechild_v2.zip

Go to the admin and make the sitechild template default and also assign all the menus to this template!!! Go to the front end and repeat the Front End step 1 and confirm that everything is as before. check 6

Front End step 6

Go with your filemanager to templates/sitechild and rename the folder xhtml to html. Redo the ritual of Front End step 1 and confirm that all the parts Component, Module, Plugin and JLayout are there. check 7

Back End step 1

Go to the addinistrator end and vist the following urls:

/administrator/index.php
/administrator/index.php?option=com_content&view=articles
/administrator/index.php?option=com_installer&view=install

Everything should be fine, no console logs or missinng icons, etc. B/C check 8

Back End step 2

Download this atum_overrides_v2.zip and extract the contents and copy them in the folder administrator/templates/atum/html. Revisit the pages of the previous step. You should see in the pages some plain text (that will also break a bit the design) Legacy Component view override. You have to look for Component, Module, Plugin and JLayout. If so then the cascading of the templating is working correctly, in the previous step there was no overrides in this one the overrides were treated as top priority. Also cassiopeia has some overrides for the static assets so that was already tested (if you want you might open a normal 4.0 version in another window and check the number of assets per page between the 2). B/C check 9

Back End step 3

Install the new mode template (basically atum with another name: adminparent) from here
adminparent_v2.zip

Go to the administrator template styles and make the adminparent template the default one. Repeat the Back End step 1 and confirm that everything is as before. check 10

Back End step 4

Go with your filemanager to administrator/templates/adminparent and copy the contents os the folder xhtml to the folder html. Redo the dance of the Back End step 1 and confirm that all the parts Component, Module, Plugin and JLayout are there. check 11

Back End step 5

Althouth the child templates should be created inside joomla's env for testing purposes we will do it using the installer, so install this:
adminchild_v2.zip

Go to the admin and make the adminchild template the default. Repeat the Back End step 1 and confirm that everything is as before. check 12

Back End step 6

Go with your filemanager to administrator/templates/adminchild and rename the folder xhtml to html. Redo the ritual of the Back End step 1 and confirm that all the parts Component, Module, Plugin and JLayout are there. check 13

Final checks

Check your db and the table template_styles, you should have

autum and cassiopeia with parent 0 and inherits ``
from the new ones the parent ones with parent 1 and inherits ``
and the child ones ones with parent 0 and inherits siteparent and siteadmin respectfully

Finally someone needs to confirm that the update sql files are all that is needed here

And the last one

You have probably saw some missing strings when you were trying to edit any of the template styles. This is expected as I forgot to include any languages in the parent template, but this is quite easy to check. You are already in the adminchild template so all you have to do is create a folder language/en-GB in the adminparent template and then copy the tmpl_atum*.ini to this folder and rename them to tmpl_adminparent.ini and tmpl_adminparent.sys.ini. Check again the strings are back. Then make the adminparent the default template and check for any changes (readable text should remain readable). You can repeat this for the front end templates (although the function is common for both).

Documentation Changes Required

For the devs the new parts are 2:

manifest requires a tag <inheritable>1</inheritable > to enable a template in the new mode
all static assets and also any static asset override should be done in the media/( administrator || site )/templateName. Folders like css/js/images inside the above path will act exactly the same as they did in the old templates/name/( css || js || images )

libraries/src/Document/HtmlDocument.php

libraries/src/Application/SiteApplication.php

kawshar · 2020-07-26T09:57:32Z

My recommendation, please keep the database out of it. Just a normal override option would be great. I don't know why Joomla has deep integration with the database for all possible features except the most important Media Manager.

Thanks

@Fedik

Thank @Fedik for this!!

dgrammatiko · 2020-07-26T11:41:56Z

My recommendation, please keep the database out of it

One way or another the db is involved here as it holds the style data

I don't know why Joomla has deep integration with the database

Very short answer: db is the only secure storage it got. Just don't ask me why the template style details (or any such data) needs any elevated security 😂

libraries/src/Application/SiteApplication.php

Fedik · 2020-07-26T12:10:34Z

Couple 2 note :)

First note.
I am not strong in English, but for me the property name inherits is a bit of controversial (Usually it means the children inherit parent.)

In current usage I would call it style_template, so the template style object will have 2 property:
Existing template the name of folder for parent template
New style_template the name of folder for override (for child template).

Second note.
I am not very understood why need parent property.
I think if the template has empty inherits it is parent automatically, or maybe I missed something?

dgrammatiko · 2020-07-26T12:24:17Z

I am not very understood why need parent property.
Check these lines in the HTMLHelper:

				$templaPath = JPATH_THEMES;

 				if ($template->parent || !empty($template->inherits))
 				{
 					$client     = $app->isClient('administrator') === true ? 'administrator' : 'site';
 					$templaPath = JPATH_ROOT . "/media/templates/$client";
 				}

Basically it's a switch for the new mode, the static files exist in the media/template/( administrator || site )/templateName. It can't be done with only the inherits value because then will not cover the parent template (or it can be done but I'm not that clever 😃)

I am not strong in English, but for me the property name inherits is a bit of controversial

Inherits imply inherits from ..., that's why I picked it but naming is hard so anything else can go there, I don't have strong feelings for this

Fedik · 2020-07-26T12:47:12Z

Basically it's a switch for the new mode, the static files exist in the media/template/( administrator || site )/templateName

I see now.
For switching we can just check if the folder exists, then do switch, something like:

$template = $app->getTemplate(true);
$templatePath = JPATH_THEMES;
$client = $app->isClient('administrator') === true ? 'administrator' : 'site';

if (is_dir(JPATH_ROOT . "/media/templates/$client/{$template->template}"))
{
	$templaPath = JPATH_ROOT . "/media/templates/$client";
}

So if original (parent) template has the styles/scripts in /media/templates, then HTMLHelper will take it

Inherits imply inherits from ...,

Exactly this part is confusing me 😉
I read it like MyStyle inherits from Atum/Cassiopeia folder, but in the implementation it like MyStyle inherits from MyStyle folder,

dgrammatiko · 2020-07-26T13:13:51Z

For switching we can just check if the folder exists, then do switch, something like:

This is true we could have eliminated the parent attribute both from the db and the manifest but I'm against it I mean stretching the code you could make any template inheritable but it will be wrong. Most, current templates use something like this:

	$logo = '<img src="' . $this->baseurl . '/templates/' . $this->template . '/images/logo.svg" class="logo d-inline-block" alt="' . $sitename . '">';

which will fail miserable if you try to make a child from it (the $this->baseurl for the child will be a for the parent will be b, file not found will be the result)
Parent templates should always use the API for css,js,images like:

$logo = HTMLHelper::image('logo.svg', '', ['class' => 'logo d-inline-block'], true, 0);

in order to not break their children...

read it like MyStyle inherits from Atum/Cassiopeia folder, but in the implementation it like MyStyle inherits from MyStyle folder

Are you referring to the db names or the php ones?
I might be answering the wrong questions here 😃

Fedik · 2020-07-26T13:34:02Z

Are you referring to the db names or the php ones?

To both :)

$template  =  $app->getTemplate(true);

var_dump($template->inherits); 
//   ^^^^^^^^^
// This part, I expect it like: $template inherits from "inherits value". 
// But "inherits value" contain "own folder name"

Well, nevermind, maybe it just me.

dgrammatiko · 2020-07-26T13:37:26Z

But "inherits value" contain "own folder name"

Maybe I misunderstood you comment in the other PR:

So templateDetails.xml should contain <inherits>parent_name</inherits> (or <parent_name>{blabla}</parent_name>) instead of style_id

Fedik · 2020-07-26T13:37:38Z

I'm against it I mean stretching the code you could make any template inheritable but it will be wrong

I think that okay. Sure, it will not work for hard-coded paths, that is not our problem.

Fedik · 2020-07-26T13:43:10Z

Maybe I misunderstood you comment in the other PR: <inherits>parent_name</inherits>

Yeah, I meant like this:
User create override called foobar that inherits cassiopeia, so dummy xml contain:

<name>foobar</name>
<inherits>cassiopeia</inherits>

Sorry for confusing :)

UPD: But I forgot that the template_styles table already contain template column, that holds the name of the parent template.

dgrammatiko · 2020-07-26T13:52:42Z

@Fedik how about instead of parent we use inheritable (means can have children) and instead of inherits we use parent where parent is just the parent template name?

@brianteeman any suggestions here?

Fedik · 2020-07-26T14:12:49Z

how about instead of parent we use inheritable (means can have children) and instead of inherits we use parent where parent is just the parent template name?

That sounds good.

To be sure I right understood:

The dummy xml of child template will have something like:

<name>foobar</name>
<parent>cassiopeia</parent>

<name>foobar</name> will go to style_template column of database;
<parent>cassiopeia</parent> will go to template column of database;
and because we have a parent this will set inheritable = 0 in database

And parent template will have <inheritable>1</inheritable>

I am understood correctly? :)

dgrammatiko · 2020-07-26T14:15:00Z

Yup, you got it right. The pain is that I have to redo all the parent/child templates for the tests 🥱

- `parent` is now named `inheritable` (eg allows children) - `inherits` is now `parent` (eg the parent template’s name )

Septdir · 2020-07-26T16:08:00Z

Child themes are a great idea.
But I have one thing that confuses me.
<inherits> siteparent </inherits>

Usually child themes do not require their own manifest, but the name of the child theme directory indicates the link with the parent.

In the case of an example. The name of the child theme must be siteparent_sitechild, otherwise, to determine where is the parent and where is the child, you will have to look at the manifest of each template.

dgrammatiko · 2020-07-26T16:18:39Z

Usually child themes do not require their own manifest, but the name of the child theme directory indicates the link with the parent.

Technically a child template is an actual template but only with one file the manifest (templateDetails.xml). This way there are very few changes that need to be done in the core. Can it be done with a snake case naming? Well it's just code so it can be done but will bee extremely inefficient as you will end up scanning the templates dir and checking each folder. Now the data is coming from the db which one way or another Joomla is using it atm and has exactly 0 performance impact. Also it's not just to get something working in the core you have to think/see what's the code in com_templates. With the proposed approach the changes are minimal.

Septdir · 2020-07-26T16:32:57Z

Technically a child template is an actual template but only with one file the manifest (templateDetails.xml). This way there are very few changes that need to be done in the core.

I recently did this for the yootheme template, I had to override a couple of classes.
The child template itself is selected in the parent's settings.

One way or another, I would still add a naming rule for the child template.
You can check during installation.

dgrammatiko · 2020-07-26T16:46:25Z

One way or another, I would still add a naming rule for the child template.

That's possible, eg prefix it with the parent name like parentName_childName but it's something that will be done in the com_templates and won't affect anything here

installation/sql/mysql/base.sql

HLeithner · 2020-07-29T20:09:30Z

thanks for the explanation I would like to make some code suggestion, I hope it's ok for you I have reopened the pr.
beside my comments the pr should be rebased on 4.1

HLeithner

The PR looks ok to me.

HLeithner · 2020-07-29T20:19:55Z

libraries/src/Application/SiteApplication.php

+			if ($this->template->parent)
+			{
+				if (!file_exists(JPATH_THEMES . '/' . $this->template->template . '/index.php'))
+				{
+					if (!file_exists(JPATH_THEMES . '/' . $this->template->parent . '/index.php'))
+					{
+						throw new \InvalidArgumentException(Text::sprintf('JERROR_COULD_NOT_FIND_TEMPLATE', $this->template->template));
+					}
+				}
+			}
+			elseif (!file_exists(JPATH_THEMES . '/' . $this->template->template . '/index.php'))


Suggested change

if ($this->template->parent)

{

if (!file_exists(JPATH_THEMES . '/' . $this->template->template . '/index.php'))

{

if (!file_exists(JPATH_THEMES . '/' . $this->template->parent . '/index.php'))

{

throw new \InvalidArgumentException(Text::sprintf('JERROR_COULD_NOT_FIND_TEMPLATE', $this->template->template));

}

}

}

elseif (!file_exists(JPATH_THEMES . '/' . $this->template->template . '/index.php'))

if (

!file_exists(JPATH_THEMES . '/' . $this->template->template . '/index.php')

&& (

empty($this->template->parent)

|| !file_exists(JPATH_THEMES . '/' . $this->template->parent . '/index.php')

)

)

@HLeithner the rest of the changes are fine but not this one. You can reduce the inner 2 conditionals to 1 but changing it to 1 (top) conditional is wrong in the sense that the ($this->template->parent) is extremely cheap to resolve but

!file_exists(JPATH_THEMES . '/' . $this->template->template . '/index.php') && ( empty($this->template->parent) || !file_exists(JPATH_THEMES . '/' . $this->template->parent . '/index.php') )

introduces 2 more file lookups for every execution for no reason.

introduces 2 more file lookups for every execution for no reason.

actually not true, the second !file_exists will not be called if empty($this->template->parent) is true

but that was not the point you can leave it that way if you want it's only to reduce duplicated code. Will you merge the other suggestions?

Done, although I have to state that I'm not so sure I want to move this one forward anymore.

What's the reason? because I said it can not go into 4.1?

I read them but the explanation but they don't make sense to me, a js that's template independent is something different then a image that's only used in the template. We already split everything about the joomla filesystem at least the templates are "self contained" but that's only my opinion.
Anyway that doesn't hold this feature back.

The move to media folder seems unnecessary. Can't we just check for assets in child template directory and fallback to parent template directory?

If you want to move assets to media directory for other purposes, that could be done in a separate PR so it doesn't have to wait for this.

You really don’t get it. It’s you only opportunity to fix this and bring consistency...

You really don’t get it. It’s you only opportunity to fix this and bring consistency...

Do a PR where you only move the assets to media. I actually think that could still be done for 4.0 as it's not a new feature.
If it can be done independant, lets do it independant and don't mix things.

Guys do you even realise the amount of work I put here to create all the 4 templates and the other html overrides for the tests?

Asking to break it in 2 is just asking me to repeat the whole work twice. Why? This is a new mode, it doesn't and shouldn't affect any of the current templates

HLeithner · 2020-07-29T20:22:31Z

libraries/src/Application/SiteApplication.php


 		// Fallback template
-		if (!file_exists(JPATH_THEMES . '/' . $template->template . '/index.php'))
+		if (!empty($template->parent))


I think you can simplify this too like them above to reduce code duplication

libraries/src/Installer/Adapter/TemplateAdapter.php

libraries/src/MVC/View/HtmlView.php

Co-authored-by: Harald Leithner <leithner@itronic.at>

bonzani · 2020-07-31T12:52:54Z

I have tested this item ✅ successfully on eec9d9a

One of the most useful things in J4 I've seen so far...

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30192.}

wilsonge · 2020-08-09T22:47:42Z

I really really shouldn't be pressing merge here - but I've seen several template clubs in favour of this so I'm going to break my own rules and hope I don't regret it. thankyou for this really nice feature @dgrammatiko

richard67 · 2020-08-10T06:07:42Z

installation/sql/postgresql/base.sql

+  `inheritable` smallint DEFAULT 0 NOT NULL,
+  `parent` varchar(50) DEFAULT '',


Strange that nobody saw this and nobody tested with PostgreSQL like it should always be done when a PR has database changes. This has broken installation on PostgreSQL. Will prepare a fix.

Wong names quotes I mean.

Fixed with #30327 .

richard67 · 2020-08-10T08:35:48Z

administrator/components/com_admin/sql/updates/postgresql/4.0.0-2020-06-25.sql

@@ -0,0 +1,2 @@
+ALTER TABLE "#__template_styles" ADD COLUMN "inheritable" smallint NOT NULL DEFAULT 0;
+ALTER TABLE "#__template_styles" ADD COLUMN "parent" varchar(50) DEFAULT "";


Next mistake DEFAULT "" should be DEFAULT ''

please submit a fix i'll test it

Done #30330 .

This fixes update from 3.10 to 4 failing with SQL error due to not existing database columns.

… from 3.10 to 4 (#30333) * Backport database changes from J4 PR #30192 This fixes update from 3.10 to 4 failing with SQL error due to not existing database columns. * Add explaining comment to the update SQL scripts

Sweet child o’mine

9baf09c

joomla-cms-bot added the PR-4.0-dev label Jul 25, 2020

dgrammatiko mentioned this pull request Jul 25, 2020

[4.0][RFC] Child templates a-la wp, but better #30149

Closed

dgrammatiko added 2 commits July 26, 2020 00:26

Update base.sql

7eb0c83

CS

f210d8b

Fedik reviewed Jul 26, 2020

View reviewed changes

libraries/src/Document/HtmlDocument.php Outdated Show resolved Hide resolved

Fedik reviewed Jul 26, 2020

View reviewed changes

libraries/src/Application/SiteApplication.php Outdated Show resolved Hide resolved

dgrammatiko added 2 commits July 26, 2020 13:32

Remove uneeded code

9c8ec53

Thank @Fedik for this!!

typo

a210661

Fedik reviewed Jul 26, 2020

View reviewed changes

libraries/src/Application/SiteApplication.php Outdated Show resolved Hide resolved

Better naming

bf7fd52

- `parent` is now named `inheritable` (eg allows children) - `inherits` is now `parent` (eg the parent template’s name )

Fedik reviewed Jul 26, 2020

View reviewed changes

installation/sql/mysql/base.sql Outdated Show resolved Hide resolved

Fix the sql

cda7686

HLeithner reopened this Jul 29, 2020

HLeithner requested changes Jul 29, 2020

View reviewed changes

dgrammatiko and others added 3 commits July 30, 2020 19:09

Update libraries/src/Installer/Adapter/TemplateAdapter.php

a3603ca

Co-authored-by: Harald Leithner <leithner@itronic.at>

Update libraries/src/Installer/Adapter/TemplateAdapter.php

750fb26

Co-authored-by: Harald Leithner <leithner@itronic.at>

Update libraries/src/MVC/View/HtmlView.php

eec9d9a

Co-authored-by: Harald Leithner <leithner@itronic.at>

wilsonge merged commit 98dacf3 into joomla:4.0-dev Aug 9, 2020

wilsonge added this to the Joomla 4.0 milestone Aug 9, 2020

wilsonge added the Documentation Required label Aug 9, 2020

richard67 reviewed Aug 10, 2020

View reviewed changes

richard67 mentioned this pull request Aug 10, 2020

[4.0] Fix broken installation with SQL error on PostgreSQL databases #30327

Merged

richard67 reviewed Aug 10, 2020

View reviewed changes

richard67 mentioned this pull request Aug 10, 2020

[4.0] Fix broken update with SQL error on PostgreSQL databases #30330

Merged

richard67 added a commit to richard67/joomla-cms that referenced this pull request Aug 10, 2020

Backport database changes from J4 PR joomla#30192

07f3a48

This fixes update from 3.10 to 4 failing with SQL error due to not existing database columns.

richard67 mentioned this pull request Aug 10, 2020

[3.10] Backport database changes from PR #30192 to fix broken updates from 3.10 to 4 #30333

Merged

joeforjoomla mentioned this pull request Aug 13, 2020

Update SiteApplication.php to initialize properly the template object caused by #30192 #30360

Closed

dgrammatiko mentioned this pull request Aug 13, 2020

[4.0] Feedback: Migration to V4 #30358

Closed

richard67 mentioned this pull request Aug 13, 2020

[4.0] Remove update SQL for child templates #30363

Merged

dgrammatiko mentioned this pull request Aug 16, 2020

[4.0] favicon changes to support child templates #30388

Merged

sakiss pushed a commit to sakiss/joomla-cms that referenced this pull request Oct 16, 2020

[4.0] Child templates for Joomla (joomla#30192)

04f0fcc

dgrammatiko mentioned this pull request Oct 24, 2020

[4.0] SCSS in Joomla #31091

Closed

dgrammatiko deleted the 4.0-dev-child-templates branch December 10, 2020 10:14

dgrammatiko mentioned this pull request Dec 26, 2020

[4.0] Tinymce adopts child templates #31785

Closed

dgrammatiko mentioned this pull request Aug 22, 2021

[4] Move JS file to the build folder #35281

Closed

dgrammatiko mentioned this pull request Feb 19, 2022

[4.1] update loses media assest #37057

Closed

dgrammatiko mentioned this pull request Feb 26, 2023

[4.2] Revert 39329 - Release Blocker #39943

Merged

dgrammatiko mentioned this pull request Jul 30, 2023

Fix for Issue https://github.com/joomla/joomla-cms/issues/41270 Loading Views #41274

Merged

2 tasks

		`inheritable` smallint DEFAULT 0 NOT NULL,
		`parent` varchar(50) DEFAULT '',

		@@ -0,0 +1,2 @@
		ALTER TABLE "#__template_styles" ADD COLUMN "inheritable" smallint NOT NULL DEFAULT 0;
		ALTER TABLE "#__template_styles" ADD COLUMN "parent" varchar(50) DEFAULT "";

Uh oh!

Conversation

dgrammatiko commented Jul 25, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary of Changes

Testing Instructions

Front End step 1

Front End step 2

Front End step 3

Front End step 4

Front End step 5

Front End step 6

Back End step 1

Back End step 2

Back End step 3

Back End step 4

Back End step 5

Back End step 6

Final checks

And the last one

Documentation Changes Required

Uh oh!

Uh oh!

Uh oh!

kawshar commented Jul 26, 2020

Uh oh!

dgrammatiko commented Jul 26, 2020

Uh oh!

Uh oh!

Fedik commented Jul 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dgrammatiko commented Jul 26, 2020

Uh oh!

Fedik commented Jul 26, 2020

Uh oh!

dgrammatiko commented Jul 26, 2020

Uh oh!

Fedik commented Jul 26, 2020

Uh oh!

dgrammatiko commented Jul 26, 2020

Uh oh!

Fedik commented Jul 26, 2020

Uh oh!

Fedik commented Jul 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dgrammatiko commented Jul 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Fedik commented Jul 26, 2020

Uh oh!

dgrammatiko commented Jul 26, 2020

Uh oh!

Septdir commented Jul 26, 2020

Uh oh!

dgrammatiko commented Jul 26, 2020

Uh oh!

Septdir commented Jul 26, 2020

Uh oh!

dgrammatiko commented Jul 26, 2020

Uh oh!

Uh oh!

HLeithner commented Jul 29, 2020

Uh oh!

HLeithner left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dgrammatiko commented Jul 25, 2020 •

edited

Loading

Fedik commented Jul 26, 2020 •

edited

Loading

Fedik commented Jul 26, 2020 •

edited

Loading

dgrammatiko commented Jul 26, 2020 •

edited

Loading