bfarber

Please use the peer to peer forums for support.

You need to change how you do what you are trying to do. I don't even know what you are trying to do, but you can always just give your content a class in the bbcode and then use javascript in your skin to execute on that class // Here's your javascript code to execute on element }); $$('.someclass').each( function(element) { But this isn't the place for support. I feel relatively confident in saying we won't be bringing in javascript to be allowed via the editor itself. Can't say for sure about custom bbcodes, but ultimately security is going to trump functionality when it's a non-essential feature.

We know, and there's an open bug report about it.

Please post bugs in the bug tracker. The bug you are referring to I believe is already known.

Ah, ok. To summarize... You want to be able to use javascript in the editor.

Even so, if we're a couple weeks off, it's not the end of the world. All we can do in development is estimate. There's no way we can see the future (e.g. exactly how many/important bugs will be submitted with RC1).

It's simply new is all. Once you get used to it, it makes a lot of sense, and allows applications to be complete segregated and sectioned off from the rest of the code. Add a folder and you're done. Delete a folder and files for the app are gone. A lot cleaner than having to upload your files to 10 different folders (and then trying to remember what to remove). userInfoPane is in skin_global. You can include one skin template directly from another skin template now, so you won't see this called in the source files pretty much at all. Instead you'll see this in skin templates {parse include="userInfoPane" group="global" params="$params"} Which means the skin template will output the results from skin_global -> userInfoPane (passing $params to it) wherever you see that tag. A lot of this is covered in articles on the resource site. Loading a member: http://resources.invisionpower.com/index.php?appcomponent=cms&module=articles&article=7533 Outputting content I don't think I've written an article on, though I'm sure we can do so. Extending group configuration: http://resources.invisionpower.com/index.php?appcomponent=cms&module=articles&article=7529 TONS of various information: http://resources.invisionpower.com/index.php?appcomponent=cms&module=articles&article=7536 That article is primarily related to upgrading an application, yes. However, it goes into detail about the file structure, what files can do what, and so on. It's very useful so long as you are familiar with how to do things in 2.3. We said we were shooting for a June release, and to my knowledge we still are. We expect an RC2 and at this time that is the only further RC release I am aware of in the works. The thing was, we were shooting for December originally. But then we had so much great feedback with the preview site we were determined not to ignore it simply for the sake of rushing the release out. We wanted to incorporate as much as possible that made sense. The spam controls were greatly enhanced. Facebook Connect was added. The personal conversations changed a lot. Friendly URLs changed a lot and were made extensible. And we won't talk about the skin changes. A ton was changed due to feedback we received, and while it has delayed our original release plans, I think in the long run everyone will agree that IPB as a product is better because of the changes. The subscription manager is nearing completion from my understanding. It will definitely be out for testing before IPB3 goes final.

This is a known reported bug that I just fixed last week. It will be fixed in RC2.

Google search is a great alternative, however you won't be able to search private forums, etc. You have to change MySQL limits in the config file to allow searching less than 4 char words. I agree that Sphinx is the best solution if you want searches of words less than 4 chars, though you'd need a dedicated server.

The template editor has been redone for RC2

It's something I *really* wanted in 3.x, but the objections to it were more or less that with the login system being extensible it's very difficult to add a "quick login" feature. What if you only allowed OpenID login, for instance. A username/password combo would be useless wouldn't it. It would have to support the full login system, at which point it's no longer quick. Also, if you use Facebook, their TOS states that you have to always show the facebook connect option next to any login fields you have, so you'd have to incorporate all that stuff into the quick login, which wouldn't be simple I'm sure.

Post archiving has been on the drawing board for a (really) long time. It's high on our priority list, but it's also very difficult and very invasive. Let's just say it's still on our to-do list for a future version. As Luke said, however, it's difficult to cache this sort of data due to permissions.

We turned it off because a few of our members felt the need to target certain other members and negative rep all their posts. In any event, you can turn it on and off and there are some controls for it in the ACP.

Yeah I'm lost. Can you explain your suggestion please?

I wouldn't post it as a bug. I've updated the CSS file, but for the image I would just update the article at the resource site. :)

Yeah, people that have avoided beta testing have now gone ahead and upgraded their live site, so there are a ton of one-off, rare, off the wall bugs that ARE bugs, but are bugs no one had run into before. It's expected. It's why we have RC releases before taking a "beta" to "final".

No it's not a security issue. Someone attempted to use Facebook connect, and as the error states, the library couldn't connect to Facebook's server (or couldn't read the response, etc.).

Or computers for that matter. And many users clear their history as well. A better alternative I wish we could implement would be to use Google Gears. This is the sort of thing Google Gears would be absolutely perfect for. Let each user store their topic history on their own computer, and let their PC/browser work out topic marker. Alas, it's not realistic. Additionally, last I knew there was no cloud support for Gears (e.g. to share data between computers).

Could all be done with the current portal, just requires some skin editing really (and possibly someone to write the plugins you need/use for the IPB portal).

http://resources.invisionpower.com/index.php?appcomponent=cms&module=articles&component=articles&article=7674 Feel free to update the article, etc.

Yeah, you can only override source action files. So when class files take over and do the work (and especially when they redirect, etc. afterwards) it makes things a little challenging. Some class files have built in hook functionality (like publicSessions.php) but not all. I think you'll have to modify this for now, but we will look into building in specific hook functionality for the posting library in the next update, as that's very useful functionality.

I don't think we'd ever integrate my old modification, though we might enhance the IPB portal a little more over time. What specifically do you have trouble setting up? When you go to the portal page in the ACP there's a list of the "plugins" available. I think you presently have to edit the skin template to show them - could probably change that so you can just enable/disable them I suppose. Other than that, anything specific?

Fine fine fine, since you twisted my arm (and *ahem* wrote the code yourself)

You could within the application itself, but not outside the application. @terabyte, cleaned way is to support an array of caches. Good suggestion. Easy to implement in next release (e.g. 3.0.1)

[quote name='tera