bfarber

Or in your hook code you can do addToDocumentHead() as includecss pointing to the proper location. Then you could upload the CSS anywhere and the source code could map to it.

You will need to use the peer to peer support forums for support.

Well, you have single-handedly saved the customer group's infamous red pips. I shall retract the virtual e-slap I delivered to you a week or two ago for your previous bug report.

Or you could use the ACP restrictions system so that they only have access to the languages area of the ACP. ;) Certainly should be safer than giving them FTP access.

Now, as of late our database backups have decided to start running early in the morning here (EST). I'm hopeful one of our server admins takes care of that soon. :whistle:

I'm not even going to ask *why* you had a backup of our red pips. :P But yes, that's what I was looking for. Thanks. :) I've updated our config.

That was actually part of the goal. In theory (not at this time, but at some point perhaps) we could remove the "forums" application for instance, and make everything based around something else. Perhaps at some point you could buy IPB with just the blogs, for example. Who knows? Our primary concern was making things abstracted and easily reusable. It's going to make it a lot easier to push out new things in the future.

That file was deleted during the upgrade it seems. And nobody seems to have a backup of the image.... >.<

FYI, javascript and AJAX execute in the user's browser, not on the server (well, with AJAX the script that the browser is calling is obviously executed), so you don't generally see server resource increases from such functionality. That said, IPB 3.0 is likely going to be a little heavier than 2.x, mainly because there's so much new functionality and much more abstracted code. You will definitely see an increased load at first if your site is open, as spiders are following new urls and reindexing content and so forth. It should level out pretty well over time, however. On the whole, after the optimizations we've done to 3.0, I think things are running about the same for 3.x compared to 2.x here.

Less than 1 is fine. But that's a generalization. I've seen servers run like there's no problems with loads much much higher.

Hello, 1) Most of us are against this feature, I'm afraid. It's a preference type thing. However, I'm positive there will be mods/hooks to accomplish this, as there have been in the past. 2) Again, we're not very fond of this feature. We do want to implement a fully featured tagging system, which would likely cover the use cases most people have brought up for this, however. 3) You can see moderation history on a topic if you are an administrator using the moderator dropdown at the bottom of the page ("View Topic History") 4) You can already accomplish all of these things on topic view from the bottom of the page. Many people, however, do use the quick mod tools in the forum listing (e.g. to correct a typo in the topic name, or pin a topic they know they want pinned). :) Are you saying you'd like the functionality duplicated on topic view page by adding links to the top of the page that do the same thing as the options at the bottom of the page?

You'd need a custom modification.

You have to set a load limit for it to calculate the load.

Why yes, you're welcome. I do take all the credit of course.

I'm not positive. All I know is that we are fully aware it's not likely to be included with 3.0.0 due to time constraints.

It would require some modifications, unfortunately. I don't see any way to retrieve a list of topics created over a set time frame without performing an actual search (member or keywords). Could either modify the active search function, as it presently has one day hard coded into it (e.g. make it accept an input parameter to determine time frame) or could modify the search routine itself to run without keywords, if there are dates supplied (best solution, but may not be nice for big boards).

I think you guys misunderstood the skinning competition. The winning skin from the skin competition is not likely to be included with 3.0.0 final. It will most likely not be included with IPB until 3.0.1 or later. We are not basing the release of IP.Board 3.0 on the results of the skin competition. :)

I don't think anything in PHP 5.3 is going to break IPB. That said, the latest version I've tested with locally is 5.2.9.

Yes, a custom group image overrides pips, as it did in previous versions.

Please read the announcements in full. We publicly stated there *would* be bugs in the RC releases and you should only upgrade if you felt you could handle the bugs until they were fixed (by/in the final release). We release betas (and release candidates) for a reason. It's to find and fix issues that we did not come across ourselves. With so many people using the software in so many different configurations there are always bound to be issues we simply didn't encounter, and that's why pre-final releases are done. Long story short, we're not going to rush RC2 because RC1 has some bugs. Nor will we rush final because RC2 WILL HAVE BUGS. We're going to continue working to make the software as stable as possible so that the final release is as bug free as we can get it.

The IPB portal has plugin functionality - we have written basic plugins for most of our applications (mini-calendar, random gallery image, random download manager file, latest download manager files, etc.) so I'm not sure why you'd think it only supports listing IPB topics. You *do* have to edit the skin template to show the additional plugins, however.

And once we release RC2 you guys will find previously unseen bugs in RC2 and will want final. And we'll release that and you'll find bugs and 3.0.1 will be around the corner. The software, at present, is pre-final software. That means it has bugs, we realize this. The final release will also contain bugs, which will be fixed in 3.0.1. And 3.0.1 issues will be fixed in 3.0.2. This is never going to change, it's how all software works, so there's never any point in rushing or pushing for the next release. It will be out once we feel we've addressed all the issues we need to and we feel the new version is stable enough for use.

Yes, the release candidates are only available to customers who hold a license for the respective applications.

Yes, the portal is still included with IP.Board 3.0

We have an internal date we are targetting for RC2, but we're not going to announce it at this time. Suffice it to say, that date is not "1-2 months" away. But we'll see how things go in the tracker before making a final decision. Why do these topics always come up right after a release? :rolleyes: