• Experience in iOS and Android development (Windows phone a plus)
• Working knowledge of IPS community suite software
• Examples of previous application development
  

• Working knowledge of SVN or similar revision control systems
• Self-starter who can take a project plan and make it a reality
• Ability to work with a team toward a larger goal
• Time management skills to be able to deliver a goal on time
  

• Allow user modifications
• Allow comments
• Database open
• Allow ratings
  

• Hundreds of language string and verbiage changes have been made to provide a more consistent experience.
• Cancel buttons have been added to all forms to allow you to more easily 'cancel' your action without having to rely on browser navigation or other page links.
• Cancel buttons displaying in the "action bar" at the top of the page have been removed, and instead moved to the bottom of all forms.
• The navigation bar entries on every single page have been reviewed to ensure they provide correct, reliable and expected navigational breadcrumbs.
• Add folder/Add category buttons throughout the ACP now show the form inside a modal box. Previously, some pages used a modal box while some of these buttons would take you to a new page to supply the category/folder title.
• Minor styling inconsistencies have been resolved, ensuring the interface looks the same no matter where you are.
• A button to jump to the 'Manage Moderators' page has been added to the database field/category/record pages. The same jump bar has been added to the manage moderators page, allowing you to easily jump back to the record/field/category management pages.
• Dropdown menus used when creating blocks have been changed to radio buttons. This allows you to more quickly see all of the available options without having to open the dropdown and close it to confirm the option you have selected is the one you want.
• On the Databases page (where your databases are listed), the name will now take you to the edit database form. This is much more consistent with the rest of the IP.Content (and IP.Board) ACP interface. The number of records and fields are now links to take you to those pages, respectively. Additionally, the number of categories and moderators are now shown, also linking you to their respective pages for thatspecific database.
• Codepress as an editor option has been removed. The javascript editor has not been updated in several years and no longer works with current modern browsers, so we have decided to drop it as an option. Having an option that doesn't work is worse than not having the option at all.
  

<?php

class myHookSetup

{

public function __construct( ipsRegistry $registry )

{

  // Your constructor code here

}


public function pre_install()

{

  //This is run BEFORE the hook is installed on the board, nothing is added in the database or in the files yet

}


public function install()

{

  //This is run AFTER the hook is installed on the board

}


public function pre_uninstall()

{

  //This is run BEFORE the hook is unistalled from the board, nothing is changed/removed in the database or in the files yet

}


public function uninstall()

{

  //This is run AFTER the hook is unistalled from the board

}

}

Furthermore to make development of hooks easier the requirements page now provides an easy-to-use dropdown menu with the versions of the chosen application, there is no need anymore to search manually in the XML files the ID for the version you want to specify!




Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum.

• Unapprove
• Delete
  
• Remove from View (Soft Delete)
• Delete from topic (Hard Delete)

• Edit
• Hide
• Delete
  

• In reviewing feedback and requests, many customers seemingly did not even realize the template tag help feature was available. They had overlooked the buttons, causing them to miss this extremely valuable feature.
• The styling of the help was inconsistent with the rest of the ACP
• There was inline help and advanced help available. The advanced help showed descriptions and additional information about the inline help tags, but was otherwise duplicative of the existing inline help panel.
• The database help always opened a popup and often felt clunky in real-world use.
  

• You can effectively lock older topics to prevent confusing 'bumps' or replies after a few years
• Free up your forum post table so it runs speedy again by giving MySQL less old data to have to work with all the time
• Use a remote server to house the archives so it can freely grow over the years
• Get a 30% reduction in SQL usage when viewing archived topics which is great news if you get a lot of good search engine placement.
• Quick and easy to configure
• Archives are done via a task that runs at regular intervals. It does a small number of posts each execution to prevent timeouts.
• It doesn't confuse search engines as the title and URL don't change (and even the H1 tag doesn't change).
  

• Control. Many administrators prefer to have more control over the way moderation happens on their communities. You may want the first time a user is warned to always be a verbal warning only; you may then want to the second warning to always be a 1 day suspension, etc.; you may want different punishments for different infractions. Or perhaps you want to allow your moderators to choose punishments themselves as they do currently. We wanted the warning system to be able to handle both of these setups so you can be as fixed or as flexible as you like.
• Communication. At the moment, if a moderator gives a member a warning, no other moderators know about it unless they happen to be looking at a member's warn logs. We wanted communication between the system and the moderators to be better. Moderators should be able to know when a member is warned. They should be able to see who warned them, why, and what post caused the warning. They should know looking at a member's profile if they're currently serving out a punishment for a warning, and if so, which warning.
• Clarity. If a member is warned, they need to know why and what the punishment is. They shouldn't be put on mod queue and not know about it and then wonder why their posts aren't showing up.
  

• Moderation queue - all posts the user submits must be approved by a moderator before they are shown.
• Restricted from posting - the user cannot post at all.
• Suspension - the user cannot access any area of the community at all.
  

• The link backs to the content from the warning log, wherever that is.
• The red icon within the content if a warning has been issued for it.
• Honouring of the punishments given - moderation queue and restricted from posting.
• The message showing above the editor if on moderation queue.
• Prompting the user to acknowledge warnings before posting.
  

• Consistency helps users better understand how the software works, and learn how to use it quicker
• Better use of framework functionality will improve moderation and administration of the software
• Expanded use of built in functionality of IP.Board will allow you and your users to utilize more features in the software
  

• The selector separates out global albums from member albums.
• You can also search for albums which is great if you're performing moderation tasks.
• You can quickly select from recently selected albums easily.
• It is context sensitive and displays only albums available for the task you're performing.
  

• Forum topics
• Blog entries
• Gallery images
• Downloads files
• Content articles
• Nexus products
• Calendar entries
  

• Screenshots stored on a remote FTP server
• Screenshots stored in the database
• Screenshots stored in a folder that is not web-accessible
• Full-sized screenshots, as we need to apply the copyright stamp or watermark if configured (and cannot apply this to the actual image file, in case you wish to rebuild thumbnails later, or change your watermark image, etc.)
  

• IPSMember::unpackGroup()
• IPSMember::makeProfileLink()
• IPSLib::getEnabledApplications()
• IPSMember::setUpModerator()
  

• We found some various array checks in the output class that were unnecessary, as the array was a class property and initialized when the class was instantiated into an object.
• We were parsing some dates in the search results area twice, when we only need to do so once.
• We were parsing the post content in search results, even when we displayed the results as topics. Parsing post content is an expensive operation, so this unnecessary operation was particularly wasteful.
• We found that one particular IP.SEO hook is outdated and provides no benefit as of 3.2.0. This will be investigated (and potentially removed) with the next release of IP.SEO: http://community.inv...topiclinks-hook
• Several operations were running when displaying a mini-calendar which were unnecessary (because the results were never displayed in the skin).
• The IP.Downloads board index latest files hook was loading the category helper class twice, unnecessarily. Similarly, some of the functions within this class were called multiple times, unnecessarily.
• IP.Downloads was utilizing an unnecessary "GROUP BY" SQL clause. Generally, this requires a temp table to be created, and in this case it was unnecessary.
• The UCP Manage Attachments page queries for attachments even if it discovers there are none (through the SELECT COUNT(*)... query that is first run). We removed this second query when there are no attachments to retrieve.