Make new post
GUROchan Feedback
This is the thread for all sorts of feedback you might have on GUROchan.
I know I'm about to spew forth a technical tirade that little of you will be able to comprehend or care to read at all, but I just can't keep my boiling hatred inside anymore, my pain of dealing with vichan imageboard software is overwhelming. So, I have rewritten major portions of current GUROchan codebase after some profiling to speed up the whole thing. I know that I promised you all a brand new imageboard software, but it isn't going well enough due to my perma-apathetic mood and lack of motivation. It will happen someday, that's the most I can promise right now. Nevertheless, I've reached my boiling point with the current code in production: vichan. No words can describe just how bad it is technically. I'll give you this: 50% of my reasoning was ideological, running this software actually hurts my feelings, literally, just thinking about our hardware executing its incredibly poorly written code insults me and pisses me off. I am ashamed of using it, no kidding. vichan is just unbelievably shitty, it is one of the worst pieces of PHP software I've ever seen, written by fucking kids who learned a few basics of PHP and MySQL and thought: "Hey wow, now I can write my own cool imageboard with it! New and improved! With blackjack and whores! Yay! Time to get busy!" You know, the usual train of thought of a hyped up overexcited dumbass teenager, utterly awkward. No shit, they did it. Did it with zero experience and not a fucking yota of knowledge of even basic computer science topics it takes to produce anything at least remotely good. You get this impression instantly by just glancing at the vichan source code. "For teenaged morons by teenaged morons" as their motto goes unspoken.

To those who wonder what might be wrong with the aforementioned approach, here's a hint: NO, that's not how software is written. First, you sit down and study computer science, algorithms (Knuth before all), programming ideas, principles, and paradigms. Then you analyze your task and explore and evaluate the tools needed to do it, google around, ask for tips and pointers. Then you pick your tools (PHP+SQL in our case) and study them thoroughly by reading technical literature available in rich selection. Then you make up a complete plan of what you are going to do, and how exactly, usually employing the "divide and conquer" principle by breaking up the task into logically orthogonal interacting units. And only after all of that you actually start writing code unit by unit. And finish with testing (+ regress-testing for updates), debugging, profiling, and optimizing. At least that's how I've been taught... But apparently not this shitshow crew behind Tinyboard and vichan.

Here's a quick list that highlights some of the more blatant, awkward, and outright atrocious moments and topics the sorry authors of Tinyboard and vichan have no fucking clue about. "Doing it wrong" – heard this idiom? Here, know your meme:

– PHP. No, they don't know how to program in PHP properly. In fact, they just don't know how to program. Consider the most trivial thing: code reuse: their shitcode is ridiculously and horridly repetitive, they write the same shit all over and over again instead of packing it into a simple function or class method. Really, why bother with writing functions when I can just copypaste? So what if my source file is 1000+ lines of code when it could be 150? Why extract() associative arrays representing database table rows into the current scope for ease of use and one less level of Zend namespace lookups when we're trained to write array subscripts everywhere? Who cares if each unextracted array access results in two hash table lookups instead of one? Zend engine, PHP internals? Who cares what goes on behind the scenes, we simply pretend we didn't know that PHP was interpreted. Go eat some shit you little PHP wannabe kids.

– Object-oriented programming: they don't know how to write and use classes to their advantage, let alone such cryptic words as "encapsulation" or "inheritance", so they avoid them, and when they actually do use the OOP approach (Thread, Post, and Bans classes), they do it all wrong as usual. Really, why bother encapsulating entities as autonomous, self-contained objects when we can litter all our code with global variables and thus have no need to toss around data between functions. Why use objects instead of arrays, so what if you can encapsulate logic into them as methods? We're just fine littering the global namespace even more with plain functions. Look, inc/functions.php will soon be reaching 3000 lines of code, we're just that awesome! Irredeemable programmer failures.

– SQL: no idea about relational database architecture in general, about proper usage of SQL types and constraints, non-existent schema normalization, clueless about business logic encapsulation with stored procedures and triggers, they never heard of views that could make their queries in PHP compact and elegant, equally make no use of correlated subqueries where they should be used (instead doing it all manually from PHP query-by-query in loops, i.e. tons of wasteful and inherently slower PHP shitcode when it all could be expressed with a single correlated SQL subquery), they know literally nothing beyond primitive SELECT and INSERT/DELETE/UPDATE, which is like spitting in the faces of SQL inventors who took time to make it as powerful as it is in hands of those who actually know how to leverage its power. These guys think SQL is all about simplistic queries like "SELECT shit FROM code WHERE software = vichan"–no wonder they have to write tons over tons of absolutely meaningless, redundant code, reinventing the wheel again and again. Pathetic to the core, but really just a matter of a week of careful reading of an SQL textbook, but these youngsters don't have time to waste on something as old-fashioned as reading and learning–they must create here and now.

– Data integrity: the database schema doesn't have a single foreign key when there are dozens of places where they should be used. Not to mention the completely idiotic "each-board-gets-its-own-posts-table" partitioning idea that prevents me as an end user to write generic, board-agnostic stored procedures and queries with static, pre-computed plans. Their approach to database schema reeks of premature optimization and total ignorance of what "relational" in "relational database" is all about.

– "Transactions? Unheard of." PHP and MySQL/InnoDB have all the means to provide full transactional integrity to all IB operations (including coherent cache invalidation by employing gumballs as described in a well-known academic paper), and at little cost code-wise, but the fuckers have no clue about such high topics. Combine this with their moronic way of issuing myriads of primitive SQL queries instead of one and stitching the results together manually, and you get a case where two concurrent operations can easily fuck each other in the ass by interleaving and yielding corrupted results, in certain places possibly leading to permanent database corruption, since none of the integrity insurance means provided by MySQL are being used.

– Oh, database corruption, yeah! We have some experience here. They sort threads in boards by fucking timestamps! Timestamps, Carl! Very sloppy™ design decision. Not just short-sighted and foolish, but actually dangerous and potentially leading to data loss. Real production example: we once had a firmware CMOS battery fault that reset the server clock, making new threads date January 1970. Remember when many threads were suddenly gone?.. Now you know why. Hint: every time-sortable table row must be sorted by a surrogate timestamp, that is, a unique numeric table column continuously increasing for each insertion or update, no exceptions. AUTO_INCREMENT for MySQL and SERIAL types and SEQUENCE objects for PostgreSQL with automatic updating by triggers is the only technically sound way of doing bulletproof sorting. Otherwise a system clock skew can easily lead to unforeseen and disastrous consequences, just like what happened to us.

– The HTTP protocol and server-gateway relationship: improper use of HTTP status codes, emulated "soft" error pages, no HTTP cache control whatsoever, doing shit in PHP that doesn't belong there and should be done on the HTTP server level (authentication, caching, and post flood protection among others.) Why the hell call PHP (a costly operation that in our setup involves establishing a UNIX domain socket connection to PHP-FPM and forking PHP-FPM itself) to execute a bunch of trivial math formulas to do flood control when you can leverage much better rate limiting means of your HTTP server? They aim to support many setups, as such not tying to particular software, but you've got to know where the responsibility border line goes: a PHP script is not supposed to rate-limit itself, it is the job of whatever executes that script. Whoever doesn't understand this simple truth shouldn't be writing programs.

