Wedge

I will note that only a handful of those who got beta access previously actually bothered to say anything to us afterwards, distinct lack of feedback all round, really.

There is also the other problem: if we were to do a release right now, aside from all the changes still to come, you'll complain that it's buggy and/or unfinished... well, duh, we know. There are still a number of unfinished areas, still a number of things that just don't work properly, some that probably just need to be removed entirely (I'm thinking the alternate theme area, and certainly the editing-from-the-admin-panel stuff)

Right now, complaining that you can't have awesome stuff is a better complaint than complaining about how not awesome it is.

Oh, and if you were *really* interested in what we're doing, you'd be reading more of the forum and replying. Not just moaning (now on multiple occasions) about how you can't have it yet.

EC2 is virtual servers, you run up and down instances to suit demand.

I do not think cPanel would work properly on an EC2 instance anyway.

(2 files, 1KB)

Revision: 2083
Author: arantor
Date: 30 April 2013 00:38:43
Message:
! Board selection from generic settings template needed a little tweaking. (Admin.template.php)
! Better handling of empty values for generic settings and fix an edge case where an empty value could be ignored. (ManageServer.php)
----
Modified : /trunk/Sources/ManageServer.php
Modified : /trunk/Themes/default/Admin.template.php

A complete and more powerful replacement.If you mean what's already committed, check what it is. It is not the warning system, it's the moderation centre which is sort of needed for the board index since that's what's happening, a new virtual category that contains virtual boards. I forget, I haven't committed half of this because of the ever sprawling changes.Every language has its variations, which is precisely why we get into English US vs English UK, or Portuguese BR vs Portuguese PT and so on. Extra files are going to need to be maintained for those, it's not avoidable.

The only real difference as far as parent language goes is how much difference there really is. English UK vs English US has some major differences but it also has an awful lot of similarities, so it would make sense to have the parent language.

The parent language aspect does sort of require the other language to be installed. If you want to set up a forum for local events in Portugal (emphasis: Portuguese/PT), that's fine because presumably it's the parent language. But if you want to install a forum for local events in Brazil (emphasis: Portuguese/BR), you then need to install *two* language packs. This is not intuitive even if it is documented somewhere.

I don't know how significant the differences are - though I did ask for some feedback on this - but the impression I've been given is that the variations are big enough to warrant two sets of language files being maintained.Let's take that as a practical example. Yes, you're probably right in that it probably wouldn't need a complete set of files.

However, that does make language loading more complex (in trying to report missing files etc.) and more importantly: is it logical or appropriate to ask those forum cases to install *both* French and the Québecois language files? (Ignore, for the moment, that French is already bundled)

Technically, English UK should be a complete full set of language files, it only isn't because I'm essentially too lazy to do so and I know that English US is *always* loaded because there must be a fallback for error-prevention-in-incomplete-translation purposes.

If the situation were reversed, and French were the only bundled language, with English US being the primary and English UK being a secondary, if I were setting up a forum for *British* users (i.e. the minority speakers), I would not want to install both English US and English UK, even if I only made English UK selectable by users.


As far as suffixes go, I've always seen where it could be practical but I've always had the feeling it's going to be a feature that no-one but you is going to use anyway :(

Back on topic, it seems that it is working as expected elsewhere with that code, so I don't know why it is in normal execution. (At least, attachments are working even when > 4MB)

Checking whether the old 'less optimised' code causes the same problem under the same conditions. I've been busy with RL stuff today but I'll check it tonight.

That and I'm fed up of the infractions code but I can't commit it in its present state because I don't want to have something in SVN that actively limits what we can do on here in the meantime. And all the other things I've been thinking of doing are not small projects >_<

I don't know what's best with suffixes.

I'm not sure it's ever actually worked properly since it was 'optimised'.

How often did the @while(ob_end_clean()); line actually run before? Seems to me that the lines we had before have a very slightly different behaviour to them because this is closing even the default output handler when it shouldn't.

I was surprised to find that every 90 odd seconds, I was seeing weird errors from the unread notifications lookup. Every time was the same, unexplained failure - no concrete reason, every request was simply left as 'pending'.

After some digging, I found there is one consistent reason for this: return_raw forces all the buffers to close. The problem is, doing that seems to cause it to screw up - in my case *every* request was failing because of this.

Bizarrely, if I don't close the output buffers, it works exactly as expected for me, behaves consistently regardless of setting. (All I did was comment out that line)

If the end-buffers line is left alone, it only works if enableCompressedOutput is disabled.

Curiouser and curiouser, I added the following debug code before the end-levels line:

With it enabled:With it disabled: