It's pretty funny actually how people get so worked up. If you actually pause and look at 3.2 compared to 3.1 you will see that, while there are new features, most of what you see in 3.2 is the same stuff in 3.1 just presented better.
I assume what people are all :frantics: about when comparing to Facebook is the "Like This" button on posts? Well that is just the same old reputation feature as in 3.1 in a "like" mode where instead of the +/- buttons you get a button that says "Like This" which is hardly worthy of dire predictions in my opinion. Also, as it's what the masses expect, it will be used way more than the +/- reputation. It already has on this forum by the very people moaning about all the "oh it's like Facebook" features:
Yes, we have added some "social network" sort of features because our clients asked us to it's what the general public expect. However, we are not forcing anything on anyone. If, for some reason, you loathe the idea of people being able to like things, share content, comment on each others profiles, etc. on your community you can certainly shut those features off in the AdminCP.
The fact that an email address is revealed is clearly disclosed before purchase.
It is only shown on PAID files and ONLY if you actually buy that file.
Only the author of the file can access it, with permission, via a special API.
If the author abuses that privilege their access to the Marketplace will be revoked.
If you are not comfortable for some reason with any of the above do not purchase files from the Marketplace.
So you trust us that we don't put backdoors, trojans, or other malicious stuff into our modifications that could break (or delete) your forum (I know the Marketplace moderators will spot that now2), but you are afraid that we're going to "spam" your email with upcoming products and updates, or sell it to a 3rd party?
The API is only available to authors of paid files in the Marketplace. Seeing as you are purchasing something from them it seems logical that they may need to contact you for update announcements, technical support, etc.
Before you purchase the file it clearly states on the download disclaimer that your email address will be revealed to the author if, and only if, you actually click purchase, go to PayPal, and submit payment. If you do not wish to reveal your email address then do not complete that process. To your point about permission: by completing the payment process you are giving permission.
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.
I figured I'd post a few ideas/concepts that my members love (might give you guys ideas for new 3.2 design).
Obviously I can't know what you've already done in regards to the redesign but I thought I'd share these ideas anyway :).
Member List (sorting)
Similar concept for user control panel " alt="" class="ipsImage" width="1000" height="513">
The icon shows for the active "tab". In this case "Settings".
Also applies for search results " alt="" class="ipsImage" width="1000" height="239">
Also, I keep redoing this everytime I make a new skin, but can you please condense the moderation bar at the bottom of topics? Here is what mine looks like now: " alt="" class="ipsImage" width="1000" height="568">
Anyway, it's just an idea. My members think it looks infinitely better than the tabs, so I figured there would be no harm in passing along the concept :).
Our average ticket response time is well under 24 hours, however we just released 3.1.2 last week and as we offer free upgrades for our customers, we are generally busier immediately after a release with the additional workload (coupled with discovering, diagnosing and troubleshooting any new bugs that may be found).
Our SLA guarantees a response in 2 business days, so you should definitely get a response today (provided your ticket is not in a department where it can take longer to resolve the problem).
Have been noticing more and more lately that stuff is going on, gallery comments, blogs and comments, download comments etc etc etc but people don't realise. I know we have the view new content but is there any way in the future of making it more "in their face" for want of a better expression