– Configuration in PHP. Sloppy™! There's parse_ini_file() designed specifically for reading array-based configuration from INI files, you pitiful ignorant shitheads. Or JSON, if you want more flexibility. Or YAML. Or XML. You name it. While marginally slower, all of these methods are more appropriate from the logic/design standpoint. Did you know that vichan's stock example config file is about 70% of all of my new IB's code? But that's not the point: IB configuration should be stored in the database too, for fuck's sake, not some .php file. That's what the database is for, it is used to store data, everything related to a particular instance or installation, i.e. precisely for the purpose in question. Yet these morons have no clue as usual, keeping part of data in the database and the rest in .php files. You can't just backup the database, you have to backup code itself, which is supposed to be plug-in downloadable from vendor repository when re-deploying from backup. Then again, MySQL supports LOBs for in-database storage of files–it takes as little as an extra table for LOBs, a table for post-to-LOB mapping, and two ON DELETE CASCADE foreign keys to make the entire thing self-contained (images in the database, easy backup), transactional, with data integrity guaranteed by database journal, and without all the shitty code vichan has in clean() for deleting files: a single DELETE SQL query, and files are gone along with their respective posts automatically, completely effortless and transparent.

– Security and cryptography: passwords for posts are stored in plaintext (sic!) No hashing, not even UNIX crypt(3)! I'd rip the face of the moron who made it so should I meet him in streets. Moderator account passwords are hashed using one of the lamest homemade crypto combinations of hash functions I've ever seen (second only to UnrealIRCd IP address cloaking) that add exactly zero cryptographic merit to each other whereas a single moderate-rounds call to a decent, mature, proven cryptographically sound KDF like bcrypt, scrypt, Argon2, or even the aging PBKDF2 would make it flawlessly neat and stronger than any MD5/SHA soup by a vast margin. In other words, they attempt to roll their own crypto without knowing a fuck about it–the worst antipattern in crypto ever, it's like a monkey playing with a hand grenade. But the biggest thing they don't realize is that crypto doesn't belong in PHP code at all by definition and design. CGI scripts are nothing but a thin glue layer between the backend (database) and the frontend (HTTP server), their only tasks are relaying data between the two and rendering HTML, they're just not supposed to encrypt or hash anything as per proper WWW site engineering: (a) authentication crypto for moderator sessions (SSL/TLS client certificates and/or HTTP authentication) entirely belongs to the web server because it is the web server that actually manages those sessions, no reason to offload their handling to PHP, and (b) handling of user-supplied secrets like passwords is entirely the business of the RDBMS backend, those secrets must never be communicated across the database session. So, PHP's natural role in the website framework is inherently crypto- and security-agnostic; if it involves itself in crypto, then it is doing the wrong job, thereby the very design of the site is defective and flawed from birth.

– Moderator login sessions, another large fuck-up of the vichan team. Instead of using PHP's start_session()–the one tool, tweakable and proven, specifically designed to provide cross-request session support–they do it manually with setcookie() in their trademark sloppy™ way... Why? Apparently because they never cared to study the subject before implementing it, it seems to be their credo of sorts, they're like Chip'n'Dale: "We don't have a plan, but we're doing it!" Very brave, if a bit retarded. OK, but there's more to it: their CSRF protection is insecure. Read any paper on CSRF (cross-site request forgery) protection, and they will highlight it up front: never use GET as it leaks the security token in a web browser's address bar, history, bookmarks, and God knows where else; always use POST to submit CSRF-protected requests. But what do they know, right? vichan knows better and does exactly the opposite: never POST, always GET. To add insult to injury, they do not generate random CSRF tokens for each session, instead using meaningless and mindless SHA-1 hashing operation on a single pre-generated server salt stored in $config plus request URI and moderator ID... It all means that a single hijacked session can compromise all future sessions, since the attacker obtains the salt, and URIs and moderator IDs are easily guessable. And this is all happening in a GET request with tokens being only 8 characters long. So, anyone can just overlook the URL in your browser over your shoulder, memorize it and the token in it, spend a few weeks bruteforcing SHA-1 to get a hash collision, and that's it, you're fucked. God, let the bastards who wrote it die a horrible death and burn in hell forever for even attempting to do security and crypto without having the tiniest fucking clue, please! (For the curious: the right way is to generate a long enough random session token for each request with random_bytes(), store it in $_SESSION, and use hash_equals() for validation.)

– Here's one bug I reported to vichan-devel and never received response on: when you delete posts by password, vichan compares passwords (a) in PHP instead of MySQL using data from a completely redundant SELECT when all it takes is a single DELETE, and (b) using a type-coercing == operator, which means that if you post with password " foo", then you can delete it with "foo", i.e. the comparison of password strings is broken and follows the defective by design rules of loose PHP comparison. If curious how to do it right: hash_equals(). But in that particular case password comparison must happen strictly inside MySQL (i.e. in a WHERE clause to DELETE) for security reasons lest the database leaks secret data over possibly unencrypted and untrusted communications channel between the MySQL server backend and the PHP client frontend. Mind you, this is common and trivial security knowledge... or at least supposed to be so.

– Algorithmic complexity (certain SQL plans yield linear tablescans on unkeyed columns whereas a properly constituted key could shrink it down on logarithmic scale.)

– HTML templating: the sloppy™ way. For such a small and primitive thing as an imageboard, using Twig (coincidentally the most bloated templater for PHP out there) is imbecilic. PHP as a template language itself suits much better in this particular niche, rendering HTML orders of magnitude faster (up to 500-600 times on PHP 7, real figures) than Twig, which is essentially "a template language written in a template language." Using Twig for an IB is like shooting down sparrows with a flak cannon when you can do the same with plain PHP in dedicated .phtml files.

– Twig is abused for preprocessing everything imaginable, from JavaScript to SQL. Hey, fuckers, ever heard of m4? Take a look at templates/posts.sql, why the fuck do you have to fucking render it with fucking Twig, a terribly heavyweight and slow templater written in PHP (not in C or C++ as a PECL extension as it should be for such a data-intensive module with a full-blown regular language parser), just to put the damn board name into the first line!? Oh God, I want to kill the miserable dumbfucks who wrote the code, because the same effect can be achieved in PHP with a simple SQL heredoc and variable interpolation inside it, the cleanest and most elegant solution possible and a textbook example for heredoc usage, all while making it much more readable (both logical parts in one place before your eyes instead of two separate files) and with proper syntax highlighting for each language (well, at least in Vim.) Heredoc + interpolation is just what it takes to do the job in many more parts of vichan, but these kids have never heard the word "heredoc", let alone "interpolation"–they almost never use it, writing incredibly ugly long strings with countless concatenation operators inside and having no idea that variable interpolation for strings is optimized much better by the Zend engine because it gets the whole string at once in a single token and only has to fill in (interpolate) variables, whereas concatenation is a binary operator that results in an excessive and wasteful abstract syntax tree many levels deep + zval allocation/deallocation. Knowing Zend internals helps a lot, you know.

– Common sense. Need to check if a file is readable? fopen() and fclose()? Unheard of. Here in Tinyboard Development Group (the shitcode factory behind it all) and vichan-devel (their accomplices in sin) we do it our way: read it all into memory with file_get_contents() and use an implicit boolean cast in an "if" statement... If people doing that sort of things don't deserve capital punishment, then who does? Another gag is right in their pretentious title of the vichan trunk on GitHub: "A lightweight and full featured PHP imageboard." Hahaha, lightweight my ass, you braindead apes. Wishful thinking all over the place. Just who the fuck do they think they are, bullshitting everyone so openly and blatantly!?

And many, many more... You might as well just roll your own IB from scratch instead of trying to fix these countless shitlines of shitcode, which is exactly the motivation behind my primary project. Tinyboard code, and code of its derivatives such as vichan or infinity, is literally a nightmare for any skilled and educated programmer, and an insult for any computer science-literate person. It is a wretched and insecure pile of outright junk code written by uneducated script kiddies who dared to think of themselves as programmers. It rots and reeks as I'm writing this, I can smell it across the HTTP session. It is virtually unmanageable and unmaintainable, it is extraordinarily slow, bloated, and of course sloppy™. It boasts many features, and every single one of those features is done sloppily and wrong. Tinyboard/vichan is a vile and grotesque collection of various programming and design antipatterns, and I have enough knowledge and experience in all of the aforementioned topics to declare it out loud as undebatable truth. Its authors are shameless and clueless programmer wannabe fuckers, because publishing such shit of a software is no less shameful than displaying dirty underwear. Avoid it at all costs, or face the unsightly consequences I am facing right now with it.

