A few small changes.

Sun Nov 10, 2019 7:33 am

I did notice load times are a bit slower now, but tolerable. The posts are blank for a second or two. I'm in PsDE. I haven't tried any other styles.

Edit 1: Seems to only affect PsDE.

Sun Nov 10, 2019 3:43 pm

It usually loads page content almost instantaneously for me, but can be up to a second occasionally. If it was one second all the time I wouldn't tolerate it. If page content load times are consistently one second or longer at your end that's not good enough, so I'll have to think of something else.

What's causing it is the ability to switch colour variants in the footer. That has to run on javascript because phpBB doesn't provide any way of setting it via PHP, and the javascript takes a while to run sometimes.*

I might end up just splitting the colour variants into separate child styles. That way they'd still be selectable in the Quick Style dropdown, and no load time problems.

*Specifically, it's setting the colour variant via a cookie called in the body tag on page load. The content doesn't appear until the cookie loads the relevant stylesheet.

Sun Nov 10, 2019 4:55 pm

Ah! Javascript. That explains it. That's why the 1 or 2 second delay. Plus the fact that I'm about 18 hours behind you.

Actually, I'm not sure where the site server is now. I know it's not down under.

I think you said it's somewhere in the EU.

Sun Nov 10, 2019 5:06 pm

It's in Paris.

The delays in rendering are due to croissant crumbs in the hard drive.

Ok seriously, what sort of connection are you on? I'm going to run some speed tests and see if I can improve the page load performance. If you know roughly what speed your connection is, that would be useful for setting test parameters.

I think I'll set up a test site in a subdomain. That way I can run PSDE as the default style for the test site, and (hopefully) get accurate results.

Edit: Been reading up on javascript trickery. Turns out that the event recommended in the code I used...

Code: Select all

<body onload="set_style_from_cookie()">

...is a problem, because it won't fire until absolutely everything has loaded completely (right down to the last little icon). The MDN docs say:

A different event, load, should be used only to detect a fully-loaded page. It is a common mistake to use load where DOMContentLoaded would be more appropriate.

The difference being that DOMContentLoaded fires as soon as you can actually apply javascript and have it work. So if I change the event to...

Code: Select all

<body onDOMContentLoaded="set_style_from_cookie()">

...then hopefully things will be a lot more user-friendly. I'll set up a test copy so I can mess around without it.

Mon Nov 11, 2019 2:15 am

@Hawk: is the loading on PSDE any better for you now?

I've tweaked the javascript, and it seems to be smoother and faster at my end. Some page loads are a bit slower than others (vagaries of teh interwebz) but generally it's behaving pretty well for me. If it looks ok for you too, I think we can call it sorted.

Mon Nov 11, 2019 3:39 am

You didn't ask me.... but I noticed an improvement. I had an up to 0.5 sec time waiting for the text to fill on a full page. Now I don't notice it at all.
Overall loading seems a bit quicker now as well. Of course that may be down to the unreliability of my connection. On my end the current setup seems to be working well.

Mon Nov 11, 2019 4:12 am

Oh good. I didn't ask you because you weren't complaining about it, but if it's better then that's a good thing.

I can tweak performance up a bit more. I'm currently studying up on that sort of thing. It's quite interesting stuff.

One detail is that phpBB uses @import rules to amalgamate stylesheets into one, like this:

Code: Select all

/*  phpBB3 Style Sheet */

@import url("normalize.css?v=3.2");
@import url("base.css?v=3.2");
@import url("utilities.css?v=3.2");
@import url("common.css?v=3.2");
@import url("links.css?v=3.2");
@import url("content.css?v=3.2");
@import url("buttons.css?v=3.2");
@import url("cp.css?v=3.2");
@import url("forms.css?v=3.2");
@import url("icons.css?v=3.2");
@import url("colours.css?v=3.2");
@import url("responsive.css?v=3.2");
@import url("dark.css?v=3.2");

