chuckf

This is a request for you to make site-wide search and advanced search more generic. I'm writting an app for IPB that can only be used by subscribers. I've read the article and implemented searchPlugin and searchDisplay and they are working however the integration capabilities could use more support. 1) My app disables searching app specific data for non-subscribers resulting in a "No results found for..." message. I'd like the ability to change this message to something like "Only subscribers can search the <app-name> database". 2) The advanced search form is currently geared toward searching forums and uses forum specific lables like author, forum, post, etc. I think these terms should be more generic, e.g. change "Find in forum:" to "Find in:". 3) My app lets subscribers maintain various lists akin to forums and topics. I'd like the ability to add these lists to the "Find in forum:" list box in the advanced search form. I know what I'm asking for is not trivial but it would provide a truely integrated site-wide search capability.

I would like Subscription Manager enhanced so I can offer free trial packages to my community. I could simply set the amount to $0 to signal a free package type but I suggest supporting it specifically by adding a "Add Free Package" menu item under Manage Packages because I'd like it tracked by IP address to help ensure that each user can only try the "free trial" once even if they create a new account. I'd like an admin override to allow the same IP address to subscribe to the free trail package more than once to handle the scenarios where several people in the same household want to try it or where someone didn't get a chance to use the free trial (for whatever real-life reason).

I understand your logic. However, please consider that perhaps the reason InnoDB isn't used much is because it was not only hard to make apps for IPB but also because IPB didn't support the features that InnoDB provides. Now that you've made it pretty easy to make IPB apps I think InnoDB use would grow if you supported those features like transactions. In the app I'm writing now I'm using InnoDB tables primarily for their foreign key support. This makes coding routines that delete records in a parent table easy as the engine automatically deletes corresponding records in child tables. As to the development time required; I'm not privy to your development cycle protocols but considering it would only require 3 wrapper methods, 'beginTransaction', 'commit', and 'rollback' I figure I could knock it out in an hour or two for mysql.

I don't understand why it's unlikely you'll add transaction support but I'm grateful you are considering adding the getter for the connection_id. If you do add the getter can you also provide a method that will return the api type in use (i.e. mysql, mysqli, etc.)?

IPB 3 provides the framework for some pretty sophisticated applications. I'm working on one myself now and realized I could save myself some work and headaches if IPB would support transactions. I searched classDb, classDbMysql, and classDbMysqlClient but didn't find methods resembling 'start transaction', 'commit' or 'rollback'. I was going to use the mysqli api directly for this functionality but I can't use the 'connection_id' since it's protected. So does IPS have any plans to add support for transactions? Or at least provide a getter for the connection_id?