The current Bug Tracker page looks awful with the blotchy grey Statuses:
I suggest you change the Statuses into Tags that are Color Coded. The Tags would be "Cannot Reproduce", "Awaiting Feedback", "Unconfirmed", "Confirmed - Matt", etc and would be pre-defined. The "Unconfirmed" tag could be shown in Grey. The "Fixed" tag could be shown in Green. The "Confirmed" tags could be shown in Red and other tags having appropriate colors to make them stand out or fade into the background. It also might work better to have the tag shown as a prefix to the "By" line instead of a suffix to this line. That way, the status of the report will be shown as a column just under the Report Title. No need for the text "Status:" to be repeated in each tag too. Just a suggestion...
I did submit a Support Ticket to get access to the Pre-Release download for working with the IN_DEV mode this weekend, but no response from IPS and I fear that I won't get access to the download tonight since it is 6:30pm ET on a Friday here and I bet all customer service people have taken off for the weekend. My current 1.0.12 install had some reported issues with IN_DEV and Designer's Mode which I believe might now be fixed in 1.0.16.
I think IPS could have handled this better. My suggestion is to automatically add a free 6 month IPS4 Suite license to all "legacy" license holders. This would have smoothly transitioned us to IPS4 and then IPS could offer to "convert" existing Lifetime/Perpetual licenses to IPS4 licenses for a further $75 account credit (or whatever $100 minus 6 month IPS4 license is). That way, we wouldn't be inconvenienced by the new license policy and would have the time to decide whether we want to keep an IPS4 license active.
How do I "convert" my Lifetime license to IPS4? I can't download the latest Pre-Release anymore since you require "active" licenses to do so.
Also, what happens to my Copyright Removals that is on my Lifetime license? Does this "convert"?
I also have inactive IP.Blog, IP.Gallery, IP.Nexus, and IP.Content licenses that are "attached" to my Lifetime license. Do these inactive licenses "convert" also so I only have to pay a small fee to activate these for IPS4?
I also have 2 Permanent inactive licenses that don't have Copyright Removals attached. I have never successfully established a community based on the IPB licenses I hold (I tried several times, but all were failures). I want to give IPS4 a try basically because I can implement my own custom app rather easily to build the type of community that I think will be successful.
If you don't mind, could you briefly describe the fees (both initially and ongoing) that I am going to incur to deploy a community based on IPS4 under the new license structure assuming I get credits applied for my old Lifetime license (and 2 Perpetual licenses and the inactive other licenses I hold) and I will be using Copyright Removal, IPS4 Forums, Blog, Gallery, Nexus, and Content on my new site.
Its an "early preview" site now and they only approved the first 906 people that registered. You would have been approved if you registered earlier. When they open it up to many more people, they will put out a public notification so more people know about the site and can contribute to making IPS4 the best release ever. Previously, you only really found out about the site by reading Charles' signature or seeing someone else discuss the site here.
As I've been playing on the IPS4 preview site now for a few days, it appears to me that not all the features I had hoped would be implemented made it into the suite. I would like to encourage third party developers to implement my desired features, but I really don't have the budget to post a Custom Project and pay for the whole implementation.
So, I was thinking that if IPS had a Contests section here, that I could run a Contest and get some developers to compete for implementing the hook/module/app for a lower price than doing a Custom Project. The rules of the Contest could be that all Contests have at least 1 prize ($100 minimum) and that all hooks/modules/apps submitted be able to be sold by the developers in the marketplace. And, that the Contest holder get a royalty-free copyright-free perpetual license for the Contest winning mod to use on their site.
For example, if I would like a Reviews forum type (that works a bit like the Questions forum type in IPS4, only for Reviews with Ratings), I would post a $250 Contest and describe the feature I want implemented. Various developers who think it is worth an afternoon or so to implement their take on the feature and submit their completed work to the Contest. Only the Contest holder would be able to download and test these developer submissions. The Contest would be kept open for maybe up to 30 days at which time, if the Contest holder hasn't picked a winner, IPS would. To make sure that winners get their winnings, IPS could require the Contest holder to pay the winning prize money to IPS before opening the contest and IPS would handle paying the winner when one is picked. The prize money would be refundable to the Contest holder only if the Contest holder or IPS don't think any developer has submitted a solution that is acceptable.
I'm willing to bet that there are lots of us IPS4 customers out here that would love to sponsor various Contests for their favorite missing features of IPS4. Developers will be incentivized to work on lots of different add on products by entering the Contests that feature a high enough prize for them to spend the effort to win the Contest even though the likelihood is that they might not win the prize. And, all Developers, regardless of whether they won the prize, can try to sell their submission in the MarketPlace. This might really jump start the MarketPlace with higher quality third party add ons than the current MarketPlace.
I'm hoping that the new IPB 4 will not only support Master/Slave setups out of the box, but that the software is transaction oriented. For example, when creating a new topic, all the inserts and updates should be in a single MySQL transaction that is applied to the Master and replicated to the Slaves as a single transaction. SELECT FOR UPDATEs that are input to a subsequent UPDATE should be applied to the Master connection and other normal SELECTs should be redirected to a Slave connection. And It would be nice if the software handled COMMIT failures to a Galera Cluster so that temporary locking issues on one of the nodes is handled properly.
Anyway, I'm hoping that IPS took advantage of the code rewrite to implement enterprise quality SQL view of the database.
I just thought of another option. If the 4.0 RTE editor used unique classes for all generated HTML (instead of, for example, "class='ipsQuote ipsPad ipsSmall'" which uses classes that are used elsewhere 4.0) and 4.0 placed these post styles in a separate CSS file (and used CSS selectors to define the scope of these styles in the HTML), I could easily create a separate CSS file for sending the post in email.
It is my understanding that most modern email clients support the script tag for CSS. But if I really wanted, I could probably easily regex the post HTML to inline the styles.
In fact, I think 4.0 could support this approach for everyone so the ability to email post bodies (in HTML) was a built in feature.
I think it would help for IPS to post a "4.0 Progress Bar" in the header of this site. The progress bar would be updated weekly. The end of alpha (where the feature set is frozen) would be 50%. The first public beta would be 75%. And, the GA availability would be 100%. Hopefully, we are close to 75%, but I really don't know what IPS would consider the proper setting for this week.
If IPS updated this progress bar regularly and accurately, this would go a long way to satisfying those that want an estimate of when it will be ready without IPS committing to any estimated completion dates. The Progress Bar would just reflect IPS's best guess as to where they are in the development process.
And, I would check once a week to see how things are going... I'm really looking forward to 4.0 which I hope will fix many of the annoying deficiencies of IPB 3. A Progress Bar would go a long way in satisfying my curiosity of wondering when we will finally get to see it and make let this endless thread die...
Thinking about this more, I think I am willing to accept that not all post emails would display perfectly in all mail clients since I could always insert a link to the post in the message so the few posts that might have some issues can be viewed in the viewer's browser. Really, probably 99% of posts don't have complex HTML other then quote/code boxes. I don't know much (or anything) about 4.0 and Email Templates, but maybe the templating system will have enough support for including an HTML version of a post body that would work (for 99% of posts) in most email clients?
On the other hand, I'm thinking the best choice for me will be to replace the RTE Editor with the TinyMCE Editor used in RoundCube and just use RoundCube code to generate the HTML for storing in the database and converting the HTML post to a proper email message.
Or, maybe just disable those features of the RTE Editor that produce non-email compatible HTML and disable changing links to YouTube videos into embeds for the email clients.
Anyway, I guess I will just wait for the 4.0 beta to see what is doable and whether I need to do my own customization for formatting HTML posts for email messages.
I understand that this would be tricky and that is why I was hoping 4.0 would make this easier. I thought 4.0 might have the ability to build a parsed representation of HTML (as part of the process of making the RTE HTML "safe" and this might let you inline CSS styles (even handling multiple classes). The style of a quote, for example, could be translated into simple CSS that isn't changeable later.
I guess the task is not really to make the post in an email message look exactly like the post displayed in IPB where the look can be skin-able. The task is really to generate acceptable looking HTML messages. It might not be that hard to generate simplified HTML from the full HTML that the RTE will allow to be produced. Ironically, this is probably much easier to do when you stored all messages in the database using BBCodes. The translation to email format would be to just use different definitions for the BBCodes.
Another approach that might be easier for me is to replace the RTE Editor and associated HTML processing to use the RoundCube mail RTE Editor and HTML processing. RoundCube Mail is available as a framework for doing core processing so maybe taking their implementation for the RTE Editor and message body display could be easily adapted for 4.0. I would probably lose some of the more advanced features that the 4.0 RTE supports right out of the box like embedding YouTube videos, but maybe these could be added over time, if my users needed them.
I use both RoundCube and IPB. I like RoundCube's database config settings better than IPB. Specifically, I like being able to set the db to use for write operations separate from read operations. This helps greatly if you need to set up database replication (master/slaves). I also like the ability to assign some tables update on the slave only (like for cache tables or possibly session tables).
Here are the relevant RoundCube settings:
// SQL DATABASE
// Database connection string (DSN) for read+write operations
// Format (compatible with PEAR MDB2): db_provider://user:password@host/database
// Currently supported db_providers: mysql, pgsql, sqlite, mssql or sqlsrv
// For examples see http://pear.php.net/manual/en/package.database.mdb2.intro-dsn.php
// NOTE: for SQLite use absolute path: 'sqlite:////full/path/to/sqlite.db?mode=0646'
$config['db_dsnw'] = 'mysql://roundcube:@localhost/roundcubemail';
// Database DSN for read-only operations (if empty write database will be used)
// useful for database replication
$config['db_dsnr'] = '';
// Disable the use of already established dsnw connections for subsequent reads
$config['db_dsnw_noread'] = false;
// use persistent db-connections
// beware this will not "always" work as expected
// see: http://www.php.net/manual/en/features.persistent-connections.php
$config['db_persistent'] = false;
// you can define specific table (and sequence) names prefix
$config['db_prefix'] = '';
// Mapping of table names and connections to use for ALL operations.
// This can be used in a setup with replicated databases and a DB master
// where read/write access to cache tables should not go to master.
$config['db_table_dsn'] = array(
// 'cache' => 'r',
// 'cache_index' => 'r',
// 'cache_thread' => 'r',
// 'cache_messages' => 'r',
I have a use case for sending copies of forum content (posts) as email messages (with title being the subject and the post body being the message body). It would help if all posts stored in the database be able to be sent with the HTML and plain text versions and have the HTML version render properly in all modern email clients (Outlook, Thunderbird, OS X Mail, iOS Mail, etc.). This probably means that the HTML use inline styles that are compatible with most/all email clients and complex BBCodes like for embedding a YouTube use email compatible embed code (or just links to the video with a PNG shown representing the video).
Are the changes made to the RTE editor and HTML processing in 4.0 going to make it easier to send a WYSIWYG email for all content (posts)?
Or, am I going to have to hire a sharp programmer to make this hook for me?
I'd like to force my users to re-enter their password when they try to enter certain forums or forum categories for the first time in a session. Basically, some of my forums (including category forums) contain sensitive personal information that I'd like to protect from other people accessing this part of the board by accessing the user's computer when the user is away from their computer (similar to the way a "auto-lock screen" feature works on a computer except this is an "auto-lock sensitive areas" of my website).
So, I suggest an "auto-lock" attribute be settable on one or more forums/categories. The user would not be able to see the "last post info/posts summary" and view the topics/index for the locked forums without unlocking them globally (either through a global Un-Lock Locked Forums link or user attempting to view the forum or forum category. If the user clicks on a locked forum or the global unlock link, they should be presented with an unlock form to let them enter their password to unlock all locked forums. The forums would then be unlocked until they auto-lock (after X minutes of board inactivity) or they click on a Re-Lock global link (found somewhere on each page).