The theory being that you only have to call the one stylesheet in the head of your page, and it takes care of the other ones. Only problem is it doesn't do any good.

For instance, if first.css contains the following content:

@import url("second.css")

The browser must download, parse, and execute first.css before it is able to discover that it needs to download second.css.

So all it's really doing is adding a pointless request to the server, to tell the browser that oh yeah, it needs to go back to the server to get the other ones. The page would actually load faster if the other ones were just called straight in the head of the page, and stylesheet.css was given the bum's rush.

Mon Nov 11, 2019 7:32 am

Still seems to be happening for me. It's not that big of a deal really. I just thought I'd mention it. Also, maybe my statement of it being a 1 to 2 second lag was a bit of a stretch. It's more like .5 to 1. Sorry!

My connection speed is about 30 Mbps (3.75 MBps), for what it's worth.

Shame that '@member_name' doesn't work in phpBB like in other forum software.

Mon Nov 11, 2019 8:55 am

Yes the @ thing can be handy sometimes. Anyway I'll keep tweaking the performance thing. If I can't get it near perfect what I'll do is just split out the ones we want into separate styles, then they can all be enabled in the Quick Style dropdown. The difference between them is only one CSS file, and they can inherit the modified templates from one parent example. So it would be easy to set up and maintain even if there were nominally a dozen separate styles, because really you'd only be maintaining one. That would definitely be lightest for performance.

Mon Nov 11, 2019 9:16 pm

Turns out there is a "mentions" extension that lets you tag people: https://www.phpbb.com/customise/db/exte ... _mentions/
I downloaded it for a look. It's awesome. Creates two new CSS files for a few bytes of code each. Whoopee teh performance!

But I can put the code in an existing file (of which phpBB has truly awesome amounts) when I can be bothered, and ditch the superfluous ones.

Tue Nov 12, 2019 5:47 am

Hey check this. I ran a few speed tests, using a moderate network connection (3G I think) from Florida (nearest to northern GA that they had).

https://www.webpagetest.org/result/1911 ... 95af6d4e6/

The diagram shows the load processes for a first visit to the forum (ie: no cookies set, no files cached). It's interesting stuff.

The server can have 6 parallel connections downloading stuff, so a maximum of 6 files downloading at the same time.

This means if you can halve the number of files by amalgamating tiny ones, things go faster.

Actual HTML only takes 1.1 seconds to download. The rest of the waiting time is all the other crap.

The first CSS file to download is stylesheet.css. That's the one that wastes a request, because it only contains @import rules for other files (which download much later), so this is all wasted time. If this file was ditched that would save 1/3 of a second right there.

The second CSS file to download is for the Font Awesome icons, and it holds up a connection for 2/3 of a second. But, it's useless until the actual font file it applies to is loaded, and that isn't downloaded until much later (number 39 on the list). And all it does is make a handful of cute little icons anyway. So font-awesome.min.css is a prime candidate for deferred downloading. It's early place in the queue could be taken by something more immediately useful.

The next file (theme/en/stylesheet.css) only does one thing. It puts the little diagonal "Online" stripe to the right of your avatar if you're online. To do that, it holds up a connection for half a second. This is rather stupid. It would make more sense to put that tiny amount of code at the end of one of the later files.

The next one to hit the queue is cookieconsent.css, which holds up a connection for another half a second. But, the cookie consent form relies on javascript to run, and the javascript won't function until the DOM Content Loaded event, which happens 2.7 seconds later. IOW, this CSS file could be deferred too.

Buttonmenu.css is up next, and this one is actually useful (does the top site menu bar). Yay!

The next one is postingbuttons.css. That one isn't required at all on most pages. It's only used when you're actually using the replies editor. It could usefully be removed from the head of the page, and called lower down in the posting template.

