Messages

Ok, in terms of a forum this means that it'll need to incorporate a user system of some sort. That said, since it'd be part of the actual software in that case, what other things do you think users could be used for?

For instance, someone mentioned posting comments on individual pages. Should that require a user or be allowed to guests as well?

Well if I were to make something like this it'd probably use a templating system like we use for the ecommerce system I work on. Primarily, you can set up multiple template (having one as the default) which allows different pages to use a different template depending on what's choosen for that that page (yes you can change them too). Nice for things like holiday theme layouts and the such.

It would more or less be HTML with a few optional widgets to add in which would be built into the software. More or less things like <% calendar %> to auto-insert a calendar widget which you could have styled with your own CSS (it'd have a standardized class naming scheme to override things, and a default style of course).

Outside that, most of this kind of stuff is standard to a CMS (Content Management System). Including page generators and advanced direct HTML page control.

The issue I hear of more often than not is ease of installation and setup. That seems to be a huge issue with most open source web software installations for some odd reason. So I guess the best idea would be to go through a listing of possible features and add/remove things. I.E. a design process. Probably should come up with a name for the software title too.

Ok so, this poses an interesting question as I'm bored and need a project to work on outside of normal work stuff.

What is it that people look for in web comic software? Like what sorts of features aside from being able to upload the pages and browsing them?

I mean as in certain things that people look for in different packages. Things that people wish were provided but rarely are. Certain useful features that exist in most suites. Plugin options, advertisement systems, surveys, etc...

Multiple DB support options (MySQL, PostgreSQL, SQLite, File System, etc...)

(no Xeph I'm not thinking anything like Artica, I'm looking at stand-alone setups with simplistic installation methods)

Might I suggest working on a design document for the project first, even if you're not going to get into the actual project just yet. It's a good idea to set up a roadmap before you start on large projects of any sort, helps keep ideas there and some structure on what to add when, or how things need to be implemented.

I also would probably suggest looking into PostgreSQL rather than MySQL for your particular idea. Mainly because MySQL is still lacking a lot of things that could probably make your idea much easier (though I suppose the longer you wait the better the chances a new version of MySQL that has the features you need will come out).

Writing something like that seems rather trivial for anyone with experience with PHP or well... any web scripting language. It seems odd that nobody out there has designed some sort of a web comic software with it's data access routines as different plugins for multiple storage methods. It really wouldn't be all THAT hard to implement something that uses either a database or file system for it's data storage (the wonders of proper OOP design).

How long has this Walrus 3 thing been in the works anyhow?

The problem with a lot of those packages and why they don't work right is generally more at fault of PHP/MySQL and/or lack of knowledge about them. There's a lot of people who plain flat out can't write code for squat and use things like deprecated functions which end up breaking in the later releases of PHP or MySQL when that it's no longer available (that or use some hacky-ass wacky method to do something that's actually not meant to work the way they use it, which also ends up breaking when things are fixed).

All in all... a little off topic but, Xepher how's that Arctica coming along? 

Generally it's easier to network a printer through things like a router IF and only if it's an ethernet printer (has a RJ45 jack to plug a network cable into it and the router). In that case it's usually a matter of hooking up the printer and installing the software (on Windows anyhow, under Linux it's a *little* more work but not a hell of a lot).

HOWEVER, if the printer isn't a network printer, you can still do so if you hook it up to a single computer and "share" the printer with others on the network. The downside being that the printer will be inaccessible while that machine is powered off.

The third possiblity is to use a print server such as the ones here. But last I knew those things don't always work very well (if at all), and can get pricey depending. Always research things like this to make sure they are compatible and will actually work for your printer.

As it looks like your printer is only capable of a USB interface, the only ways you can network it is via the second or third method I explained.

Congrats!


My favorite one to date was:

make me a sandwich
what? make it yourself
sudo make me a sandwich
okay

If you learn how to use ssh/bash it's as easy as a rm -fr foldername/

[Warning!]

Here's a list of videos that have been around but are still awesome.

Read a Book	Warning! Explicit language, not work safe.
Slaughter Your World	Warning! Cartoon violence, not work safe.
Ultimate Showdown
Llama Song

These are all rather well done, and kinda neat, all work safe too:

There She Is!!

Cake Dance

Doki & Nabi

Psh, run both... oi! Granted you can't run them at the exact same time, but you can still install them both at once and use whatever one you want to.

I stand by the idiots remark. 

Sounds to me like they're idiots.

Well the person who writes this is a real life friend of mine, so I can mention that to him. Hell I think the documentation was just written like 2 weeks ago.

Simple was the whole point of him writing this. Because Smarty *is* a total pain in the ass. It gets all this attention though, because... well... there really wasn't anything else that was actually worth a damn out there. There's plenty in Smarty that pisses me off, one of the most notable ones that I had mentioned is string concatenation, which you would think to be a native and easy part of a "templating engine". Then there's the escaping (it's the same concept as forgetting to quote SQL, you know what I mean Xeph), and the way math works, and how page and function caching works, and I know there's more but I can't remember them off the top of my head.

Now just a heads up, there are a few things that he's going to be changing pre-1.0 (release). I think he's still trying to determine on how to handle function params (names, non-named, ordered, etc...). Because as I've stated, we have in fact used this in several small and large projects and do on occasion run into a quirk or two that needs to be addressed. This is why it's not to release 1.0 yet.

Now I know a lot of people who work in PHP have heard about Smarty, but I tell ya I've never seen something so horribly over-complex as it.

Tell me the use of a templating language that can't even do string concatenation in a somewhat simple and sane manner? How about that it complies template to raw php code which can quickly become a nasty security hole on shared hosts? That's not to mention that it's flat out a pain in the ass in many situations and isn't exactly web designer friendly. The worst part is you have to MANUALLY escape things during output, which from a security standpoint is *retarded*. Things should be escaped by default and you should need to tell it not to.

Well now there's a templating system that exists that is sane, is just as fast as smarty, more secure, escapes things intelligently, and is web designer friendly.

I can also vouch for it's speed and ease of use as we've now used it on a few rather decent sized contract projects.

http://php-sugar.net/

I'm hoping this can come in handy for some people who are a little more code-oriented here.

I guess I've just learned long ago that simplicity is better than efficiency in most cases. I used to think along the same lines of preferring the other way, and to be honest if I were a large company like ebay I probably would go an even more complex but faster route, that being an actual server built and set up (possibly with custom complied server) just for the images alone.

In terms of the method I was stating, it's the far more flexible method, even if it is a little slower. Using apache config and static files makes it possible to stop hot linking, yes, but note that I was referencing finer grain control than simply prevention. The better of them being the capability of having images that only certain users could access, integrated with the rest of your system (yes I realize that you can in fact gain stats information via apache directly).

Now I do agree. There's no way I'd do this for just some small site which is *just* preventing hot linking to images. However, in the cases of things like needing preventative access to things that require user login for access, or some special users group, it sure as hell comes in handy (note you can just pass the information directly from the file system to the client too, far more efficient than a DB I might add as we've learned from hard experience >.<). For his case though, the static hot linking prevention through .htaccess is probably the best solution.

You don't ALWAYS do this to me. I'm not viewing either as right or wrong, both methods are equally as good, it just depends on the scenario that you're using them in.

That's debatable actually, if you set up your image cache correctly it's doubtfully 100x slower. It also can depend on many many other factors. For instance, on our primary eCommerce system all our images are stored in the DB, and all headers are custom built, and it's still blazing fast. The processing overhead you refer to may have been a problem back in the 90's, but with machines now days, it's not really enough to matter.