An even better option than resizing on the server is resizing on the workstation BEFORE the upload using an uploader like plupload. Spent some time making a case for it and Matt said () he would strongly consider it in an update. :)
I like the idea of the Google custom search option too, it offloads a lot of the search load and gives you a bit of income via ads for search as well.
I think it's nice to have the "Tagging & Prefixes" under one roof, but where it falls is that you may only want certain prefix's available... for example:
Classifieds Forum - Only Available Prefixes - "For Sale", "For Rent", "Looking For" etc etc - Hyperphetically speaking I may only want these, I would not want people to be able to start a forum with "Apple", "Gaddafi" or "Pear" etc etc - not good...and irrelevant..
Can I suggest Prefixes have some control/definible per Forum/category basis please?
Reduced several cache-load queries on the ACP index page
Combined two permissions queries loaded on every ACP page into one
Added some additional cache-loading calls to other ACP pages (manage applications, manage hooks, manage members)
Added some caching for fetching the max version ID in the upgrade_history table, which reduces the number of queries on the ACP manage applications page by the number of applications installed
Changed how modules are grabbed when IN_DEV is enabled for menu building (runs one query instead of one query per application)
class_forums was getting loaded and initialized twice in the Manage Forums page - fixed so it's not reloaded a second time. Also removed a shortcut for the class in the manage forums file to reduce small amount of overhead/memory.
Removed a query for group data on Manage Forums page (group_cache is already loaded, so used that instead)
Removed several deprecated functions, reducing the size of some classes and reducing their resulting overhead
Edited language export routine (for IN_DEV mode) so that it only exports the data we absolutely need. This reduces the size of our language XML files significantly, and also reduces memory overhead needed to process the language XML files.
Index added on ibf_posts.post_parent to speed up certain update queries that previously required a full table scan
A lot of unused code in the friend management files has been removed
Avatar or profile photo cleanup tools in ACP were unnecessarily loading and instantiating upload class
Removed outdated/non-functional coloring in admin logs
Calendar has been rewritten, and much unused code has been removed.
Caches used by calendar were not being properly loaded at runtime
Changed most of the file_exists call in the code with is_file for a faster code execution
The bbcode cache now uses the ‘bbcode_tag’ field as array key instead of an incremental integer, that allows a faster data access for single bbcode tags as there is no need to scan the whole array with a foreach.
An unnecessary query has been removed from the forum index view (the query used to verify the name used for the friendly URL is correct)
Removed unnecessary query from report center report view
A cached used by report center was being queried separately instead of at page initiation
Report center plugins are now cached for quicker runtime lookup without having to query the database
Useless queries removed from report center
Some queries that selected all rows and counted them (instead of running COUNT style queries) were changed to be better optimized
ACP skin files previously extended the output class unnecessarily. This was removed, resulting in approximately 20KB or more memory savings in each ACP page.
Report center plugins are now cached for quicker runtime lookup without having to query the database
RSS import now is much faster on boards with lots of feeds setup in the ACP.
overWrite header query / method_exists moved from every page load and value is cached in app_cache
Developer-Oriented Changes Changes that may impact resource authors and skinners (including removed functions, database changes, new hooks, etc.)
$this->DB->force_data_type has been removed. Mod authors should now call $this->DB->setDataType( $column, $type ) instead.
$this->DB->no_escape_fields has been hidden. You should use the available $this->DB->preventAddSlashes( array( 'col' => 1 ) ); syntax instead.
Login management custom configurations have moved to database handling. conf.php (or conf.dist.php) files are no longer needed (though acp.php still is).
search_results, sessions.location, and cache_store.cs_extra are all removed
If you have a findIpAddress extension you can now add an array of additional columns to pull from your table as the fourth array member. i.e. "'posts' => array( 'author_id', 'ip_address', 'post_date', array( 'pid' ) ),"
IPB will now do a better job of cleaning up centralized application data during uninstall, so applications don't have to do it manually. (http://community.invisionpower.com/tracker/issue-25956-attachements-in-support-ticket/)
The way hook data to-be-exported is stored has changed. This should have minimal impact on developers as the upgrade routine will update it for developers. This should make working with hooks between multiple developers easier, and make hooks import, export, install and uninstall in a much more consistent manner whether IN_DEV is on or not.
Many skin system bugs have been resolved, and improvements implemented, making the skin system more flexible to developers using it outside of normal contexts, while allowing it to be more forgiving of various formatting possibilities (i.e. typehinting for function parameters and spacing around function parameter definitions).
Central permission management now correctly can handle more than one permission type within a single application
IPv6 is now supported. You should ensure any database columns holding IP addresses are varchar(46) or larger.
You should use the new ipsRegistry::getAppClass( $app ); call to load your app_class_(application).php class. This ensures any library hooks execute as appropriate and consolidates duplicative code.
You should use the new constants IPS_FILE_PERMISSION / IPS_FOLDER_PERMISSION for file and folder permission values. i.e. instead of chmod( $file, 0777 ); use chmod( $file, IPS_FILE_PERMISSION ); instead.
Calendar has been completely rewritten - the DB schema has changed, dates are stored as datetime parts in MySQL, etc.
The ACP has a new interface implemented, some of the JS has changed, jQuery is now supported in the ACP
Removed 4 data hooks in public_forums_forums_topics: topicViewTopicData, topicViewDisplayData, topicViewForumData, topicViewPostData. All 4 of them can be replaced with a simple skin overloader for the template "skin_topic > topicViewTemplate".
Photos and avatars have been merged.
Photos thumbs are now cropped at 100px and you can select which area to crop
Twitter / Facebook photos are actually imported and re-sized where possible (needs fopen URL wrappers otherwise the thumb URL for the services is used)
Some functionality for importing/exporting/rebuilding from and to XML files has been hidden unless IN_DEV mode is enabled
Added a second parameter for the function “$this→cache→getCache( $CACHE_KEY, FALSE );” which allows to skip the loading from the database if the cache isn’t loaded already.
A new option to define an application when creating an hook, if the application is filled the code checks if it is enabled and if not skips loading the hook file completely.
class_forums::fetchTopicFolderIcon() has been changed to return an array of meta-data about the topic that can be used to generate the topic icon, although Rikki is changing how topic icons work in general anyways.
pp_*thumb*_x is now pp_*small*_x
The sessions API (admin/sources/classes/session/api.php) now supports a different cutoff time rather than the default one, additional joins, ‘where’ query bits, complete ‘where’ query part override.
The function “IPSLib::unpackGroup()” now is “IPSMember::unpackGroup()”.
ACP group_form.php plugins now support an optional third method: postSave(). This method accepts one parameter (the group ID), is only called if present, is called after the rest of the group data is saved, and should not return anything.
Added a getCount() method to the like class to return just the number of followers
The setting disable_reportpost has been removed. Our applications now check the report center permissions directly, instead.
A new extensions file per-app is supported: permissionsSync.php. Class name should be “(app)PermissionsSync” and supports a constructor (ipsRegistry reference passed) and one method with no arguments: updatePermissions(). This method can be used to rebuild application caches when the app permissions have been updated from the central permission manager.
Deprecated function getBlogID() in the blog API has been removed, developers will need to use the more updated function fetchBlogIds()
makeProfileLink, memberViewImages, makePassword, makeNameFormatted, canReceiveMobileNotifications have been moved to IPSMember
unconvertSmilies has been moved to IPSText. The redirect method in the bbcode class has been removed.
The “doneScreen” method in the admin output class has been entirely removed. Authors are encouraged to use the global_message/silentRedirectWithMessage() methodology instead.
The “redirect” method in the admin output class now simply routes to silentRedirectWithMessage(), and is marked deprecated.
The template “global_main_wrapper_no_furniture” has been removed from the admin skin.
Function “rebuildSphinxConfig” has been moved from “IPSLib” to “admin_core_applications_applications”
classCommunication.php was removed, and classFileManagement.php was extended to handle POST requests (encompassing the only functionality missing compared to classCommunication.php)
Almost all private methods have been switched to protected to allow more robust hook capabilities
New pagination potions to use a next/previous style pagination. Next/previous style pagination supports AJAX pagination.
The column “ban_nocache” has been removed from the “banfilters” table.
New adminOutput method setMessage() has been added. Allows to set the global_message, and allows to specify a “sticky” flag or not.
ACP Settings are now in their own “settings” module and the templates have been moved as well in “cp_skin_settings”.
menu.xml files for ACP modules now support specifying a language key, which can then be placed into “(app)_admin_menulang.php” as “menu__(language_key)” to support menu language abstraction in the ACP. This is optional for apps.
Just to remind you guys from IPS, don't forget of LANGUAGE SYSTEM in IP.Board 3.2.0. As you all know, this is an issue since 3.0.0!
The current language system fails when you use more than 1 language and translate the apps!
Example: if I use English and Brazilian Portuguese (or any other foreigner language) and use any app (Gallery, Download, Blog, third-party add-ons (tutorials, ticket system, etc) ), when you translate those apps and upload the XML, now you got both languages sets using the same translated files (XML), when should translate only one!
You need to find a way to make the translation update only one!
GOT IT! I've spent the past 4 hours straight playing with a few different hook types and setups and templates, and building a custom query to get the current statuses (since IPB doesn't hold them conveniently in the on-hand memberData since 3.1), and I think I've got the entire hook EDIT-FREE! Including both placement options. :) And only the 1 extra query per topic, and thats only if you have it set to Current Status and not Post Status.
No time to finalize, but expect it this weekend once I'm done testing and am comfortable with it.
Disable members of this group from editing their signatures?
Yes/No until (approved posts)
Enter 0 or leave blank in second field to not limit by days/posts
Maximum number of images users in this group can add to their signature
Maximum dimensions of images users in this group can use in their signature Max Width (px): Max Height (px):
Maximum number of urls users in this group can add to their signature
Maximum number of lines users in this group can use in their signature
I'd recommend adding an optional coice of adding a custom site google search when using ADVANCED search function. Find some nice way to introduce that google search. search is not the strongest part of IPB, so I think its fair that google search should be utilized.
Now I'm just getting around to realizing that you also can't move (or merge) topics found in the Report Center, except by clicking through them one by one - worse, after you click through the first link, you have to click a second link, "This report is regarding..." to get to the actual topic and move it.
Seriously, who made the executive decision that at every opportunity we will make it impossible for administrators/moderators to move topics en masse? I've got admins up at arms because they hate that I made the switch from SMF to IPB and I'm spending a lot of time defending the decision, and then I run into things like this that just don't make a lot of good sense to me, because these kinds of features just seem like basic good functionality that any forum software should have. Will someone please tell me that this is something that's going to be addressed in a very near-future release?
I've looked and haven't been able to find any addons/hooks that will allow this. If anyone knows of one and can point me to it, I'd appreciate it.
calendar improvements are needed as the present calendar is very basic and overlooked on upgrades
just something i would like to see is....
when theres an event in the calendar, the date highlighted and to be able to hover over the
date and see a popup preview of the event on that day.
The option would be very useful when shown as side block on the main index.
We occasionally get a database error once in a blue moon. We run a >3Gb database and sometimes tables like ibf_core_markers can be left locked in use by mysql. It's a simple fix to just flag a repair in phpmyadmin.
When IPB gets errors and puts up the database error page saying "there appears to be an error with the database" it'd be real nice if it booted a lossless automatic check/repair routine.
Here's the example error page: http://img403.imageshack.us/i/arnieserror.jpg/
Would it be possible in a future IPB release to tie the error page to a simple automated check/repair mysql system? In the case of simple errors the forum could fix things, log it and email the admins. In the case of more serious errors it could email the admins to let them know the board had a DB error. Obviously I'm talking about a lossless mysql check/repair routine here that'd clear simple things like locked tables etc.
Facebook has updated its Registration plug-in for developers to help streamline the way users can sign up for accounts on a site and connect those accounts with Facebook.
I really hope that IPB adds support for this feature soon. I think this is a much better way to register rather than having people "login with facebook" and trying to auto-create the account using the facebook info. Using this method the new member will clearly know what information is being copied into your website and we can easily request extra information to be requested from the user in a single form.
Any chance we will see an update to IPB soon that incorporates this updated registration method?
I haven't been following this board much recently, so let me know if this has already been discussed or implemented. I'm really anxious to have this support for a site I'm working on currently.
There is nothing I've seen in XenForo that's evolutionary or ground breaking in terms of what a Forum/community package can do.. Not to mention IPS has been making relatively steady strides to all of their package NOT just IP.Board
I'm not 100% sure what changes we will see in 3.2 for language management just yet, however I know the language manager needs a good bit of work still. It's on my todo list, I just can't say yet when we'll get to it.