Jump to content


Olivier Turbis

Member Since 04 Mar 2008
Offline Last Active Dec 10 2011 04:58 PM
****-

#2117246 Suggestion! in the features

Posted Charles on 04 June 2011 - 06:01 AM

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:

Posted Image

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.


#2114767 Suggestion! in the features

Posted ørret on 28 May 2011 - 05:37 PM

This thread made me lol.


#2114656 Suggestion! in the features

Posted Troy Spiral on 28 May 2011 - 09:51 AM

Differentiating Forums from "blogs/diaries" needs to stay on point, otherwise, I'm afraid IPB will just become irrelevant.  Facebook will win that battle.


#2116888 Complete the Suite Promotion

Posted IPS News on 03 June 2011 - 01:15 PM

Complete the Suite is back!

Our most popular promotion ever, Complete the Suite, is back to welcome the preview of IP.Board 3.2!

Complete the Suite promotion is specifically for our loyal, existing customers. This promotion will allow you to fill in the gaps in your IPS community suite licenses at a discounted price.

Anyone with a current, active IP.Board license (Standard/Business/Perpetual/Lifetime) will be able to purchase the following applications at the reduced price listed:
  • IP.Gallery: $64.99 ... $35
  • IP.Blog: $49.99 ... $35
  • IP.Downloads: $49.99 ... $35
  • IP.Content: $49.99 ... $35
  • IP.Nexus: $74.99 ... $55
That's a total possible savings of $94.95!

Do you already have IP.Board and IP.Gallery but always wanted IP.Blog? Now is the time to purchase IP.Blog at a discounted price. Perhaps you have everything except IP.Content and are ready to power your whole web site with the IPS suite? Perfect time to give it a try! Maybe it's time to try to monetize your community with our IP.Nexus commerce system.

To order: login to the client area, and click the green New Purchase button in the upper right. If you qualify, the discounted prices will show.

Act fast! This promotion ends June 17, 2011.


#2115848 Resources

Posted bfarber on 01 June 2011 - 10:28 AM

Just a quick observation, when you switch software initially, search engine spiders generally have to reindex your entire website.  This can often cause temporary higher-than-normal loads because you're getting much more traffic than normal (on top of the fact that nothing is cached for your users - e.g. images, css, javascript).


#2110682 IPS, why do you want to disclose our emails?

Posted Mat B on 13 May 2011 - 06:42 AM

View PostCallieJo, on 13 May 2011 - 05:15 AM, said:

I look at the forum threads for updates or the author's site if it's an important mod. However, why can't there be a system like vb.org where you get an email notification sent from vb.org's site each time there is an update to a mod?
It could be documented better, but you can achieve this by visiting the mod's download page and clicking "Like".  You will then receive an email (or PM, or mobile push notification) when it is updated.


#2051769 IPS, why do you want to disclose our emails?

Posted Breadfan on 04 December 2010 - 11:50 AM

This whoie discussion feels like a...

Posted Image


#2049892 IPS, why do you want to disclose our emails?

Posted Mark on 30 November 2010 - 11:39 AM

If you choose to ignore the disclaimer, you can't really complain that we didn't tell you something that was in them ;)


#2049884 IPS, why do you want to disclose our emails?

Posted Charles on 30 November 2010 - 11:24 AM

People "tend" not to read any disclaimer with or without without a scroll bar :)

Comes down to the fact that we aren't hiding this information, it's just an email address, and it's only for paid files that you buy. All seems quite reasonable to me.


#2046931 IPS, why do you want to disclose our emails?

Posted Charles on 23 November 2010 - 04:44 PM

To clarify:

  • 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.


#2046925 IPS, why do you want to disclose our emails?

Posted Martin A. on 23 November 2010 - 04:40 PM

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?


#2046746 IPS, why do you want to disclose our emails?

Posted bfarber on 23 November 2010 - 11:20 AM

Just keep in mind...if we weren't acting as the middleman, and you purchased the file directly from the author, they'd get your email address (the one you use for PayPal) anyways. :)


#2046658 IPS, why do you want to disclose our emails?

Posted Charles on 23 November 2010 - 08:36 AM

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.


#2108545 iPB 3.2.0

Posted Black-Elmo on 06 May 2011 - 04:34 AM

As mentioned in a previous blog entry the AdminCP is receiving a lot of improvements in the translation area.


#2092911 What's new in IP.Board 3.2.0 and related Apps (so far)

Posted Charles on 20 March 2011 - 01:55 PM

Performance Improvements
  • 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.inv...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.
  • Hooks Improvements: http://community.inv...s-improvements/
  • Applications Improvements: http://community.inv...s-improvements/
  • 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.