>>1897 its hard to interact with a post that sounds retarded without risking to sound retarded myself

>>1898 thanks

I think you can just cache the featured threads. Like, when a new user fetches the index page, server bakes featured threads, cache it with timestamp of the time of creation. And when another user fetches the index page, server first checks if there's a cache that was generated in less than 1-5 seconds ago, serve the cached one if there is, bake a new one and cache it if there isn't. This way, even if 100,000 users request the index page in a single second, you will only bake it once.

>>1897 rip vichan >>1900 i understand php has the ability to cache, but ive yet to actually research much of that, either way ive been thinking about using a json file to keep track of active threads instead of an sql query, it wouldnt be super difficult but it still seems inefficient, plus i have no idea how many issues bringing a json file like that could bring me in the end.

>>1902 I'm not really much of a Php person but what I meant was just storing the contents of the featured threads (queried contents) in a variable as an object and serving it til it expires.

>>1902 Just *Someone requests the index page* if there isn't a valid cache, query the DB to get necessary data from the featured threads and store the data in a variable as an object for caching with a timestamp of the time you stored it. if there is a valid cache (was generated less than 1 second ago according to the timestamp), then just serve it to the user. If you use server side rendering, you can render the html right on the server with the data. If you serve a static page, then just give an html file to the user with js code that fetches the featured contents data from the server using rest api. Your server can return a json containing the featured threads data that was stored in the variable when user fetches from mysite.LOL/api/featured-threads

lol at this thread.

>>1904 thats probably what im gonna end up doing, although i probably should get a proper admin panel setup before i keep adding more board functions .

imagick is gonna make me burst a blood vessel. i hate this stupid fucking api and its retarded nonexistent documentation, and i hate google for insisting on giving me search results from 12 years ago.

>>1909 Maybe it's time to move to Typescript?

>>1911 that sounds even worse, besides i was just using imagick for backend image processing. i think im gonna leave gif processing as the last thing i do, everything else sorta works rn.

>>1913 not the bad luck fortune....

>>1909 I have used imagemagick for a few things, including making captchas and thumbnails for an imageboard. my advice, if you don't want to post code, is to initially disregard the documentation for your language's port, and instead consult the c/c++ documentation, and/or the command line interface. once you have found a way of doing what you want to do with either of those APIs, you can look up how to translate that to whatever language you are using there are lots of examples on how to do things from the cli, specially things like making thumbnails, striping metadata or querying properties (width, height)

this thread is making me doubt how i handled images in my own abandonware, with imagemagick rce and all...

>>1915 it never crossed my mind to lookup the c documentation, ill be sure to look into that. i still feel embarassed with the current state my code is in rn, maybe ill make a git page for it at some point. >>1916 yeah no kidding, the fact that it even has vulns like that is just lame, totally kills my interest in using it.

There are alternatives written in rust and zig, which guarantee things like bounds-checking (when compiled with the ReleaseSafe flag in the case of zig) that would've prevented that cve: https://github.com/image-rs/image https://github.com/zigimg/zigimg The problem is that neither of them have bindings to other languages or a cli. The good news is that both zig and rust support ffi through the c abi, which means that you can expose a c interface that will then be available to any language that supports calling c libraries (python, javashit, etc.). If you only need to do those three things (query dimensions, remove metadata, generate a thumbnail) you could write that in either zig or rust using these libraries, expose a single c function like "Result processImage(const char* data, unsigned len);" and then call that from whatever language you're using.

>>1918 that sounds like an interesting solution, but way beyond the scope of my current project lol, i feel like it would be better as a standalone project rather than just another component for what im making.

>>1897 coding is.... suffering. i keep getting lost in my own code. am i gonna make it

Well, it looks like I'm going to have to eat my own words. I decided to check if you could actually make thumbnails with zigimg, and more importantly, if you could write a good C interface to the tool. It turns out that, for a number of reasons, they don't use zig's std.Io reader/writer interfaces, which means that you can only use it with files - not with sockets, memory buffers (reading is fine, but you can't write to an allocating buffer) or anything else. This meant that I had to fork the library and rewrite a few parts to use generic streams instead. This is important because, if you want the library to be usable from something like nodejs that has it's own event loop for reading and writing to files, it should either work on memory buffers and leave the IO to node, or offer some mechanism (like the std.Io interface) to implement the IO through node-api primitives. Anyway, the end result is this: https://codeberg.org/cirefl/spell Apparently node has a lot of options for using C libraries (https://nodejs.github.io/node-addon-examples/getting-started/first), and they all seem to be pretty good, but I don't want to install node.

Here is an example of how to use it from C, libspell.a is the library already compiled. It has a README with instructions, but it's just >gcc main.c libspell.a https://files.catbox.moe/2s9iq0.gz untar with >tar -xzf 2s9iq0.gz

>>1932 Stupid question but what are the benefits of thumbnailing an image? Right now im just shrinking down the image via css (probably isnt good for the image quality).

>>1937 Saving bandwidth, so that pages load faster.

>>1938 I dont know why i didnt think of that lol, does make a lot of sense. I hope leaving the loading attribute as 'lazy' helps a bit too, im way too lazy to add thumbnails.