bfarber

None of this is done at all now, so all resources related to this would be added to current resource usage of posting (keep in mind)... We'd have to 1) Parse the post looking for attachment bbcodes (which we don't do now) 2) For any found, run a query to lookup the attachment based on the ID 3) Determine if it's already public (which could be a challenge upon itself - would need callbacks for other apps like blog that might need to run custom code to verify if attachment is normally publicly viewable). What would be public at this point? Member can view? Guest? Poster? Owner is poster? 4) If not, then is it the owner posting? Has this attachment already been used elsewhere that IS public by the owner? This right here would be difficult. Overall the nature of how this would work is very unstable and unreliable. What would be better I think is a proper attachments manager where the owner can check a box or something to make their attachment public, and then it can just be re-used anywhere without permission checking for view. As for download, I'm not sure yet what we would do. If an admin says guests can't download attachments in Forum A, we wouldn't a member to be able to override that decision. Would they post the attachment in a public area, then re-use it in Forum A? What happens if they post it in Forum A and re-use it elsewhere? What if the admin doesn't allow members to download attachments in Forum A, but does in Forum B, and it's re-used in one location or another? Or what if it's posted in blog, but then re-used in Forum A? There's a million what-ifs here that need to be resolved before we can do such a thing..

That sounds relatively resource intensive. You have to understand that the attachment system does NOT (at all) work based on WHERE the attachment bbcode is posted. It works based on where the attachment was UPLOADED. That's how permissions are verified.

Setting aside the rest of your suggestion (which has some interesting implications, regardless of whether it's the direction we want to go), this here presents a chicken and egg scenario. We can't easily change this. When the framework starts loading everything it needs (settings, caches, etc.) it needs to know what application is being accessed BEFORE the settings are loaded, so anything saved via the ACP isn't "known" at the point we need to know which application to load - hence why a file edit is required for this particular change. Sometimes we need data before settings are actually loaded, so we can't store that data in the settings.

Yes, IPB3 only.

The only roadblocks are permissions (that's what I said before about the practicality of the suggestion). We can't just allow any attachment to be downloadable to anyone in the event it's reused somewhere in a forum post. Imagine PMing an attachment to a friend and some member randomly manages to guess the id and download it, even though it was a private attachment. We'll first have to figure out a system to allow this permissions-wise. I'm certain that won't happen until the next major point release (i.e. 3.1, rather than 3.0.x) at the earliest.

That entirely defeats the purpose of mapping a skin based on the URL though. I don't see why we would change this functionality myself. The idea of the URL mapping was to force a skin based on URL parameters.

When we have more information on when it will be available, we will announce that information. See post [url=", where this was already stated. :)

I could have sworn multi-select was an option. Perhaps I was mistaken...

I *believe* there's a bug report open about this, but I'm not positive. It would be set "awaiting feedback" or "flagged for future version" if so. You can accomplish the same thing using a multi-select.

You can reuse the default images in your custom skin.

When we have more information about the release, we will announce it.

This is already a per-group feature of IPB. You can setup signature restrictions for each group from the Manage Groups area of the ACP.

We will be discussing 3.1.0 in due time. We are not ready to publicly talk too much about it just yet, however. There's only so many development hours in a day, and we've been working at updating IPB 3.0.5, as well as new versions of Gallery, Blog, and IP.Downloads, and a point release of IP.Content with a few new features.

IP.Content 1.1.2 is being prepared for quality assurance testing, and I just wanted to take a moment to let everyone know about a couple of new (but useful) features and changes in this minor point release. Stability and Performance In addition to fixing all reported issues, and adding in proper support for our MSSQL driver, we've added many resource improvements throughout the software. Databases and fields are now properly cached, preventing the need to query this data throughout the front end of IP.Content. Additionally, we've added a few MySQL indexes that speed up certain areas of IP.Content significantly, reducing overall overhead and improving responsiveness. Database feeds A new feed plugin module has been added to facilitate database feeds. You can create feed blocks pulling content from your custom created databases. Various sorting and filtering options are available when you create database feed blocks, allowing for powerful control of how you display content from your custom databases. Truncate option for listings An option has been added when you create or update your custom fields for a database to control truncation of the field content in the listing display. In previous versions of IP.Content, data is automatically truncated at 100 characters for most fields (and certain fields have special behaviors, such as attachment fields displaying a count of the attachments, instead of the normal attachment HTML). Now you can disable this, or change the length to truncate the content at. This can be useful for providing longer previews of an article in the listing, or to display attachments instead of just the attachment count. Member lookup field type A member lookup field type (a user AJAX type-ahead field, like you see in the messenger area of IP.Board when typing in a username you would like to send a private conversation to) has been added. This allows you to create fields that directly relate to a member in the IP.Board user database. Database relational field type Several requests have been made for a database cross-referenced field type, and you will now have one in IP.Content 1.1.2. Essentially, this field type allows you to create a dropdown field in one database, using content from another database. You define which database and field you want to retrieve content from, and a dropdown menu is created. The user (or admin) selection when saving a new or edited record is stored as a reference to the record in the remote database, so if you update that remote record, it's automatically updated anywhere that it's referenced. This concept may be a little difficult to understand at first, but an example should help clarify it. If you are creating a database of recipes, for example, every recipe is going to need to reference the ingredients used. With this new capability you could, for example, create one database of ingredients, and then in the recipe database you create, use this new relational field type to provide a select list of ingredients, rather than requiring the user to manually type in the ingredients used. If you find later on that you made a typo in an ingredient, or need to include a registered trademark symbol for a specific brand, you can edit that record in your ingredients database, and subsequently every recipe using that ingredient will be automatically updated. We hope that these small but useful and oft-requested features will go a long way towards making IP.Content more flexible and customizable for your installation. If you have any questions or feedback we'd love to hear it! Just drop us a comment at the end of this entry. :) View full blog entry

Well, templates and CSS are fully customizable. It's of course understandable if a software product doesn't meet your needs, but I'd hazard a guess it's unlikely we'll write up a separate concurrent package that does one of the same things IP.Content does. A more realistic approach would be to figure out what IP.Content lacks, and then enhance it further to accommodate.

Generally speaking, we ask that you air complaints about software (other than ours, naturally) in more appropriate channels. Just a friendly reminder. :)

You can do this with IP.Content already. :) http://community.invisionpower.com/resources/articles.html Here's an example.

If you want, you can submit a ticket to account assistance and have your two accounts merged as well. :) You're not required to or anything.