I am sorry to run vichan on GUROchan. Using vichan for GUROchan was a terrible mistake on our part due to lack of experience with other IB software packages when we first started our project, and it keeps backfiring, again and again. I apologize, guys, we fucked up big time with our software choice, and what I'm doing now is sorting out the resulting mess. So, the least I can do right now is send a word of warning to everyone who wants to run an imageboard: don't even think of using vichan, infinity, or any other disgusting Tinyboard derivative, all of them are shitty beyond any description or belief. I repeat, never touch those stillborn abominations, have some dignity. And remember that "Tinyboard", God forgive, is an utterly misleading and awkward oxymoron of a name–in reality it is one of the fattest, bulkiest, most fucking bloated IBs in existence; it has every feature that you don't and won't ever need. I mean it, every single word, beware of it, spread the word of warning if you care at all. Tinyboard/vichan must die a dishonorable death as the bastard brainchild deserves.



Had to take this shit out of my head, it's been corroding my mental wellness for a while now. It turned into a marvellous rant, even if I'm the only one enjoying it. I just hope that someone finds these topics interesting and fair. So, to conclude the soulcry: my replacement code may experience minor bugs and glitches–I was hasteful about it, wanting to do away with the rotten vichan code ASAP. Please take some time to report bugs whenever you spot them, your feedback will be much appreciated. Peace.
>>5568
Damn man, it kinda makes me sad that my programming knowledge isn't huge enough to help. Still, It's really great about all the work that you do - the recent changes are both interesting and helpful, so don't get disheartened. There are people out there that are appreciating your hard work <3
>>5568
>>5569
Agreed, your work in keeping this site up is hugely appreciated.
>>5568
Great work so far. Thank you for maintaining our beloved slice of depravity.
I'm already seen major improvements in the snappiness of the site.
Can we get the date back in DD-MM-YYYY format ?
>>5629
No. The current format is dictated by database, and I'm not up to transforming it artificially.
>>5630
You mean the database, or the code that connects to it, handles the date in text form? Not surprising in light of earlier post.

YYYY-MM-DD is best format anyway.

Thanks for the time and energy you put into maintaining this site.
>>5631
The database. Currently, GUROchan is backed up by MariaDB. All dates used to be stored as plain Unix Epoch integers and formatted by PHP code. Now they are stored in TIMESTAMP-typed columns which have the output format as you currently see on the site; it rids me of the effort of manual formatting as I receive dates already formatted from the database.

Also, a reminder: stylesheets and layout change often during this reconstruction, so if something looks wrong, first of all flush your browser's cache.
One thing I noticed... Infinity (also based on TinyBoard as you mentioned) seems to be unable to delete boards correctly. 8chan's attempt to delete the /phile/ board apparently left over some pages, like page 2, 4, 5, 6, and more, with some images still present and others 404ed, yet the main index.html says no such board exists. This is just sad.
>>5637
Perhaps they should learn to use memcached instead of generating actual HTML files. Board deletion is backed up by Tinyboard's rrmdir() function, which is essentially rm -R, so it could fail due to file ownership or access rights.
>>5629
Agreed. And this is coming from a European.
did the catalog disappear or it's just me?
Is there a way to have it back?
>>5649
Yes, the old catalog disappeared and isn't coming back, at least not these days while I'm busy refactoring the core code. Unless there's a very compelling reason to roll it out back, I'll just direct you to use board Table of Contents instead and wait for the search function (which, among other things, is expected to easily fill the catalog niche.)

And yeah, remember to flush your cache whenever something appears outright wrong for you. Please excuse the inconvenience, things have to be done.
I backported the UI and other code parts from my primary imageboard project into the current codebase. Get used to it. Feedback and constructive criticism is welcome, especially bug reports.

Please note that old thread-hiding settings are no longer actual, so I recommend you first clean up the localStorage (area where your browser stores per-site settings) using the "R" button in the bottom right corner.

After polishing this update, the roadmap goes toward a mobile-friendly theme... That is, if apathy doesn't devour me for next several months as it often happens.
The "open post forum" thing is kind of weird, but i'll get used to it. New UI is rather nice, really modern and sleek looking, hope it doesn't confuse anyone. Glad to be a mod for this site.
where did the "expand images" button go? I really don't want to click each image in a long ass thread.
>>5659
The poster-to-viewer ratio of GUROchan is well beyond 1:1000, so it makes sense to hide the post form for casual surfing.

>>5661
It is now fixed in the bottom right corner so that you don't have to scroll all the way up to find it.
Site looks awesome now, and it's always been pretty mobile friendly imo - I almost always browse it from a phone. With the new look, however, the top panel is cutoff on the side - I can only see it up to /lit/, and the other options after that are not visible nor can I select them
I made a post on /rp/ and it had no image, so after I clicked post I got ported to an empty page. I thought it didn't work so I did that like 3 more times like a moron, and then also attached a picture and then when I reloaded the frame I saw that I posted 5 times.

Therefore, here's a possible idea: can a script be run to detect multiple posts in the same thread and automatically only keep the latest one?
New design looks excellent. Also very nice, finally, to have a thread's all-page access at bottom as well as top. Thank you for your hard work! ^v^
I concur, wonderful layout. On mobile it was bad earlier but it was fixed shortly, I love seeing it all smoothed out.

I feel like I walked in on a construction site and now revisiting, it's so luxurious.
Thanks everyone, we will keep doing our best.

>I feel like I walked in on a construction site and now revisiting, it's so luxurious.

The sad part is that this UI layout has been around for more than two years in my imageboard project, but I never cared enough to backport it.

I don't browse GUROchan from mobile devices and cannot easily debug it on real hardware because GUROchan is blocked in Russia, so I welcome any feedback regarding mobile browsing experience. Please report any glitches, distortions, skews, whatever.

One matter that bothers me is that the board table of contents may be too large and overall useless in mobile view. Therefore for now I updated the stylesheet to hide it when the viewport is narrow. Perhaps I could do better: leave it in place, but hide certain columns like ID, Author, Posts, and Images. Tell me what you think.

Another point of concern is the buttons in the bottom right corner (up, down, etc.): as it currently is, it is but a quick hack. I am very tempted to stuff them all into a context menu that would be displayed upon clicking the topbar GUROchan logo in the top left corner, but since it implies JavaScript, it will leave users with disabled JavaScript (or enabled NoScript) without jump to top/bottom links.
I honestly don't like this new look. Hard to tell at a quick glance when scrolling into a new thread because of the lack of a distinguishable line between threads, and having the titles the same color as all the other text doesn't help either. I'm part of the PC master race, so I don't know about the difference on mobile devices.
>>5672
I just cannot figure out a way to render thread titles both clean and distinguishable without using ugly boxes as it was before. If you have ideas, I'm all ears.

A little update for today: keyboard shortcuts:

w – jump to top
s – jump to bottom
a – shrink all images
d – expand all images

It may require reloading of https://www.gurochan.ch/js/fluff.js or cache flush.
>>5670
The table of contents is essential, as without it it's impossible to tell what threads were updated recently without scrolling through all of them. I'd say ID, Author and Images are not necessary but the number of posts is.

Oh and the logo doesn't load on mobile for some reason.
>>5670
As a mobile user, I agree with >>5675, table of content is essential on mobile. Not having it means I must scroll all the page to see what's new, instead of just looking at number of answers and eventually opening the topic in another tab.
ID can be removed, useless as fuck on mobile. Author can at least be moved, topic and number of posts(or last post date) should be the first columns.

