teraßyte

Hello, I'm Terabyte. I've used the Invision Community software from the early days of the free 1.x version, and I worked on countless free and paid modifications for every major version of it. I was also involved in several community projects, like the old IP.Shoutbox and IP.Tracker applications. From 2009 to 2012, I worked as a developer for IPS, Inc. (support, development, conversions, SSO, enterprise customers support). Then, from 2013 to 2021, I worked as a developer for a big site with more than 14 million posts using Invision Community (for which I also developed several custom complex applications & plugins). Now that the site's ownership has changed, I'm back to working as a freelance programmer. Some of the services I offer include: Installing & upgrading both Invision Community & Modifications. Legacy upgrades from older IP.Board versions (2.x/3.x/4.x). Developing applications & plugins (it doesn't matter if big or small). Compatibility updates for PHP 8. Conversions from other software. If needed, I can also develop custom conversion scripts for software IPS doesn't support out of the box. Support for simple theme changes & updates. Translating modifications from English to Italian. A service to keep your community updated with the monthly releases from IPS. Additional Tech support is also available. Investigating 3rd-party related issues. Helping move sites to another host. Helping with normal community management/setup tasks. You can contact me in both English and Italian. 😉

Parts of this entry may only apply to those who create hooks for IP.Board. Feel free to skip the sections that may not interest you. For IP.Board 3.2 I made several changes for both applications and hooks and now with this new major version I went ahead and made some more changes that I hope will simplify things for everyone. Applications Ordering Very often customers asked us for a simple way to reorder applications in the ACP, and subsequently in the front end, without having them split in 3 different categories (Root, IPS Addons and Third Party Addons) which for example prevented having the Blog link before the Forums one without having to manually modify the templates to add it. I am pleased to inform you that this is now possible without having to edit anything! This image shows the old layout with the split categories in IP.Board 3.2: While this one lets you see the new and updated layout in IP.Board 3.3: As you can see from the image above the System application (which is hidden for the front end) is always listed at the top but all the others can be re-ordered. Let's now take a look at the main navigation in the front end which properly displays the applications in our chosen order: Applications Status & Restrictions From the image above of the new layout you will have surely noticed that now the applications page has 2 tabs which list enabled and disabled applications, the disabled page looks exactly the same except for the first button which is a green plus to enable it opposed to the red cross in the enabled list. Note also that the uninstall button has been replaced with the enable/disable button and has been moved in the dropdown where the less used options are available, after all if you install an application on your community you want to keep it! Another change is the "Tab Restrictions" column which displays an icon to inform the admin that the front end tab may not show to some (or all) members depending on the chosen options: Application Details Unlike for hooks which already have a page to view all their details, applications had nothing and the list itself doesn't have any information about the application author, website and similar data. I have gone ahead and added a new view for that which lists most of the known information for the application: Hooks List For consistency with the new applications layout and the recent changes introduced in IP.Content the hooks listing now has two tabs to list enabled and disabled hooks while the old "Install a New Hook" tab is now replaced by a button which opens a modal popup to import the file: Hooks Settings Several hooks being released include new settings or whole new group settings but those settings are not always where you expect them. To help admins find those faster we have included a new link in the dropdown that takes you directly to the settings page once clicked. Since none of our default hooks add settings the example below is from one of the hooks I've released for free: Since hooks also support multiple groups or even individual settings in the image below as a test I have added a setting from the "Spam Prevention" group in IP.Board in the hook, as you can see both groups are now listed: Hooks Development Sometimes a developer might need to run code before allowing the admin to install or uninstall a specific hook, starting with IP.Board 3.3 this is possible adding the functions "pre_install" and "pre_uninstall" in the custom installation file. A simple example with the basic structure can be found below: <?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.

Parts of this entry may only apply to those who create applications for IP.Board. Feel free to skip the sections that may not interest you. In my last blog entry I mentioned the improvements we have made for the hooks system, in this new entry I'll talk about the changes we have made for applications. Disabling an Application When an application is disabled from the ACP a check is performed on all the enabled hooks that have it listed in their requirements and a warning will appear at the top of the page to warn the admin about disabling them. Application Tab Permissions We have received several requests from our customers in both the feedback forum and tickets and we decided to include it in IP.Board 3.2, you will now be able to specify for which groups the application tab will appear on the public side! The setting to control this is an easy multi-dropdown menu, furthermore we have renamed the setting "Hide Tab" to "Hide for all current and future groups?" and we have moved it under a new permissions tab. Global Caches As we have already mentioned for the hooks (see previous blog entry) we have added support for the "Global Caches" system in the applications too, this will allow modification developers to also specify for applications which additional caches should be loaded on each page together with the default ones. For example we will use this in our IP.Nexus application and specify the "nexus_ads" cache which is currently loaded separately on each page when the application is enabled. Updates Checker Unlike hooks the applications had no way to check for updates, we have now added 2 new settings "Website" and "Update URL" which are used in the same exact way as the one for the hooks (see the previous blog entry). The updates available will show as a purple badge similar to the ones for the hooks and a counter of the updates available will show up at the top of the page as well. Sphinx Cronjobs When Sphinx is enabled we often have customers confused on how to setup properly the cronjobs based on the applications installed. To solve this issue we have added a menu for the old Sphinx button which contains the new "Build Cronjobs" tool. This tool will ask you to input the path to your sphinx.conf file and will then provide the proper cronjobs based on the applications installed. Furthermore, the tool will also warn you about a possible wrong path as you can see in the screenshot below. Export Tool for Developers Currently the information.xml file included in the xml folder of each application needs to be written manually, we have now included a tool that allows developers to easily create such file from the ACP without having to write it manually. This is an example of the file that will be exported from the Members application: <?xml version="1.0" encoding="UTF-8"?> <information> <data> <name>Members</name> <public_name>Members</public_name> <author>Invision Power Services, Inc.</author> <description>Manage members and groups</description> <disabledatinstall>0</disabledatinstall> <global_caches/> <website/> <update_check/> <templategroups> <template match="exact">skin_messaging</template> <template match="exact">skin_mlist</template> <template match="exact">skin_online</template> <template match="exact">skin_profile</template> <template match="exact">skin_ucp</template> </templategroups> </data> </information> Please note that the option "disabledatinstall" will always be 0 by default unless a previous information.xml file is available and it contains a different value which will be retained. The same goes for the templates, you need to add them manually but as long as you have them in a previous xml file the export function will keep them in the new one as well. Conclusions As you can see from the previous screenshots we have not only added new features but also the layout of the pages has been updated as well for better usability, for example you'll notice that the applications not installed are now listed on a column on the right instead of at the bottom where it was harder to see them. 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. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

Parts of this entry may only apply to those who create hooks for IP.Board. Feel free to skip the sections that may not interest you. As mentioned in our previous blog entries about IP.Board 3.2 we are focusing not only on adding new features but also on improving some of the current areas as well. In this entry I'll talk about the changes we made for hooks. Global Caches Several times it might happen that a hook requires a specific cache on every page (like our IP.Chat hook "Chat Tab Count") but there was no way to do that apart from running a separate query on each page load. In IP.Board 3.2 we have added support in the hooks for a system called "Global Caches" which allows modders to specify a set of caches that the board will always load together with the default ones. Such caches can be selected in a new tab we have added in the hooks form and will help reduce the number of queries run. Hook Requirements Already in IP.Board 3.0 hooks had 4 requirements fields and nothing changed in 3.1: min/max PHP version and min/max IP.Board version. What if the hook was for a third party addon or even one of our official addons? Was that enough? We felt that the answer was no and thus we have implemented an enhanced applications requirements system. With the new system you can now specify any installed application as a requirement while creating a hook as well as the usual PHP version. Furthermore, you can specify a minimum and/or maximum version or leave both fields set to 0 to only require the application to be installed. In the example below the hook will require a PHP version between 5.3.0-5.3.5, a minimum IP.Board version of 3.1.1 and IP.Gallery installed. When installing a hook that doesn't meet the requirements, a warning badge will appear before the title and a count of all the warnings for enabled hooks will be shown as well above the list. Clicking on the warning badge will redirect you to the hook requirements page where each requirement has its own badge (ok / error) and as you can see the minimum PHP version requirement is not met. You will also see the same requirements page when trying to enable a hook already installed that doesn't meet the requirements. In this case however you'll have the option to skip the requirements check and still enable the hook regardless. Updates Checker The update checker for the hooks has been enhanced and now the code can retrieve an 'update url' as well if there is an update available, previously the system simply used the hook website value if one was provided but what if the site got moved or if the modder wants the admins to go to a specific url to get directly the update rather than viewing the main page of their site? In the old IP.Board 3.0 & 3.1 versions the update script simply returned a 0 value if there was no update or 1 for an update available, now if an update is available IP.Board will explode the string on the character | and take the second value in the array as the url. An example is available below: 1|http://www.google.it/ Additionally IP.Board 3.2 will now add also the IP.Board long version in the update URL together with the hook long version, in this way the update script can return only 1 for older versions or add also the new 'update url' variable for IP.Board 3.2+: IP.Board 3.1: http://www.domain.com/checkHookUpdate.php?hookKey=test_hook&version=10000 IP.Board 3.2: http://www.domain.com/checkHookUpdate.php?hookKey=test_hook&boardVersion=32000&version=10000 Install a New Hook As you may have already noticed from the screenshot above the "Install a New Hook" form is now a tab and you won't need to scroll down to the bottom of the page anymore, especially when you have a large list of hooks installed. Conclusion Many other small tweaks and optimizations have been implemented in the layout as you can see from the screenshots and also in the code, finally all the enhancements discussed above are available in the Hook Details page as well which contains a summary of everything concerning the hook. 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. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

As the entry title says, this blog entry describes changes and improvements to the hooks functionality in IP.Board, and is aimed mainly at modification authors. New Data hook access points Several new data hooks have been added for IP.Board and the addons. Here a list of the ones added in 3.1.3: IP.Board topicViewQuery: allows you to add new fields for the members table in the query, and add new joins when posts are retrieved from the database. This will allow you to select additional fields in the members table if you need to, or join in other database tables to retrieve additional information for your modification. The main use for this would be to retrieve additional data to show in the userInfoPane template. incrementUsersPostCount: several modifications need to execute code when the post count for a user is incremented (example: popular points modifications). This new data hook will allow you to do so. Add Calendar Event Edit Calendar Event Add New Blog Add Blog Entry: Entry Add Blog Entry: Poll Data Edit Blog Entry: Entry Data Edit Blog Entry: Added Poll Edit Blog Entry: Updated Poll Add Blog Entry Comment Edit Blog Entry Comment Add Download Edit Download Update Downloads Category Info Rebuild Downloads Statistics Cache Add Download Comment Edit Download Comment [*]IP.Calendar [*]IP.Blog [*]IP.Downloads The other applications, such as IP.Gallery, will all see new data hooks as well. Library hooks support In IP.Board 3.1.0, we introduced a new type of hook: Library Hooks. This hook type is a powerful tool for modification authors, allowing you to overload the libraries and extend virtually any function in the IP.Board code. Initially, the support for library hooks was limited and often times a class loaded from different areas of the code would sometimes load any library hooks associated with it, and sometimes would not; for IP.Board 3.1.3 we have added support for them in a lot more areas of the code. All of our addon applications have been updated to use them too! While IP.Board 3.1.3 is a major improvement in terms of library hook support, we will continue working on implementing the library hook support throughout all of IP.Board, with the expectation that IP.Board 3.2 will support library hooks in 100% of locations that can utilize them. New function IPSLib::loadActionOverloader() Action overloaders are usually executed automatically by the code but unfortunately that happens only when those classes are executed directly; when those classes are loaded and executed manually like in the code below the overload doesn't apply: require_once( IPSLib::getAppDir('core') . '/modules_admin/languages/manage_languages.php' ); $langLib = new admin_core_languages_manage_languages( $this->registry ); To resolve this issue, we have added a new function in IPSLib that works similarly to IPSLib::loadLibrary(). This function however accepts only 2 parameters: the first one is the path to the file itself while the second parameter is the class you are overloading. This is an example based on the code above: $classToLoad = IPSLib::loadActionOverloader( IPSLib::getAppDir('core') . '/modules_admin/languages/manage_languages.php', 'admin_core_languages_manage_languages' ); $langLib = new $classToLoad( $this->registry ); Support for usercpFormsExt plugin dropped Starting with IP.Board 3.1.3, we have discontinued support for the plugin usercpFormsExt.php. This is a plugin that we introduced in the 3.0 version of IP.Board to extend the user control panel tabs when library hooks didn't exist. It has now been replaced with a much more flexible library hook that allows for infinite extensions and you won't even need to upload a file as everything is done with a simple hook. If any developers were using this functionality, be sure to update your code to use the new library hook method. This below is the current code in the public_core_usercp_manualResolver class, for reference: //----------------------------------------- // Begin initilization routine for extension //----------------------------------------- $classToLoad = IPSLib::loadLibrary( $EXT_DIR . '/usercpForms.php', 'usercpForms_' . $_TAB, $_TAB ); $usercp_module = new $classToLoad(); We appreciate the feedback of our developers, and hope that these small changes make it easier to extend IP.Board and create useful and creative addons for our products.