We can rarely tell you what will and wont' be in a future release. The release plans are very fluid, and change as situations/issues/etc. come up. I can say it's on the list of potential features for 3.1.0. If it will make it into the release or not is not something I can definitively answer yet. 3.0.5 may or may not be the last point release of 3.0. There's too many unknowns to answer that yet.

Yes, that would be correct, because your "parent" would technically be the next class up the chain.

Ah, ok then. No problem. :) If you uninstalled that hook, but the class hadn't reset properly, submit that as a bug (assuming you uninstalled it through the ACP normally, etc.).

If that third party hook was ALSO an action overloader that ALSO overloaded public_forums_post_post, then the hooks system tries to automatically account for this. You can't have two hooks overloading the same class (if you are familiar with php, we are extending the class, and you wouldn't have class a extend class b, and then class c extend class b, for instance). What *should* have happened was something like your first hook extends the third party hook you installed, then that hook extends public_forums_post_post. In the end it would be like hook_a extends hook_b ... hook_b extends public_forums_post_post and IPB would do new hook_a()

I think this should be common sense if you guys think about it for a little bit. :) We offer a bulletin board product, so it's not really in our interests to offer hosting for competing products. There are other reasons (some have exploits, some are resource intensive, etc.) why we may not allow specific individual scripts as well (such as Unreal Portal). I think there are plenty of other hosts available if you want to host a phpbb or vb board.

Yes, I still use it (used it - it's gone now). I'll add a new one at some point. :P