Similar situation for quotethumbnails.css (#8). It's only used when you're inside a thread, so there's no point calling it anywhere else. Same goes for #11 (lightbox.css). Lightbox.css is useless without lightbox.min.js (#20) anyway, so these should ideally only be called inside threads.

Numbers 9 and 10 (collapsiblecategories.css and boardannouncements.css) are useful early in the game, so probably leave those alone.

Now we get to the first on the javascript files (jquery.min.js) and apart from the jpg banner it's the biggest file of the lot. For one thing, this beast could have been downloading 0.4 seconds earlier if the less important files before it were rationalised. For another thing, there's a handy trick you can do with javascript files. You can set them to defer:

Code: Select all

 <script src="demo_defer.js" defer></script>

What this does is stop them blocking other files while they are downloading, so effectively it makes more connections available. In other words, if all 9 javascript files are set to defer, normalize.css (#21) would start downloading 0.8 seconds earlier.

The other point is that at the moment I have the javascript for assigning the multiple Prosilver Dark Edition stylesheets after jquery.min.js and some of the other javascript files. If I put it in front that should reduce the "flash of unstyled content" problem with PSDE.

Normalize.css and the next 10 CSS files are the ones that were called by @import in the stylesheet.css back at #2, but it's only now they get around to beginning to download. Something tells me this is not optimal. And again, if some can be amalgamated that will free up connections.

#33 is the one smiley I put in the board announcement, and by itself that blocks a connection for 1/3 of a second. By this time we're out to around 3.4 seconds since first contact, and could easily have knocked that back to under 2 seconds (even with the smiley).

The rest of the time until completion is images and the Font Awesome font file. Site-logo-mine.gif will be disappearing, to be replaced with text that is part of the banner image.

The banner itself could be optimised some more, and that could probably knock off another half a second until page completion.

The remaining images aren't a big deal at this stage.

So there ya go. Looks like a 5 second time to completion could be cut down to about 3 seconds.

Edit: Oh yeah, while I think of it, Font Awesome has around 700 icons, and phpBB only uses less than 1/3 of them, so in theory font-awesome.min.css could be cut in size by around 2/3 by getting rid of rules for icons that aren't used. And then the rest of the CSS and javascript files can be minified too, which is not at all difficult and can save even more time.

Tue Nov 12, 2019 8:22 am

It looks like that test runs on the default style. Maybe set the PsDE to default temporarily and run the test again on it, just for scientific testing purposes.
That is, unless you already know everything you need to know.

Tue Nov 12, 2019 3:36 pm

Ok, running that test now.

Edit: First test results.
Connection chosen as "DSL (1.5Mbps/384Kbps 50ms RTT)" from Orlando, Florida.
3 different runs, with massively different completion times, varying from 4.9s to 14.0s.
https://www.webpagetest.org/result/1911 ... ce7778e1d/

The second run, with a 14.0s time to completion on first view, appears to be an anomaly. Most files downloaded normally, but yellow.css somehow got blocked up by eddies in the space-time continuum and took yonks to download. It's only tiny, like the other colours files, so there must have been a blockage in the network.

The third run appears to be a close match for the previous test with the default Prosilver. But I'd actually expect Prosilver Dark to be slightly slower anyway due to the extra CSS files it contains, along with a tiny bit of extra javascript.

This is how the CSS files for colours are listed in the head of the page:

Code: Select all

<link href="{T_THEME_PATH}/colours/grey.css?assets_version={T_ASSETS_VERSION}" rel="alternate stylesheet" title="grey">
<link href="{T_THEME_PATH}/colours/blue.css?assets_version={T_ASSETS_VERSION}" rel="alternate stylesheet" title="blue">
<link href="{T_THEME_PATH}/colours/green.css?assets_version={T_ASSETS_VERSION}" rel="alternate stylesheet" title="green">
<link href="{T_THEME_PATH}/colours/orange.css?assets_version={T_ASSETS_VERSION}" rel="alternate stylesheet" title="orange">
<link href="{T_THEME_PATH}/colours/pink.css?assets_version={T_ASSETS_VERSION}" rel="alternate stylesheet" title="pink">
<link href="{T_THEME_PATH}/colours/purple.css?assets_version={T_ASSETS_VERSION}" rel="alternate stylesheet" title="purple">
<link href="{T_THEME_PATH}/colours/red.css?assets_version={T_ASSETS_VERSION}" rel="alternate stylesheet" title="red">
<link href="{T_THEME_PATH}/colours/yellow.css?assets_version={T_ASSETS_VERSION}" rel="alternate stylesheet" title="yellow">
<link href="{T_THEME_PATH}/colours/snowy.css?assets_version={T_ASSETS_VERSION}" rel="alternate stylesheet" title="snowy">
<link href="{T_THEME_PATH}/colours/green_light.css?assets_version={T_ASSETS_VERSION}" rel="alternate stylesheet" title="green_light">

Based on that, I'd expect grey to load first. It's the one set by default if there is no user cookie already set. But it doesn't load until #42 on the queue, which is 0.4 seconds after orange.css. Beats me why, but that's what happened.

Grey.css will be the one that shows all the post content, and it's still loading after the DOM Content Loaded event (which is when the javascript sets the colour) so that's a flash of empty posts right there. Looks to be around 0.2 seconds.

Oh, and basic rendering starts around 1 second earlier than grey.css starts to download.

So here's a thing. Alternate stylesheets aren't applied, even though they are all downloaded. One doesn't get applied until DOM Content Loaded, so it's critical that the required sheets is available then to minimise "empty stuff everywhere".

The banner is downloading at #35, then the board announcements close.png at #36, then the wink smiley at #37. That's the order they would appear in the markup, so that makes sense.

Normally stylesheets would be downloaded in the order they are listed in the head of the page, but maybe having them declared as "alternate" screws with this. Blue.css is listed first after grey.css, yet for some reason blue.css was the last to connect and download, even though it was "discovered" at the same time as grey.css.

And all of the alternate colours stylesheets are not downloading until after the banner, close.png and wink smilley, even though the stylesheets are called in the head and the images obviously aren't called until you're into the body.

This is a PITA, because you really want the stylesheets loaded first, so something has to be done about that. At the moment I'm not sure what is required.

The repeat view for this run (ie: with files and cookies already cached) comes in at 2.1 seconds.

Basic rendering starts at 1.53s, and the style isn't set until 1.85s, so that's a third of a second of empty posts there. Which makes sense given what we've been seeing, and pretty much ties in with the results from the first view. Overall time to completion is around half, and so is time between first render and the colour stylesheet being set.

Tue Nov 12, 2019 3:58 pm

Second test results.
Connection chosen as "DSL (Cable 5/1Mbps 28ms RTT)" from Orlando, Florida.
3 different runs, with completion times varying from 2.9s to 5.5s.
https://www.webpagetest.org/result/1911 ... 60f496ceb/

The longest time of 5.5s seems to be more web gremlins. DNS took about 2.4 seconds to get its act together. The previous test on the slower connection was getting DNS times around 0.2-0.3 seconds, so the 5.5 seconds time to completion on DSL/Cable looks like an anomaly.

The other two runs are grouped pretty closely each side of 3 seconds, so that's probably about where the benchmark should be for cable.

Working through Run #2 (3.2s to completion) there are some weird things happening. Hey, it's the internet.

This time the wink smiley for the board announcement has jumped the queue and is butting in at #12. No idea how that happened, and it's definitely not optimal behaviour.

The rest of the files seem to be following pretty much the same load order as previous runs.

The alternate colours CSS files are downloading in (exactly) the same strange jumbled order as before. Appears to be no logic to it, but there must be in computer terms.

Code: Select all

 5th to download: <link href="{T_THEME_PATH}/colours/grey.css" title="grey">
10th to download: <link href="{T_THEME_PATH}/colours/blue.css" title="blue">
 3rd to download: <link href="{T_THEME_PATH}/colours/green.css" title="green">
 1st to download: <link href="{T_THEME_PATH}/colours/orange.css" title="orange">
 2nd to download: <link href="{T_THEME_PATH}/colours/pink.css" title="pink">
 4th to download: <link href="{T_THEME_PATH}/colours/purple.css" title="purple">
 6th to download: <link href="{T_THEME_PATH}/colours/red.css" title="red">
 9th to download: <link href="{T_THEME_PATH}/colours/yellow.css" title="yellow">
 8th to download: <link href="{T_THEME_PATH}/colours/snowy.css" title="snowy">
 7th to download: <link href="{T_THEME_PATH}/colours/green_light" title="green_light">

Grey.css (the one that will be applied in this case) is still downloading after DOM Content Loaded (when the javascript sets the colour).

This will give approximately 0.15s of missing content, from start of rendering at 2.6s to grey.css fully downloaded at 2.75s. Which is getting down to human reaction times (for a younger human than me) so isn't too bad, but could obviously be better if that file could be downloaded earlier.

In this run it look as if deferring the javascript files would be enough to get all the CSS files loading before rendering starts, which is obviously what you want in an ideal world.

Another idea. I don't think we'll ever want all of the dark variations, and there are 8 of them, and each variant file is less than 2Kb. It might be worth just using four or five of them, and putting the code for them in dark.css. This means always loading more CSS than is strictly required, but on the other hand it's not that much and it saves downloading extra files. The colour change can be done by using the javascript to append a class to the body tag. So body.grey in the CSS would call grey links, etc, while body.red would call red ones. Looking at the waterfall for this run, I think that trick could get styling sorted in next to no (visible) time.

Tue Nov 12, 2019 5:54 pm

RulerofRails wrote: ↑Tue Nov 05, 2019 1:07 amOff-topic: What are the restrictions on the advanced search and ignored words? Some words like "industry" are ignored. Which maybe is fine because who would search just that. But sometimes when I do a search I want to put something like "industry profit" and it's not possible from what I can tell. Is that something that saves server bandwidth (a good thing). I have no idea, just wondering if the update did anything for search capabilities?

I think I have this sorted now. The way it works is a bit bonkers. There's an admin setting for "ignore words that are too common" and it works off the percentage of posts they appear in. So you might think that if you set it to 10% it would only skip words that were in 10% or less of posts, and would index any words that were in 90% or more of posts.

It's the other way around though. It will skip any words that are in a greater percentage of posts than what you set in admin. So if you set it to 2%, it will skip any words that are in 3% or more of posts. So I've just set it to 33% for a trial run, which should hopefully mean that words we want to find will be easier to find.

The other thing I forgot before is that for the new setting to work you have to delete the old search index and build a new one, because otherwise existing posts are still indexed under the old setting. I've now done that too. Give the search another few test runs and see if you like it better now.

Wed Nov 13, 2019 8:57 am

Well, I guess it is what it is, eh Gumboots?

Wed Nov 13, 2019 9:41 am

It'll work alright. It's just not quite what I expected. Now that we know what it does, it should be easy enough to find a setting that works for everyone.

The other thing is I spent the day swotting up on javascript, and I'm pretty sure I can massively cut the amount of code needed to run the variant switcher. Should give faster initial loading too. I'm going to run some trial code on a test site, or maybe on a spare test copy of a style on this site. But it's looking like the while thing will run off 9 lines of js, which would be very cool if there are no glitches.

Wed Nov 13, 2019 7:35 pm

Woooooooooooooooooooooooo HHHHHHooooooooooooooooooo!

I got my nifty Prosilver Dark variant switcher working with hardly any code.

All it needs in in the footer (for the change buttons) is this:

Code: Select all

<script>
	function change_variant(clicked_id)
	{
		document.cookie = "local127_prosilver_dark=" + clicked_id + "; domain=127.0.0.1; path=/phpBB3; max-age=3600";
		document.getElementById("stylesheet").href = "{T_THEME_PATH}/colours/" + clicked_id + ".css?assets_version={T_ASSETS_VERSION}";
	}
</script>

That's it. That's all the javascript required. It resets the cookie, and rewrites the stylesheet url, when you click any button. The colour change is instant. The buttons themselves are this:

Code: Select all

			<p class="footer-row">
				<button id="blue"	onClick="change_variant(this.id)"></button>
				<button id="green"	onClick="change_variant(this.id)"></button>
				<button id="grey"	onClick="change_variant(this.id)"></button>
				<button id="orange"	onClick="change_variant(this.id)"></button>
				<button id="pink"	onClick="change_variant(this.id)"></button>
				<button id="purple"	onClick="change_variant(this.id)"></button>
				<button id="red"	onClick="change_variant(this.id)"></button>
				<button id="yellow"	onClick="change_variant(this.id)"></button>
			</p>

Which is pretty simple too. Couldn't be much simpler.

Then it needs a bit of javascript up in the head of the page, to pick up the cookie value when you load a new page and rewrite the stylesheet link to your selected preference. That works like this:

Code: Select all

<script>
	function getCookie(local127_prosilver_dark) {
		if (document.cookie.length > 0) {
			c_start = document.cookie.indexOf(local127_prosilver_dark + "=");
			if (c_start != -1) {
				c_start = c_start + local127_prosilver_dark.length + 1;
				c_end = document.cookie.indexOf(";", c_start);
				if (c_end == -1) {
					c_end = document.cookie.length;
				}
				return unescape(document.cookie.substring(c_start, c_end));
			}
		}
		return "";
	}
</script>

And then just down the page a bit it picks up the stylesheet link like this:

Code: Select all

<link href="{T_THEME_PATH}/colours/grey.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" id="stylesheet">
<script>
	document.getElementById("stylesheet").href = "{T_THEME_PATH}/colours/" + (getCookie("local127_prosilver_dark")) + ".css?assets_version={T_ASSETS_VERSION}";
</script>

So if javascript is screwed, or if there is no cookie set, it just falls back to whichever variant you set as default (grey, in this example). In other words, it should be unbreakable. Then as soon as someone clicks on a colour change button their cookie gets reset, and the code up in head reads the new cookie value and dynamically rewrites the stylesheet link for you. But this rewriting is only while javascript is active, so if it goes borked for some reason, or if you disable javascript in your browser, it just falls back to the default grey again (because that's what is actually written in the HTML).

Now this all works smooth as silk with a desktop test site on local. I'll have to set up an online example and see how that goes. I think it should be faster on page load than the current switcher, but I'll have to check to make sure.

Thu Nov 14, 2019 8:54 am

That sounds great!

Why not just try it on this live site. Just back up what you had in case something goes awry.

What I did was create a sub-domain and copied the forum to it and used that as a test site, if you have the storage space on the server.

Thu Nov 14, 2019 3:06 pm

I am going to try it live here. I just didn't want to do it late last night.

I've also been thinking an online test site is a good idea. What I did last week was grab one of the forum backups from the server and import it on local so I had a good desktop test site. This turned out to be easy to do. My local server (I use Vertrigo) has limits in the phpMyAdmin config and I couldn't be bothered messing around with them, so I figured out how to import the db from the command line. That turns out to be easy once you've done it, and the whole db imported perfectly on about one second flat (oodles faster than phpMyAdmin).

I then dropped all content from the private messages tables (because they're private and not for test sites, obviously) and pruned the members down to about a dozen, then changed passwords and emails on those so there's no personal information left and I can use the accounts for testing. So this is a good basis for any test site. It has the same boards and permissions as this one, and a lot of the visible content, but is smaller and easier to handle. And if anyone wants to use their account on it I can set their emails and passwords to whatever they want for access.

I'm also going to minify some of the default CSS files. I had a quick play with that on local last night and it seems to be fine (as it should be). phpBB themselves make dark warnings about minification, but your average online minifier these days is pretty good. I found if I take all the files that are imported by the (useless) stylesheet.css a quick bit of minification knocks about 1/3 off the overall byte count. Then I amalgamated a few of them to cut the number of requests from 13 to 6. Again, not something I wanted to try live on the site late last night.

I've just been looking at the CSS files for some of the extensions, and they can be improved too. Some are so trivial they can be amalgamated with another file, and general cleaning up and minification will help the rest (five minute job per file). So hopefully I'll be able to get the thing loading decently on any reasonable connection.

Oh yeah, I took that javascript for the changer and ran that through one of Google's online compression gizmos. That got the js squeezed down quite significantly too, and used some interesting syntax to do it. The stuff down the bottom (just under the buttons) came out like this, and still seems to work the same.

Code: Select all

<script>function change_variant(a){document.cookie="local127_prosilver_dark="+a+"; domain=127.0.0.1; path=/phpBB3; max-age=3600";document.getElementById("stylesheet").href="{T_THEME_PATH}/colours/"+a+".css?assets_version={T_ASSETS_VERSION}"};</script>

Since you'll only ever have to edit it to use the required cookie name, domain and path this is a rare instance when the minified version is as human-friendly as an expanded version (minified js is usually seriously gruesome for humans).

The javascript in the head came out like this:

Code: Select all

<script>
	if(0<=document.cookie.indexOf("local127_prosilver_dark")){var getCookie=function(a){c_start=document.cookie.indexOf(a+"=");return-1!=c_start?(c_start=c_start+a.length+1,c_end=document.cookie.indexOf(";",c_start),-1==c_end&&(c_end=document.cookie.length),unescape(document.cookie.substring(c_start,c_end))):""};
	document.getElementById("stylesheet").href="{T_THEME_PATH}/colours/"+getCookie("local127_prosilver_dark")+".css?assets_version={T_ASSETS_VERSION}"};
</script>

Which is fine too, since it'll only ever need cookie name and path edited.

Hawk & Badger Railroad Forum

A few small changes.

Re: A few small changes. Unread post Sun Nov 10, 2019 7:33 am

Re: A few small changes. Unread post Sun Nov 10, 2019 3:43 pm

Re: A few small changes. Unread post Sun Nov 10, 2019 4:55 pm

Re: A few small changes. Unread post Sun Nov 10, 2019 5:06 pm

Re: A few small changes. Unread post Mon Nov 11, 2019 2:15 am

Re: A few small changes. Unread post Mon Nov 11, 2019 3:39 am

Re: A few small changes. Unread post Mon Nov 11, 2019 4:12 am

Re: A few small changes. Unread post Mon Nov 11, 2019 7:32 am

Re: A few small changes. Unread post Mon Nov 11, 2019 8:55 am

Re: A few small changes. Unread post Mon Nov 11, 2019 9:16 pm

Re: A few small changes. Unread post Tue Nov 12, 2019 5:47 am

Re: A few small changes. Unread post Tue Nov 12, 2019 8:22 am

Re: A few small changes. Unread post Tue Nov 12, 2019 3:36 pm

Re: A few small changes. Unread post Tue Nov 12, 2019 3:58 pm

Re: A few small changes. Unread post Tue Nov 12, 2019 5:54 pm

Re: A few small changes. Unread post Wed Nov 13, 2019 8:57 am

Re: A few small changes. Unread post Wed Nov 13, 2019 9:41 am

Re: A few small changes. Unread post Wed Nov 13, 2019 7:35 pm

Re: A few small changes. Unread post Thu Nov 14, 2019 8:54 am

Re: A few small changes. Unread post Thu Nov 14, 2019 3:06 pm