Leaderboard

Perfect! I see it now. I ended up following your advice and created an fgetcsv PHP script (which only took me an hour, not the 2 days I anticipated :-) Now instead of the hassle of opening the file in excel, copy-and-pasting into text editor, creating a mySQL lookup, formatting the data to paste back into Excel, etc., all I have to do is open up SSH and type "php my_new_script.php" and voila.

Create a view for yourself that shows threads and the initial posts. It'll make life easier. Though I'm really skeptical that XenForo doesn't have a way to get that information sort of finding the first post for a given thread ID - after all, since there is an ID in the first place, surely there is some source generating that ID, right? Once you have the view the query to find users is trivial.

Yup. Personally I would also be tracking the nodes as members of the chart itself, but that's besides the point. Sounds too complicated. Speaking of complicated, you could create a NodeCollection object that offers iteration by category and series. The series and category objects then use that collection instead of managing their nodes manually. I'm leaning towards this. Having links on both ends makes it harder to move things around, as you have to remember to update both links, but it's not too unreasonable to do so. Meh. If the id isn't set then there's no operations to clear it, but instead it adds operations to check the value. More lines of code for no net benefit. The nodes must be cloned because they can/should only belong to one chart. No cloning means you are reusing them in two places. Same reason you have to clone the series and categories.

Here it is colourized php output:)

And the problem is... that it's not replacing anything? Metacharacters like \e do not work in single-quoted strings.

It's extremely unlikely that a Windows update broke this. Something else happened.

Perhaps CSS Grid

There is that risk, yes. But what I haven't said is that you're really the only one here who knows your application best. There is no one-size-fits all answer to stuff like ecommerce. No one can just tell you what to do and be totally right about it: every company needs something a little different, and when random people on the internet give advice some of it will be right and some of it will be wrong. I also don't think I mentioned but your questions are (mostly) not technical questions. They're business questions. Application requirements. So what you should do is figure out, as best as you can, what the requirements are and how to go about satisfying them. Is there a requirement that an order exist in the system before the user submitted payment? Is there a requirement that a cart be saved in an account instead of temporarily held in the browser? Create a specification that describes everything you need to support, then make sure what you code supports it.

You probably saw the behavior you did due to using sessions. When you start a session PHP will lock the session data so that it's not affected by other processes. This lock exists until you either call session_write_close or the process ends. So if you're long-running process doesn't need to update any session data, call session_write_close prior to starting it. That said, lots of concurrent long-running processes could block a server. Your HTTP server will process each request using a thread or worker process (depends on the configuration). I'll only spin up a certain number of these based on the configuration and if that limit is reached it'll stop responding to requests. Your long-running processes would tie up some of these threads. The number of threads available on an actual server will probably be relatively high though, so unless you expect a lot of these processes to be running concurrently it likely won't be an issue. If the server is setup with something like PHP-FPM or a CGI setup though, the number of allowed PHP instances may be smaller. You limit would be the smaller of the the http server's limits or PHP's limits. If you want to keep your site responsive though, the way to manage that would be to offload the work to a background process so that your website can continue to respond to requests. The user would then go to the page which would trigger the processing and you would respond with a message like "We're working on your request, check back in a bit". When the process is complete give the user the results. There are many ways to accomplish this, such as using services like redis, gearman, beanstalkd, etc or simply adding records to your database and having a background service checking for new records periodically.

Not even remotely the case. Locally, were you using the built-in server that PHP provides? Don't. It's good for quick stuff but it's not a real server. Set up your development environment to match your production environment as closely as possible.

...and you are NOT using a framework like jQuery or Prototype, think long and hard to come up with a very good reason why you are not! In all my years of coding, the only valid reason I have ever seen for not using one of these tools, is because someone is trying to learn it the old fashioned way (but not necessarily actually build websites with it). Or...someone is trying to build their own framework. That's it! IMO there has been no other reason worthy enough to warrant not using jQuery or the like! "It will bloat my website, increase page load time, blahblah" is not a good enough reason! These frameworks are compacted and browsers will cache them! So if you post an AJAX question here and your code and/or question does not involve the use of an existing framework like jQuery, then be prepared for you first response to be something along the lines of "Why aren't you using a framework?" Seriously. It is super easy. Way easier than that code you're trying to post. Save yourself the headache. Get jQuery or similar. DO IT.

It was not my intention (nor do I think I implied it) to say you're stupid if you don't use a framework. I said do yourself a favor and make your life easier. Also, I am not "just another soldier" in the "we use frameworks" army. I actually actively resisted and opposed frameworks for a very long time. I too made arguments such as "If people learn jQuery, they won't learn the core language and therefore they will be weak." But the bottom line is that there's always going to be a certain amount of coding involved to keep things cross-browser compatible. And after several years of developing and maintaining my own baked framework (because that is essentially what you wind up with), I came to the realization that there's a whole lot of people out there much smarter than me who are dedicated to maintaining frameworks such as jQuery, vs. just myself, and on my very best of days my code will look very similar to theirs anyways. In short, I came to the realization that it was a waste of my time trying to develop and maintain my own baked framework, because my coding career does not revolve around that framework. Now, I still agree with the notion that one should take the time to learn javascript without frameworks, before diving into using them. I still absolutely agree with the dangers of not properly learning the nuances of javascript if you don't. And the same can be said for any language and framework. But if you've reached that level of expertise, all you are doing is holding yourself back by dedicating time and effort to maintaining your own baked solution. There's basically no compelling argument to do it, unless you are looking to distribute it and focus solely on it. Literally thousands of sites and coders out there developing, testing and submitting feedback etc. to a framework will always do it better than you, one person, trying to basically do the same thing on your own. And for what? Bragging rights? If I'm "just another.." then tell me, what makes you think rolling your own is better? I honestly want to know, because as I said, I did start on your side of the fence. Anyways, I also agree that there's little point in using it if you're only going to use like 1 tiny piece of it. I suppose I will concede that maybe I should amend the OP to weigh the options. But thing is, 9/10 times I see people not using a framework for stuff like AJAX.. turns out the site they are working on is already using a framework. This certainly comes up a lot more for freelancers and coders working in agencies who work with many clients on many sites and it's constantly new sites/clients in the door, vs. some coder working as web dev for a single company. Point being that if you get hired by a client to do some work on their site, it is better to evaluate what they already have going on there and use what's already there, than to just start throwing your own stuff into the mix. If you want to talk about unnecessary bloat, well that's a prime example right there. P.s. - telling me to "keep it civil" right after you've thrown out a "you're just another.." statement.. classy.

Lol first impression was "who the hell is starting yet another thread in caps". But I think many people here agree on what you just wrote. I don't even bother reading vanilla js doing ajax stuff.