Also, logo is indeed broken, but not only on mobile.

Otherwise, the new design is very nice. :)
WHOA!! Digging this new look! I love the visual distinction between anon thread owners and not, plus the posts/images counts. This is awesome! Very clean and modern. Keep up the great work.
Lots of wasted space. Almost half my screen is empty of content.
>>5679
Annie, what's that you say? Attaching a cap just now from Firefox 55.02 (32-bit). Oh. No attachments. Well, it's totally clean visually for me. Are you still seeing what you described?

Yes, the top left Home button needs an icon.
Just logged in for the first time in a few days.

Holy fuck, I like it! I like it a lot!

(I'm just curious where the news went)
>>5673
You could try making the line that separates the threads the same red as the names of posters, or make it thicker.

Also, making the names of the threads bolded .
I think that would separate things nicely.
What's going on?! I'm scared. Is it not 1998 any more?!
...ah, dammit, what happened to the "down to bottom/up to top" and "expand all" buttons? They were extremely useful, especially on mobile (without them, scrolling to the latest posts in a long thread is very, very tedious), or for quickly archiving at-risk threads...
>>5708
Should be on the bottom right of your screen.
>>5707 This! I leave GuroChan unattended for a week and I come back to find it overhauled! ._.
I'm largely indifferent regarding the new board software (though I do like the YYYY-MM-DD), and while I never really used the functionality, I can't help but notice that there's no permalink for each reply anymore. Previously, the "No" located before the reply number would be the permalink for that reply, but now it's just part of the "add link to my reply" function that you'd get when clicking the reply number itself.

If you don't already know what the formatting is for permalinks, then the only way to get a permalink for a pre-existing reply is to make a new reply that links to the aforementioned pre-existing reply.
I don't know if the old board software did this, but it seems that the new software will re-save an uploaded image for the thumbnail even if the uploaded image is already small enough to fit the thumbnail.

This is most obvious with a small resolution animated PNG, such as the bouncing ball example on Wikipedia's APNG article (the image is only 100x100 pixels). If one uploads said bouncing ball to GUROchan, the thumbnail will not be animated yet clicking the image and viewing the actual uploaded file will result in it animating. This can only happen if the board software is actually creating a new image specifically for the thumbnail regardless of the uploaded image's pixel resolution.
Oh and one last thing, it seems that passwords are no longer capped at 16 characters! Yay for that.

However, the new board software still seems to cap password length to "only" 21 characters - inputting a password of 22 characters will seem to work fine (it'll post your reply and everything), but as soon as you try to delete your reply, the board software will complain that you've entered the wrong password no matter what.

It would probably be wise to make sure the password limit for when you create a reply is the same for when you delete a reply.
>You could try making the line that separates the threads the same red as the names of posters, or make it thicker.

Let's try the first suggestion.

>I can't help but notice that there's no permalink for each reply anymore.

OK, I'll bring it back for now. The idea is to simplify things and keep a single link: when clicked, it cites the reply, and if you right-click on it and select "Copy link address" from the popup menu, you get the post's perma-link. I still plan to make it so on one of the subsequent updates when I finish and fully debug a quick reply feature.

>I don't know if the old board software did this, but it seems that the new software will re-save an uploaded image for the thumbnail even if the uploaded image is already small enough to fit the thumbnail.

It thumbnailed unconditionally before, since I haven't made any major changes to the thumbnailing code. However, expect new restrictions on images to come: images smaller than thumbnail size (which will be fixed at 200×200 pixels) or with aspect ratio beyond 1:10 / 10:1 will be rejected. So, re-saving thumbnails is fine. All images will be re-thumbnailed eventually anyway.

>It would probably be wise to make sure the password limit for when you create a reply is the same for when you delete a reply.

This discrepancy stemmed from the fact that I basically ported the UI from my new IB software first, overlooking a few things in the process. I rewrote the password handling code and fixed the issue: now passwords are stored as cryptographically strong digests (using Blowfish-based bcrypt) and can be at most 72 bytes long. However, as outlined in the updated FAQ, passwords now expire: you have just 3 days to change your mind and delete a post before it becomes public domain.

E-mails are no longer restricted to 30 characters as was idiotically enforced by vichan. The new limit is 255 bytes as dictated by applicable RFCs. Post message length limit is henceforth 65,535 bytes on all boards. Note that I mean bytes, not characters: due to technical shortcomings (namely, the use of MariaDB for storage), text field length limits are imposed in bytes, not actual characters; our site uses the UTF-8 encoding, meaning that a single character can occupy from 1 to 4 bytes (e.g. Russian characters take up two bytes, Chinese/Japanese/Korean even more.)

Thanks for feedback. As a footnote, a few more sleepless nights on coffee and Adrenaline Rush, and the site's operation should stabilize by the end of August.
Looks pretty sweet so far.

The only criticism I can think of right now is the disappearance of the news feed from the homepage. I thought that was handy (although I concede that there weren't actually that many news posts on it).

Is that coming back eventually, or is that gone for good?
>>5729
Gone for good in its old form. News, if any, will be added to the home page, but removed as soon as they become old. Don't judge the home page just now, it is but a quick placeholder, it still needs redesign.

Update: OP image in /p2p/, /req/, and /rp/ is no longer required.
>>5731
I actually like the current home page. The minimalist yet everything-you'll-need-to-navigate-the-site is there. Makes me think of a wrapper around a magazine, hinting that for most folks, the content within comes with a caution: in this case, Gore & Death; Scat.

Ineluctable modality of the visible...
Um, I seem to keep losing what I've typed in the name, email, and password boxes. Does the new GC not save these any more, or is this a bug, and if so is it just me or are other people having to re-type their stuff for every post?
Looking good, but theres a problem on mobile, the thread name is getting cut off. Also, could you please make it easier to see when a thread was last updated?

Honestly, that's why I prefer DDMMYYYY, I don' have to read to the end of a string of numbers to find the day the last post was made on. Boom, it's right there near the title of the thread.

Also, I'm slightly sad the old look is gone. It had a nice, simple asthetic, and this look is a LOT more cluttered in comparason.

Good riddance to bad rubbish for the code, but I prefer the older look.

Perhaps in the future you could add skins?

(And please, don't insist on css for the skins if you do, it's more than a bit too complicated for those of us who don't code on a regular basis)
>I seem to keep losing what I've typed in the name, email, and password boxes.

Yeah, there were autocomplete="off" vichan leftovers in HTML. I removed them. Also, vichan used to manually remember stuff with JavaScript for some reason; that is no more. If you want fields remembered, use your browser's form autocompletion/autofill feature.

>Looking good, but theres a problem on mobile, the thread name is getting cut off.

I'll look into it.

>Also, could you please make it easier to see when a thread was last updated?

I might try to convert dates to local time format and timezone with JavaScript. I'm pondering on how to implement JavaScript-based thread watch cheaply and without Ajax; it might also help solve the issue. The working idea is to highlight updated watched threads in the table of contents until visited.

>Also, I'm slightly sad the old look is gone. It had a nice, simple asthetic, and this look is a LOT more cluttered in comparason.

As >>5707 pointed out, it is no longer 1998. The old look was outright garbage, poorly designed and awkward. So now we have this as a starting point. What clutter are you speaking of specifically? I honestly fail to see any beside the bottom-right corner block. The entire point of early redesign was to get rid of old visual junk, unnecessary elements, and whatnot.

>Perhaps in the future you could add skins?

There's a dark theme draft in the works. Potentially a light white-ish theme may be added to make it three, but I'm not porting any of those other imageboards' eyesore skins (4chan, 8chan, etc.)
Can confirm, passwords that are 26 characters work perfectly - I'm happy now. (no idea about longer as the password I normally use is 26 characters).

Question though - am I crazy or is it impossible to link to a post from a different board using the typical shortened image board link? For example, if I want to link to the story "car fight", I seem to have to use the full URL of https://www.gurochan.ch/lit/res/1903.html rather than the shortened >>1903


>>5742
But the same can be said for the opposite - with DD-MM-YYYY, I had to look at the end of the date whenever trying to find posts that were made in the last several months rather than the last several years - this is especially true for stories and such that don't update very frequently at all, like "Car Fight".

It's going to be impossible to please everybody, so it seems best to just use the date format that has the best chance of not being misunderstood regardless of what part of the world they are from...which ends up being YYYY-MM-DD.

<asshole-mode>
Besides, I can't help but notice that is seems to always be people from countries that primarily use day-month-year that seem to be the most critical of any date format that is anything other than day-month-year, while even supposedly notoriously stubborn-to-change Americans (see: metric) seem more forgiving towards both day-month-year and year-month-day date formats.
</asshole-mode>
I believe I've found a bug regarding the new keyboard shortcuts:

On Chrome, Ctrl+W is the shortcut for closing a tab. But if you close a tab that way and the tab next to it (that the view switches to) is a thread, it thinks you pressed W and jumps to the top of the thread.

Similarly, pressing Ctrl+S (to save the page) jumps to the bottom of the thread.
>>5749
I, personally, am fine with either day-month-year or year-month-day, as both of them are properly consistent. Month-day-year on the other hand is just ridiculous, it's like if you wrote time like "minutes:hours:seconds" or a number like 125 as "twenty and one hundred five". But the existence of it makes the year-month-day format preferable just so that seeing something like 02-08-2077 you don't have to wonder if it's the second of August or the eighth of February. On the other hand this can be solved by writing it as 02-Aug-2077.
About dates: the easiest solution is to let users select the desired format. I'll roll it out in the next major update, so sit tight for a few more days.

>Question though - am I crazy or is it impossible to link to a post from a different board

The cross-board citing syntax is >>>/board/123.

>I believe I've found a bug regarding the new keyboard shortcuts

Fixed.

By the way, when threads are hidden, I think they should either be removed from the table of contents, or marked visually somehow.
I guess it's the way everything is laid out in blocks, I guess?

It all just seems to take up more room than it actually needs. Like up at the top, the g, f, and s boards have a huge amount of room compared to fur, art, and the others. And on my screen, it looks like rp is just squeezed in there.

On the main directory for each section, there's a huge amount of information packed into a tiny area- things like thread titles are getting cut off.

The older version had a bit more room to work with, most sections had two lines to work with, not just one, if it was needed. One was bugged to not work right, but that was a fairly recent occurance.

All in all, the layout of the older version was simpler. A mite bit easier to work with on mobile devices, once you got away from that damned framework or whatever it was that was the main page insisting on being the only damned page. And that was easy enought to manage.
now when ever i press down arrow it now snaps to the bottom on the page. makes it very hard to scroll though a page now.
>>5751
Wouldn't the actual equivalent of month-day-year be minutes:seconds:hours? It's basically just a corruption of your typical big endian format where the largest value (year / hours) is stuck on the end rather than the beginning.

This is most obvious in that when you drop the last value (year / hours), it the result is month-day or minutes:seconds which is just a a shorter version of the typical big endian format.
Apparently I'm a bot. Any idea what triggers that? I'll try breaking my original longer post up into multiples, see what upsets it.
Oho. Right. I think it's because I put some html in. Even though there were no links, it's still link-like code, which must have upset it.
Next changereq then - add html filtering in that does more than simply prohibiting posts that include it or similar looking strings?
*edits post* ok that should fix it.
> spoiler: it didn't

*edits again* ... ok, how about now?

>>5709
Ah! Thanks. Actually quite slick. Thing is, using a widescreen machine, and a screen that couldn't really be described as the world's highest contrast, plus rarely if ever using the regular scrollbar now we're in an age where cursor keys, pgup/pgdn, home/end, and of course the mousewheel (& its emulated touchpad flavour), and with most posts being left-aligned to such a degree that they rarely extend much beyond halfway across (even with a lowly 1280 pixel resolution!)... I never ever looked over there, and it didn't stand out enough for me to notice it.

I know it's there *now* of course, but still, any way to have an option to move it to top-left or something like that? Maybe detect screen width and automatically put it halfway up the left hand edge with an extra couple dozen pixels of left border before the images and text posts are drawn on any screen where text doesn't normally extend all the way to the right-hand scrollbar? It'd take up the same amount of screen space overall, after all.

Also, that's fine on a desktop display like the one I'm currently using, but I'll have to reserve full judgement until I can test on mobile again. Fancy floaty features like that have a nasty habit of either not working properly after taking the leap to handheld, or simply don't work at all. The old links as described were plain HTML anchor bookmarks, ie [[data expunged]]. Absolute HTML universal-compatibility 101 grade, any device that can't parse them needs to be thrown in the sea ;)
[original angle brackets replaced with square brackets to try and evade the overzealous bot-hunting code]
[[and now redacted entirely... you can just look up what i mean if you don't know the form already, after all]]

And then there's the matter of how big the shortcut buttons will be on a dinky touchscreen and if they're oversensitive so get triggered by normal scrolling etc...

Anyway, without having tested it yet, that's just conjecture, it may work absolutely 100% fine, so don't take it as a criticism... (yet!)



>>5711
Totally unacceptable, isn't it. Some people have no respect for the classics, or how us weirdos still can't deal with moving into the 21st century. There oughta be a law.

It is pretty cool, though.

Also...
> Is trying to learn n00b-level PHP/MySQL right now

> Reads >>5568

> Fuck.

> That sounds really complicated, have I got the time and mental capacity to deal with all that stuff? I'm not exactly a tech novice but I've not heard of more than 50% of that, and probably 40% of the rest I've heard of but haven't had any direct contact with, or even actually know *what* it is. Presumably the insight would gradually accumulate over time, but if that's the kind of guru level knowledge and analysis exercised just for a niche back-of-the-woods imageboard, what kind of insane wizardry is expected for professional use?

> ... heck of an insight and a resource though

> *select* *copy* *start>notepad* *paste* *find-replace to edit out the bits that point directly to here*

> *fukken saved*


Damn, Enclaved. That sounds like a fuckload of work. I feel like a bit of a dick going "wah, where's the top/bottom links?" now. (The "wtf happened?!" bit was supposed to be a comedic expression of it actually being new and swish, however) ... Thanks for being motivated enough to put in the effort to fix/rewrite it. It looked like just some kind of CSS theme pack initially but I have to say the site seems to be running somewhat quicker and smoother than its previous somewhat clunky self, that sometimes gave the impression that it was running on a C64, on the moon. Probably the strain of trying to serve 10 different people browsing at once, through the fug of the original spaghetti code.

*double thumbs up*
Further FB on that little top/bottom feature ... I don't know if this is a client side (ie browser) or server issue, but is there any way to prioritise loading the entire html for a page before the images, or at least high enough that it can keep a good way ahead of the image stream?

It might even have been down to the janky programming (and the "inherent rate limiting"?) of the old version, but the old behaviour was that it could be made to jump to the bottom pretty soon after loading a thread / whilst the browser was still showing the first screenful in progressive-loading cases. If it hadn't yet loaded in the entire html of a longer page, it would at least jump to the end of what had already loaded (IDK if there's a particular anchor code for that?) and you could click the link on one of the visible posts there, or just manually scroll the then much shorter distance to the bottom... skipping the loading of all the pictures / thumbnails in-between.

Now it seems like, although it doesn't really start loading until you start scrolling a tab (especially if you had many opened in the background), it does so in a very progressive manner, ie as soon as an image tag is encountered in the code it will load in the image as a priority, progressing only a little bit further through the html, or maybe none at all. Hitting the "down" button whilst it's doing this full page load just has it flicker (1/10th sec if not a whole lot less) to where it's reached so far then right back to the top, very very rarely sticking there for maybe a half second when caught in between two loads but still returning to the top. Only once the entire page - seemingly with all the pictures - has loaded can you do skip-to-bottom.

And, well, that's where all the new shit is... you don't really want everything else you've already seen to have to load in first, even if it's only thumbnails, especially on a page with 100+ images... double especially if you're on a slow link, or a metered one (two things that often go hand in hand). Particularly this could be murderous for capped mobile data access; my wallet has probably a lot to be thankful for in terms of being able to skip right to the bottom of more frequently visited threads when phone-browsing, seeing if there's anything new or not, and either closing that tab even before any of the immediately visible images started to load into their placeholders, or sticking around to let those 2 or 3 of the newer pics actually download, then scrolling up slowly, loading as you go, to see if there's more than just those.

It's ok on desktop with a fast, unlimited link, but that's not the case for everyone or every access situation.

(in fact, this isn't even so much about the operation of that particular button, but how things load up in the browser, if you have any influence over that at all and it's not just Chrome / Chromium / Webkit weirdness; its effect on the button is just what led me to discover the change. Besides the significance for mobile / slow connection users, it has implications for server load and total bandwidth consumption also. A channer browsing a thread with their browser pulling down 100 images when they're only really interested in the newest two or three is placing a lot more load on the server in terms of file requests, and using up a lot more of your monthly bandwidth with entirely needless data transfer)
>Apparently I'm a bot. Any idea what triggers that?

HTML links, namely href attributes. That's what most bots try to post.

>Fancy floaty features like that have a nasty habit of either not working properly after taking the leap to handheld, or simply don't work at all. The old links as described were plain HTML anchor bookmarks (...)

If you mean the bottom right block of links, there's nothing fancy, it just has fixed CSS3 positioning and should display correctly on any modern mobile browser. The links still point to the same old HTML anchors, well, one anchor (#bottom.)

>Presumably the insight would gradually accumulate over time, but if that's the kind of guru level knowledge and analysis exercised just for a niche back-of-the-woods imageboard, what kind of insane wizardry is expected for professional use?

For professional use, the task is usually divided between several specialists: backend, frontend, UI designer, etc. Whereas here I have to fit into all of these roles, and I am no professional in any except general programming (I'm a C programmer) and databases (I'm a professional DBA.) Plus remember that I'm not the only one here: since 2014 GUROchan has been a brainchild of two, ryonaloli and mine. I'm the programmer, but a lot of security concepts employed are the wisdom of ryonaloli, who is an information security professional and consults me on these topics.

>I don't know if this is a client side (ie browser) or server issue, but is there any way to prioritise loading the entire html for a page before the images, or at least high enough that it can keep a good way ahead of the image stream?

That cannot be truly controlled, the loading-rendering sequence is fully governed by the browser as it sees appropriate. The issue is well-known, and I plan to address it by introducing paged threads view.

>the old behaviour was that it could be made to jump to the bottom pretty soon after loading a thread

That cannot be true: the #bottom anchor is at the tail of the page; you cannot navigate to it if it hasn't been loaded. I added a simple JavaScript workaround. Also, there's the "s" hotkey.
The top and bottom buttons doesn't work anymore on mobile, at least on Chrome for iOS and Safari.
>>5778
Fixed?

Update: If you have JavaScript enabled, check out the dark theme draft via the red button.
The dark theme is a welcomed addition, good job!
The new interface is cool - thanks! But pls. bring back thumbnail "catalog" view in top section. I liked that!
Please, man, bring back the option to have something like the old interface. I loved it. I like janky nipland web 1.0 no-gradient no-font-fuckery shit. It makes me think of happier times. I wanna see Times New Roman, a framed sidebar, no shading on post boxes, 2005-era visual design that was left that way because it works. I want to see Futaba. I see that, and I think to myself, "things may be shit now, but at least good ol' Gurochan is the same as always".

I'm a fucking idiot, man. I don't know from PHP, I can hardly write a line of C++, and I don't know if what I'm begging for is even possible. But if you have the time, and you can bring yourself to waste it doing such a thing for me and the other silent people who might feel this way, I would really appreciate it.
>>5795
We do indulge one's sick perversions, but what you are asking for transcends all planes of reality. No. Craft yourself a custom stylesheet and live happily ever after.
Some /lit/ threads extend beyond the horizontal border. Example would be the story chapters of Pogue's Stretch Goals. My suspicion lies in the equals signs.
Hiya. I was wondering if I could suggest maybe a dark red color for links in dark theme instead of the light blue? The light blue is nice but I think red suits GUROchan better and I personally prefer red over blue myself. But it's just a suggestion. c:

Also, this might be a silly question but is there any way for the OP of a thread to change the title of said thread and edit the text of the first post? I'm the OP of the loli scat thread in /s/ but I titled it and created the first post when I was 18 and I find it cringy and would like to change it if possible. Thank you in advance for any response you can provide.
>>5797
Disregard that. We will switch to a new markup processor soon, which will gracefully handle all possible kinds of valid and invalid markup syntax.

>>5798
Red colors: the initial draft had it red, doesn't really work, it comes much harder on eyes, whereas the entire point of dark theme is to be easy on eyes, especially in unlit environment.

Editing: there's no stock feature. I remember discussing it with ryonaloli a couple of years ago, and at that point we decided it would be wise not to allow editing lest confusion ensues. This is up for another discussion. Meanwhile, you can message me on IRC if you really want something edited.
>>5799

Oh, I see. I appreciate that red was at least considered and I can see how it might be a bit hard on the eyes. By the way, I think the dark theme looks very nice.

That makes sense but seeing how a thread title is not exactly urgent I wouldn't want to bother either of you on IRC about it. I may simply create a new thread with the same subject matter (with my newly preferred titling and such) since the old one may hit its post limit soon.

Thank you very much for your quick and concise response!
A little update: the capacity of all boards has been extended to 300 threads (20 pages with 15 threads on each.)
I liked the old layout, but i like the new one also.The important thing is that this places lives.As long as gurochan exists the internet will be internet.
>>5806
That sounds nice. Teh New feels comfortable.

In Firefox 55.03, everything looks good and works.

So enclaved, after your >>5568 tirade, how are you feeling/doing now?
>>5813
A lot better, thank you. There will be a major internal update (not many visible changes besides yet faster site operation) within a week that will rid us of old code entirely; then I will be truly at peace.
The top button's icon looks broken on mobile
>>5794

You're asking why would thumbnails of art be preferable to a text description? IDK if I'm misunderstanding your question, or maybe just not using the right terminology for the thumbnail gallery option that I used to quickly peruse my interests...
>>5827
I've never really understood how catalog worked. It simply displayed last images per thread, which I rarely found any useful. But if you guys really liked it, I can make it again, with any changes that you may want and request.
>>5828

Well I'm just one voice but thankful if you'd considerate restoring it. I think others would find it useful too...
Can you please put the site name back into the page title?
It helps with downloads.
I'd like to also give feedback on the way the thumbnails load.


For large threads that aren't updated all that frequently, I pretty much always press the "End" key on my keyboard to just go to the end of the thread to read the new posts (usually only a couple) and/or open any new images in new tabs for enlarged viewing.

However, my internet connection is only ~372KB/s down (aka 3mbps).

As I just found out a couple minutes ago, if I go to the bottom of the page via the "end" keyboard key before all of the images are loaded, it'll be pretty much impossible for me to read any new posts or click any of the new images because, as soon as an image loads, the page shifts downwards which manifests itself as scrolling the entire page up.

The thing is, my internet isn't slow enough that there's a long enough gap to actually click an image let alone read a post before the page "automatically scrolls" on me; this becomes extremely apparent if I simply hold down the "end" key - it results in the page shifting up and down at a rate of about 5-10fps (therefore it's loading 5-10 thumbnails a second?), which means that for a thread with 200 images, I have to sit there and wait for at least 20 seconds before being able to click or read anything located near the bottom of a thread.


Now normally I despise it when any sort of discussion thread on any sort of website is sorted by having the newest posts first, yet such a thing would actually solve this issue.
>>5844
The upcoming site update will split threads in pages (75 posts per page), provide the default view of last 50 posts (the so-called "noko50") and retain an option to view the entire thread at once. Just hang in there, I should be finishing it soon.
>>5538
I just wanted to say thank you for your hard work.
>>5777

> HTML links, namely href attributes make it think you're a bot

Weird... I think I *might* have tried to insert a weblink, or at least type something that might have looked like one, but I certainly wasn't dumb enough to format it like a full HTML anchor, seeing as markup doesn't work on most imageboards. Not even sure if I put aitch-tee-tee-pee on it, because I know *chans tend to choke unless you use "hxxp" or whatever. Bit of a pain if you just want to type in an "innocent" (ahem) link to something useful and relevant.

> nothing fancy, it just has fixed CSS3 positioning

thinks: "wat" :)

> and should display correctly on any modern mobile browser.

"Should" is a dangerous word... but, weirdly, I still haven't had oppo to pull GC up on my phone since last checkin, so still can't confirm. All I can say is that even in the last week I've had to deal with websites that try to do special effects and my 'droid 5-point-something (6.sth?) 3-ish year old midmarket phone has suffered a bit of a headache as a result. Not displaying properly, dragging when trying to type into textboxes etc, when other sites are much smoother and better behaved. Might not be anything of the sort you use, it just makes one a bit wary.

> For professional use, the task is usually divided between several specialists: backend, frontend, UI designer, etc.

*phew*

> Whereas here I have to fit into all of these roles, and I am no professional in any except general programming (I'm a C programmer) and databases (I'm a professional DBA.)

That sounds advanced enough to me...! At least, it's probably a good combination for this kind of work, and enough to make my head spin when looking at it.

> a lot of security concepts employed are the wisdom of ryonaloli, who is an information security professional

Well, likewise. Maybe it's just that my mind is permanently anchored in about 2001 :D

And if it hadn't been reiterated enough by myself and others - the effort is much appreciated, and it definitely seems to have paid off.

>> is there any way to prioritise loading the entire html for a page before the images?
> That cannot be truly controlled, the loading-rendering sequence is fully governed by the browser as it sees appropriate. The issue is well-known, and I plan to address it by introducing paged threads view.

I guess the server can't really take the liberty of assuming that the IP requesting some HTML and also a bunch of pictures is actually doing so for the same browser thread / page, or that it's even actually the same machine instead of multiple ones behind a NAT-ing router or whatever, as it might end up breaking more things than it would fix, as well as being extra server load keeping track of things, and a pain in the ass to program to boot...

Would there be any way to address it as a QoS issue or the like, though? As in, literally prioritise the delivery of HTML files above all others, and CSS/etc at the second level if it proves necessary, with picture and video third? So a client requesting mixed content would get the core page code fastest (which in a perfect world should happen first anyway as it should be considerably smaller than everything else, on a site like this), and the style sheet/scripts/whatever if needed to successfully render it to the point where a seek-to-bottom would succeed (or, of course, for the buttons to even appear), so it can start building the framework whilst the images then load in to fill it out...? And even if it was trying to REQ a squillion images at once, it would only see HTML/style/script packets appearing until there were no more due for that IP (or at all...) and just have to wait for them.

ISP level traffic management, like.

There's a chance it could cause general congestion and slowdown, but the amount of html files, and the data in them, is so small vs the images that they then cause the client to download that it doesn't seem particularly realistic, and even with a perfect storm of a 100 users all requesting new pages at the same time as there's 1 waiting for image(s) to load in the latter shouldn't see a -huge- slowdown ... at least, not until the situation switches over to 101 users waiting for images anyway :D

(example, downloaded a threatened thread earlier for archive / re-dumping purposes earlier; pretty long page, took a couple minutes to save as "web page, complete"... the HTML is a fairly meaty 258kb, the collected JS and CSS another 20kb... and the 268 images add up to 114mb, or about 420x (ayyy) larger, with 278kb being just below the median image size, i.e. there's a couple more pics larger than the page code than there are smaller, so we can simplify that as the code for a huge page being equal to a single below-average image. Can't say that's at all representative of everything on the site, particularly the smaller pages, but it's certainly true for one of the heavyweight ones I had in mind when asking the original question...)

In any case, that in itself shows that things are definitely running faster now than they used to, so it's sort of give-and-take. In fact, dumping a couple dozen images onto a similar sized but not yet autosageing thread was fairly painless even though my ISP throttles uploads pretty hard (it's a good day when it manages 1:10...), as well as at least as dynamically as the downstream bandwidth, and the server has to regenerate then send the html plus its own version of that same picture back down the pipe each time... in fact the wait for the larger ones to squeeze their way out of the router was the biggest yawn, the reload time was fairly short. Though of course that still doesn't say anything about the mobile performance where the width of the downstream pipe and system processing power is more important and could benefit from traffic shaping ;)

>> it could be made to jump to the bottom pretty soon after loading a thread
>That cannot be true: the #bottom anchor is at the tail of the page; you cannot navigate to it if it hasn't been loaded. I added a simple JavaScript workaround. Also, there's the "s" hotkey.

*shrug* IDK, maybe it was loaded but hadn't rendered or something? All I can report is what I experienced, and how things changed between one version and the other. Maybe the spaghetti code of the old site, and the lower overall bandwidth that seemed to cause (especially for images?) meant that the browser had a mare building and displaying the DOM with any speed (and in fact sometimes *still* seemed to receive and decode a lot of the images before that happened) but it was still able to set the caret position and knew that there was a #bottom anchor that could be sought to? So it would then jump down to meet it once the local document was built?

(yeah, guess who started reading the dummies guides to javascript and html5 literally yesterday :p ... somewhat underwhelmed at this point fwiw, as the largest part of it seems to be Universal Programming Fundamentals And Childishly Simplistic Webpage Construction 101, even from the perspective of someone stuck in 2001 and whose experience so far essentially amounts to BASIC, html 2.0 in notepad, and some very elementary PHP/MySQL... I at least know enough more now that I can take a guess at what you did for the workaround, though it's probably wrong...)
>>5795
muh nigga
join me in 2001...

...anyway, I'm sure there used to be a way to force the browser to ignore styles and render sites with a very basic appearance, but there doesn't seem to be that option in the menu any more. At least not in Chrome. Might have been an IE or Firefox (or Opera?) thing? Presumably there's an extension you can download for it.

(no idea of how to enforce a custom style sheet as a discrete thing, anyway)
>>5796
if there's a way to do that and apply it to Yahoo Mail and you know how to do it, I would owe you many virtual blowjobs

goddamn enforced UI upgrades that fuck with your workflow and murder the CPU...
>>5798
damn, nothing on this incarnation of the site is more than 3 years old, that's some pretty fast becoming-embarrassed-by-your-younger-self right there.

>>5799
Hopefully that's some proper kind of markup, not that "markdown" bullshit that never works right even when you try to use the actual code, and visits all kinds of generalised destruction on any copied-in text or everyday ASCII-assuming typing which may have asterisk/underscore/etc emphasis included amongst other things...

As for the links, I'd suggest a bit of lightening and desaturation (so it doesn't actually go full brightness on the red channel), so it's actually more a sort of greyish pink but still looks fairly red in comparison to everything else? I'm using the light theme right now but I assume "light blue" isn't full primary blue (itself difficult to red against a dark background) or cyan (a bit glaring) but a more pastel sky colour anyway, so its reddish counterpart might work just as well.

With the editing thing, the fairest might be something like the IP which submitted a thread can delete it afterwards (in order to repost it with corrected title/text/etc) for an unlimited time if no one else has posted (even if they have themselves submitted multiple posts and then realised the OP had a glaring mistake), and maybe for 10 minutes after the first post by another user/IP, after which it's fixed except for Mod intervention. I've never known an imageboard of this type to offer any kind of editing beyond simple post/thread deletion followed by reposting, and I'm not sure how you'd implement it without adding in whole extra modules (instead of just adjusting the permissions setup).

>>5806
Is there a way to get the aforementioned autosageing thread restored to normal life in that case, or does the post limit remain, with it simply saved from being deleted by falling off the bottom of the threadlist quite as early?

>>5807
^this

>>5828
That's a handy way of catching up on what threads may have changed, though usually they still have at least some of the text title and last post date. I think the most useful one I saw however was a rather simpler, yet more comprehensive type which just showed a reverse-date-order (ie newest to oldest) listing of each uploaded image for the entire sub-board (/g/, /f/, etc) as fairly small, fast loading thumbs with a timestamp and short version of the parent thread title underneath, 100 or so to a page. Good overview of what the freshest stuff from the whole section is, especially if your last visit was only a day or two earlier and you can therefore maybe reach what was newest last time you were on within the first page. Somewhat like a *booru frontpage, but a little more organised and without it being the default interface.

>>5844
This does annoy me a little, but I think that's a universal interweb problem, unless it could be fixed by e.g. adding (individual thumb appropriate) width= and height= fields to each img_src tag... or even just height, in fact... so the browser can reserve the space in the document framework. Seeing as they can be individually or collectively expanded from thumbnail to full size (or at least as large as will fit horizontally?) without reloading the page (thus dynamically changing both the source of the image as well as the height/width), however, there might be some kind of CSS or Javascript spanner waiting to fall in the works there.

What browser do you use, btw? For me, Chrome, and especially the mobile one doesn't seem to load (or at least bother to render and figure the size of) images until just before they scroll into view, first time round, so if there's a bit of loading delay - here or on any other site - I can hold "End" on the keyboard and wait for it to herky-jerk its way down the page without too much spurious data loading or stretching the overall page length out. And once it gets to the bottom, it "sticks" there with any further loads causing the centre of the view to drift upwards (ie it remembers it's "at the bottom", or maybe "X percent down the page", instead of the rather more troublesome "Y pixels down the page"). However, hitting the "expand all" button does mean it then comes adrift, which I don't quite understand, but as usually I'd only bother doing that in order to hurridly archive the entirety of a thread page (instead of picking and choosing), that doesn't matter so much.

3mbit isn't so great, sure, but having browsed similar sites on 512k and my current connection seeing to vary between 8-20mbit (mostly the lower), it wouldn't say it's terrible either. It's probably about what I get with my phone, both on wifi and 3G, thanks to the low power transceiver... Seeing as the median image size I figured further above was under 300kb, after doing an expand-all, that's better than one image per second on average, though the biggest ones will take a while (some were up to 6mb, so a remarkably dial-up-esque 20 seconds?). Dunno how big the thumbs are, data-wise, but I'd expect it to be maybe around 100kb each, including for the ones that are huge once expanded. And the non-image data itself should only take about 1 second to load. Take heart :)

Though a solution to this could be to have a clickable option to just swap oldest first / newest first. It fouls up the flow of any ongoing discussion, but otherwise should be fairly intuitive, especially as that would fit with the catalogue / booru-like layout if it was restored and you used it.

>>5845
That sounds like a pretty decent way of working things.
Can't remember which particular chan I saw it on, but an option set that has gone before is having, on the thread header list, a trio of "first 100 posts", "last 50 posts", and "show entire thread"... something like that anyway. So you could either read the thread from the start in manageable chunks if it's new to you, see the more recent few dozen if you're familiar with it - being able to jump back and forth in chunks from there, or see everything together if you want that for some reason (also being able to switch to that in-thread after opening it a different way). Given the way the threadlist and previews are arranged on GC this might be a bit trickier to do in an efficient way (it was on some more traditionally set up chan which didn't have the summary list at the top of each sub-board page, I know that much), but still worth investigating.
Even if it just loaded the last 50 by default, if this was made obvious to the casual browser, and the navigation back and forth / expansion to the full thread all at once was reasonably easy, that would work fine itself.


.....phewwww
right, off to the everyday normal world for another few weeks.
V short update, verbose anon from yesterday. Actually on phone now... Typing is still slow for some reason, though not terrible. Actual site, boards, threads working AOK, including the seek up/down, right from a few seconds after opening a thread.

Top work!
Greentext quotes have terrible spacing. It makes quoting anything that's more than one line really ugly. Any chance on setting this to the same spacing as regular text?

>foo

>bar

>baz
I just noticed that with the update, /lit/ goes back much further and thus my story threads have come back! This pleases the Aiko.
Excelent, I think without this site the net will die.I miss the old site thou, those were the days, without patreon, deviantart and the like.Just hardcore japanese manga artists who posted incredible guro pics, like tsepsesi, uziga, ah-dualism, juan-gothoh(back in the day) and many more.Thank you 4 keeping guro alive thou, good work gurochan!
>Weird... I think I *might* have tried to insert a weblink, or at least type something that might have looked like one, but I certainly wasn't dumb enough to format it like a full HTML anchor

It is triggered by "href", not full-blown anchor, in addition to common signs of URLs. For a time being, this is a necessary measure. Working two-stage posting with captcha into the current codebase would be damn painful and is just not worth it. However, we have smarter spam checks in mind, just not yet ready to give them a try.

>I guess the server can't really take the liberty of assuming (...) that it's even actually the same machine (...)

>Would there be any way to address it as a QoS issue or the like, though?

No. QoS is inapplicable. QoS and traffic shaping kick into action when the networking node is experiencing congestion. Without congestion, QoS is either off as it should be, or doing meaningless work rearranging packets for no reason. And even with a full-blown packet reordering firewall, we (1) cannot reliably associate several concurrent HTTP sessions with a single client as you've pointed out, and (2) even if we could (using nonces, for instance), it would in fact be mostly useless and just create a good deal of overhead on our part.

>the HTML is a fairly meaty 258kb, the collected JS and CSS another 20kb

The math is wrong, divide that by 4 or 5 due to gzip content encoding. To address the issue, I will try to tune TCP_CORK and output buffers of PHP to give out generated HTML as a single chunk, or several large ones, to try and feed text content to browsers in one take.

>Is there a way to get the aforementioned autosageing thread restored to normal life in that case, or does the post limit remain, with it simply saved from being deleted by falling off the bottom of the threadlist quite as early?

Sure there is. Generally, if you feel some thread is dying prematurely, drop a line here, and I'll check and possibly revive it.
When you open the "Killer and Victim" thread in /rp/, the last two post aren't shown - they still show up if read from the main /rp/ page.
Also, instead of an up arrow in the bottom right of the screen my phone shows just a box with an x inside
Was wondering if there is an archive of older literature?
>When you open the "Killer and Victim" thread in /rp/, the last two post aren't shown - they still show up if read from the main /rp/ page.

Apparently the issue fixed itself.

>Also, instead of an up arrow in the bottom right of the screen my phone shows just a box with an x inside

Something is wrong with the font used by your phone. Guess I'll have to switch to FontAwesome someday...

>Was wondering if there is an archive of older literature?

Not really. There may be a bunch of archived threads not shown anywhere, and eventually they will appear as proper archive, but those date back to a couple of months ago at most.
There was a thread in artwork started by a Killing Children guy, was it taken down or was it a server failture?
>>6089
Most likely fell of the board and died.