Jump to content
View in the app

A better way to browse. Learn more.
Invision Community

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Invision Community Blog

Show all categories

IP.Board 3.1.0 Dev Update: View Reputation

In IP.Board 3.0 we introduced a simple reputation feature, allowing users to give positive or negative reputation to a post.
While administrators can view who gave reputation through the Admin CP, in IP.Board 3.1 we have introduced a way for all users to view who gave reputation on any given post.

To view who gave reputation, you just click on the reputation number at the bottom of the post which will now display a popup balloon indicating who has given reputation.


There is a per-group setting to control who can use this feature. If a user does not have permission to use it, the number will not be clickable and appear unchanged from how it currently is.

The data is loaded through an AJAX call when the link is clicked, so there is no additional queries to the topic view for this feature.
  • 12,089 views
Mark

IP.Board 3.1.0 Dev Update: Profile Customization (II)

We recently blogged about our new profile customization options. I've made a few updates since and wanted to update you on them.

As you may already be aware, we have added Twitter integration into IP.Board 3.1. This enables you to 'connect' your Twitter account to your forum account to share links, status updates and to allow you to use your Twitter photo on the board.

I've taken this a step further and added an option to allow you to import your Twitter background preferences to your profile:


My test Twitter account with using a different Twitter theme


The background preferences (img and color) imported into IP.Board


The preferences control panel

I've also added a few handy links to the Profile Customization control panel. These links allow you to revert all customizations, remove just the background image and load your profile to see the changes:



I've also included a quick way to remove your own customizations while viewing your profile:



And if you are a "Super Moderator", then you remove and remove and disable customizations on any profile you view:



We hope that you enjoy this feature and allowing Twitter to set your background further personalizes your board profile and re-enforces your own personal brand.
  • 15,470 views
Matt

Demo System Term Extended

While not a particular interesting blog entry :) I wanted anyone interested to know that our demo service term has been extended from 24 to 48 hours. As always, you can email sales for a further extension if you might need more time.

If you are considering using IP.Board now is a great time to get your proverbial feet wet on version 3.0.5 so you are ready as soon as the upcoming version 3.1 is released! If you have any questions, feel free to email [email protected] to speak to our sales staff or post in our pre-sales forum for friendly help from the community.
  • 3,838 views
Charles

IP.Board 3.1.0 Dev Update: Topic Preview

We read virtually every piece of feedback we receive, even if we don't reply and we often see the same requests coming up. The ability to 'preview' the topic by viewing an excerpt from the first post is often requested and we've added this into IP.Board 3.1.

We've made it a little more useful by also including the last time you read a topic (if applicable) and the number of unread posts so you can quickly review how much activity has taken place since you last read the topic.



When you 'mouse over' a topic entry, you'll see a little 'pop-up' icon. Clicking this loads an excerpt from the first post along with some data underneath. This is very useful for moderators who can quickly review un-approved topics and well as being useful for normal members who can quickly decide whether they want to open the topic or not.

Technical Details:
- Icon appears for moderators / admins and normal members. If there are no moderator tools, it shows on its own.
- When you mouse over the cell, the icon is "faded" until you mouse over the actual icon.
- Data is loaded via Ajax to reduce mark-up required in the templates.
- The post excerpt is stripped of all BBCode and mark-up to prevent it breaking out of the pop-up.

This feature adds a little more functionality and polish to the forum index allowing you to perform your daily routine a little quicker and a little easier.
  • 15,871 views
Matt

IP.Board 3.1.0 Dev Update: Profile Customization

The IP.Board 2 series introduced a number of new profile features designed to make your profile page a little more interactive. Besides the usual stats and figures, we introduced a personal photo and the ability to leave comments and list recent visitors. This made your profile page a little more personal and encouraged repeat visits.

With the status updates feature in IP.Board 3.1, the profile page is becoming increasingly like a little user portal. With that in mind, we've extended the personalization options to include profile page background customization. You can allow your members permission to add a new background image or change the background color which instantly changes the feel of the page.

Here's an example of my own profile:


I've chosen a beach scene, so I've not tiled the image. This allows the image to not repeat and remain 'fixed' so that when you scroll, the background doesn't scroll with it.

You'll note a new menu item in the User Control Panel:


Naturally, you as the administrator can control which groups have permission to do this:


When the user adds a profile background, the margins on the profile page increase so you can see the background image. If the user doesn't have a background image set, the profile appears as normal with minimal padding. You can adjust this by editing the profile page CSS as normal via the Admin CP.

The profile page has undergone a few tweaks to make it a little neater. We've moved all the user's information into the left hand bar leaving more space to the right for other data such as the status updates, etc. We plan to develop user customization further in future releases.

Technical Notes:
- Group settings to enable / allow uploads / allow URL images / maximum upload size
- Ability to disable on a per-user basis
- Ability to tile an image, or to fix it (background-repeat: no-repeat; background-attachment: fixed)
  • 19,389 views
Matt

IP.Content 2.0 Dev Update: Friendly URLs for Databases

IP.Content is a complex framework that allows you to create and manage website content in many different ways. You can embed blocks and databases into pages, and pages can be wrapped by templates. You can define page names and use friendly URLs through the IP.Board built-in FURL system, you can use friendly URL's through the included index.php file with IP.Content (for instance, if you want your website in the root of your domain, and the forums in a subfolder), or you can optionally not use friendly URLs at all. Because of the many configuration options, and the fact that you are already embedding a database within another friendly URL system of sorts (given that you define the filename of your page already), friendly URLs were not supported in IP.Content 1.


They will be in 2.x, however.


We have added support for databases in IP.Content 2.x to utilize friendly URLs. To make use of this support, you will need to be using an existing friendly URL method (accessing IP.Content through the included index.php file, or using IP.Board friendly URLs).

The index page of a database lists the categories contained within the database, and is accessed by accessing the page the database is embedded on. For example, if you embed your database on a page called "database.html", then you may access your category index page at



http://domain.com/database.html

In IP.Content 1.x, if you clicked on a category from this page, you would see a URL similar to the following



http://domain.com/database.html?category=1

Arguably, the URL is still "friendly", but "?category=1" doesn't really tell you much about the link you are clicking on. In IP.Content 2.x, you will now define the friendly URL name for the category by editing the category in the ACP. The upgrade process will automatically set a friendly URL name for your categories based on the category title, but you have free-reign to go back through and set the categories to be accessed as a different name if you wish. If I set the category 1 friendly URL title to be "ipb-rocks" for instance, the URL to the category is now



http://domain.com/database.html/_/ipb-rocks

Because categories are defined by administrators and we are able to do error checking while saving your category configurations, categories do not require any additional information in the URL (such as the category ID).

This page will list the records stored in the category. In IP.Content 1 those records would be accessed as follows:



http://domain.com/database.html?record=1

Again, this isn't unfriendly, but we can do a little better. Similar to topics in the forums, records will automatically inherit their title based on the specified title for the record. For instance, if the record title is "IP.Content is cool!", it will be automatically rewritten to the following URL



http://domain.com/database.html/_/ipb-rocks/ipcontent-is-cool-r1

In this instance, because titles can be duplicated and we wouldn't want to restrict record titles purely to prevent URL conflicts, we must add a marker with the ID to the end of the URL. IP.Content in turn uses this information to load up the proper record when this URL is requested. This is pretty useful in and of itself, however we went a step further.

IP.Content is used by many different customers in many different fashions. On some sites, anyone can submit to the database. On some sites, only administrators submit to the database. Because of the different configuration options, and because some databases are small and very controlled by nature, we knew that some administrators would like to remove the record ID from the end of the URL. So we built in support to do just that. If you would like to remove the "-r1" from the end of the URL in the last example, you need only login to the ACP, load up the record to edit it, and within the ACP you will have the option to specify the friendly URL for this specific record. If you manually specify a friendly URL for the record, it overrides the dynamic friendly URL and is used instead. You will not be able to set this same friendly URL for any other record, naturally, but you can edit the URLs at any time should you need to. Thus, you can turn the above record into the following URL



http://domain.com/database.html/_/ipb-rocks/ipcontent-is-cool

You may have already noticed, but it's important to note that IP.Content utilizes the category hierarchy within the URL for records, including for any sub-categories you may have configured. If you do not utilize categories for your database, that's fine as well - IP.Content will already know this and omit the category from the URL without issue.



While not related to the friendly URLs, there's something else I'd like to point out while we're discussing friendly URLs in IP.Content. You are not required to specify an extension for the pages you create in IP.Content, if you don't want to. If you didn't realize this, you can rename "database.html", in our example, to just "database" and the page will continue to function just fine. If you did so, your URL would become



http://domain.com/database/_/ipb-rocks/ipcontent-is-cool



I know some of you are going to ask about the "/_/" marker in the URLs posted above. It is not a typo. Because of the complexity and many configuration possiblities (pages can be in folders, which can be subfolders, with or without an extension, and so on), IP.Content requires some sort of "marker" in the URL so that it knows when the rest of the parameters are database information. We thought about setting some sort of word for this marker (i.e. "news") but quickly realized this isn't feasible, because everyone uses their databases for different purposes, and many of our customers do not speak English natively. Additionally, you may run one more than one database, however the marker itself is global to IP.Content. While the marker will ship as "/_/" in IP.Content 2.0, you can change it if you desire by editing a constant in an IP.Content file. We felt that having this constant was the the best way to ensure you had control over the marker, should you wish to change it, given that we cannot store this information as an ACP setting for technical reasons.



Your requests for friendly URLs in IP.Content 2.x have been heard. They will be available, and will work right out of the box based upon your existing configuration. We have much more in store, so stay tuned!
  • 5,595 views
bfarber

IP.Content 2.0 Dev Update: Interface Improvements to Pages

The page manager, introduced with IP.Content 1.0, is a core feature to IP.Content. It allows you to create pages and folders, and manage those pages and folders, core functionality that IP.Content relies on for everything else. Page management has been pretty reliable and functional, but we decided we wanted to improve the interface for IP.Content 2.0 to make it sleeker, faster and even more functional.


Several interface tweaks have been (and are still being) implemented in IP.Content, and the page manager was one of the primary focuses of these interface enhancements. We'll quickly describe the major changes below.

Redesigned "buttons"


The IP.Board ACP interface utilizes a small "button" icon that is located to the far right of a row in the ACP that you can take action against. In most cases, you will click this button and then choose an option from a resulting dropdown menu. Here's a quick screenshot of one such button to give you an idea of what I'm referring to




While functional, Rikki has redesigned this area to allow for the more important buttons/options to be pulled out of the menu, while still allowing for the menu to contain further options you may need to take on a row, but likely won't be executing very often. This means that for your typical options (i.e. edit) you now have one click, instead of two. And it's a lot prettier to boot!





The folder rows allow you to quickly add a new folder or page under the selected folder, while the page rows allow you you to quickly edit the page. Additional options remain tucked neatly away in the dropdown menu, just a click away.

Quicker access to folders

In IP.Content 1.x, when you click on a folder you are taken to a new page that lists that folder's contents. If there is a subfolder, you can click on it to enter into that folder. While effective, if you have a deep folder structure, this can require some time to fully drill down to where you want to end go. There's an easier way than this, surely!

With IP.Content 2.0, when you click a folder, its contents will be returned via AJAX and displayed inline. Any subfolders will be listed, along with any files in the folder, right below the folder row that you clicked in (indented, to show "depth"). You can click on subfolders to return those results as well. here's a quick screenshot to show you what I'm talking about.




In this screenshot, I've clicked on "another-test" and then proceeded to click on "sub-another" to show its contents as well. With this method, you can quickly drill down into any directory without having to wait for several page loads to occur, improving resource usage and efficiency, while simultaneously reducing the time it takes to accomplish the same task as before.

Page filtering

When you just have 4 or 5 pages, it's not much of a task to find the one you need to edit. You can quickly browse the list of pages from the page manager and click on it to edit it. Once you start designing an entire site, however, and utilize folders to create sub-sections of the site, it can become increasingly difficult to find the exact page you are looking to edit. Setting aside any "difficulty" in navigating to where you need to get, if you have a 10-level directory structure, it obviously takes a little bit of time to drill that deep.

IP.Content 2.x features a new filtering field at the top of the page manager page. This filtering field utilizes live-search functionality to show you search results as you type into the field. You start off by typing in the name of the page you wish to edit. The display will switch to show you all search results for that page, and the folder the search result is contained within. From here you just click on the page and start editing. You can click the "x" icon to clear the search results and switch back to the normal page manager listing, all without any page refreshes.







If you know the name of the page you want to edit, but don't remember what folder it is contained within, this new filter capability can make it easier to find where you need to go without hassle.

More AJAX

We've utilized AJAX elsewhere on the page manager to make common actions quicker and smoother. For instance, if you click on a button to add a folder, and submit the new folder name, it is submitted to the server via AJAX and then displays inline where it should (i.e. as a subfolder of an existing folder, or in the main page manager root, depending on what folder you are adding your new folder to).

Deleting and emptying folders also utilize AJAX to accomplish these actions without the need for a full page refresh. Inline confirm prompts (newly restyled) ensure that you don't accidentally click the link without confirming that you truly want to empty or delete the folder.




Additionally, deleting pages also utilize AJAX to accomplish the task, again with the restyled confirm prompt to prevent you from accidentally removing something you didn't mean to.

Conclusion

Many of these new interface changes you will see introduced elsewhere in IP.Content, such as the new action buttons to trigger actions against a specific row of data. Other minor tweaks are being implemented elsewhere in the ACP as well, but we'll leave that for another blog entry. ;)

As always, if you have any questions or feedback, we'd love to hear it!
  • 4,716 views
bfarber

IPB 3.1.0: Centralized License Key

Over the past year we have introduced new services that are available to our IP.Board Standard Licenses holders, such as the spam service and the chat service. We also have plans for more services that will be tied to your license. While this provides a lot of value to your license, managing these services is a cumbersome process, you need to create keys for each of these services and enter them in different areas of the ACP.

We're always looking for ways to streamline and improve your experience, toward that end we will be introduce a new centralized license key that will work for all services. Starting with IP.Board 3.1, all licenses will be given a single key that will grant access to all services available to that license. When we introduce new services, you will automatically have access to that service without having to log in to your client area account to generate a new key and activate it.

IP.Board 3.1 will include a new license manager in the ACP. When you first access the manager, you will see a screen that lets you enter your license key and your forum URL:



After you activate your license, you will be able to see the status of your license and all the services that are attached to that license:



Like all previous versions of IP.Board, your forum will function if you do not enter your license key, however you will not have access to any of the special extra services your license provides until you activate your license key. There will be a grace period where old spam and chat keys will continue to function, however we recommend that you activate your new license keys as soon as possible.

We hope that this simplification of our license key system will be beneficial to everyone and that you enjoy all the services it provides! As always feedback and suggestions are welcome.
  • 8,437 views
Josh

IP.Board 3.1.0 Dev Update: Improved Facebook Integration

When we were developing IP.Board 3.0 we were looking for ways to lower the barrier for registering. There are many single sign in providers but most of them required separate registration and set-up. Around this time, Facebook released their emerging API "Facebook Connect". We seized the opportunity to implement it within IP.Board 3 and adhered to all their guidelines. The first implementation of the Facebook Connect API was less of a point of authentication but more of a way to appear as a member of a site.

This was slightly at odds with the concept of permanent registration at a forum and a few work-arounds had to be made. For example, there was no way to request your Facebook data without you actually being active on the board and connected (logged into Facebook). Also, Facebook did not allow you to request the Facebook user's real email address but instead had to make do with a long proxy email address that Facebook would use to forward mail to your Facebook account. Despite these limitations, it worked well in allowing users with a Facebook account to register almost instantly on your forum.

Since then, Facebook have updated their API dramatically allowing so much more functionality. Naturally, we have taken the opportunity to update the integration within IP.Board. You can now request several different permissions to allow IP.Board to fetch your Facebook data without you being online. Furthermore, IP.Board can now store a permanent "key" to link your forum account to your Facebook account meaning that you shouldn't see the "Connect" button once you initially set up your forum account.

As these permissions need to be explicitly granted, we have added a little section to the "Manage Facebook Connect" page to list the permissions IP.Board requires and whether or not such permission has been granted. If permission has not been granted, you will be give the option of requesting permission.



You can now also publish your status updates directly to your Facebook account using the new API methods:



This new implementation should clear up a lot of the current Facebook issues people experience, mostly due to authorization errors between IP.Board and Facebook caused by expired sessions.

The new methods also allow the new sharing links system.
  • 13,963 views
Matt

IP.Board 3.1.0 Dev Update: Sharing Links

Following on from our recent blog entry about Twitter Integration, I'd like to present our newest IP.Board 3.1.0 feature: Sharing Links. This new feature makes good use of our improved Facebook Connect integration and the new Twitter integration.

As most Facebook and Twitter users have discovered, sometimes you see a link to a great article or topic and want to share it with your friends and followers. This new feature makes this very easy to do. You don't even have to leave the page to do it. The ease of use will encourage your members to share your links among their friends increasing the traffic to your forum.

If you have connected your forum account to Twitter and Facebook, then clicking on the share link icon for those services loads a pop-up enabling you to tailor your content before sending it. Of course, there are many more places to share links which is why we've included a few other methods by default and made it very easy to add your own.

Let's look at the feature in more detail.

The screen shot below shows a typical topic and the new share icons underneath. In this case, we've just clicked on the "Twitter" icon:



Now, lets hit "Share". We see a confirmation of our tweet and a link to it:



Let's take a quick look on the Twitter site to confirm it. (I've removed some of the bit.ly URL in this screen shot)



Now, let's hit the Facebook icon:



A quick look on Facebook confirms the link has been added to my wall



Of course, if you don't have your account linked to Twitter or Facebook, the standard "share" link is launched for each service. The other services act like this too, a new window is opened with the service's share page loaded and filled in.

Developers will be pleased to note that adding share links to your own pages is incredibly easy. All you need to do is add one small line of code to your templates and it handles the rest. You don't need to load or parse any data directly, it's all handled for you. For example:



Share this: {IPSLib::shareLinks( $documentTitle )}

Wouldn't it be great to know which links were shared and how many times? You'll be pleased to know that IP.Board tracks the number of shares for each URL and service type and can show a log of this data in the Admin CP. We've also put together a side bar hook to process this data:



This data is cached each time a link is shared, so it is very light to load and process. It is entirely abstracted so your own applications can make use of it.

It's no secret how social media has improved how we share data to each other and this feature allows your board to gain more exposure using existing services. The seamless integration with Facebook and Twitter lowers the barrier for sharing your content.

Here's a quick overview of the feature:

- Global on/off switch to remove the share link icons and functionality
- On/off switch per forum to remove the icons and functionality
- Fall back to simple service's "share" page if member doesn't have JS enabled, or does not have their account connected
- Admin CP options to add more services and to disable existing services
- Sidebar hook uses cached data and can be disabled. Guests cannot see it.
- Topics that are shared that you do not have permission to see have the topic title "Protected Topic" by default in the sidebar block.
  • 27,333 views
Matt

IP.Content 2.0 Dev Update: Improvements to Databases

Database "Tweaks"
The database functionality in IP.Content is quite powerful at its core. You can do a lot of things with the database feature that would normally be laborious coding yourself. A lot of addon applications add common features: rating, comments, sorting options, etc. IP.Content takes all of this legwork out of the picture by providing it for you with just a few clicks in your admin control panel. But there's always room to improve! We have focused on some small but useful tweaks and improvements to the core database features that we think will benefit everyone.



Specify The Text

IP.Content databases refer to stored entries as "records". This is a generic term that can be used for just about any database, which is why we chose to use this originally. It is understandable, however, that some of you want to personalize the interface a bit more. "Records" isn't exactly the clearest term in all cases to all users, so it makes sense that you might want to refer to the entries as "articles," "pets," or "recipes", for instance.

With IP.Content 2.0 you will be able to define the text bit to use to represent "records" in a database right from the database configuration form in the ACP. Four fields will be presented to allow you to define the singular and plural versions of the words in both lower-cased, and first-letter-capitalized versions. I know this probably reads a little confusing, but basically it allows you to define "record", "records", "Record" and "Records" independently. While PHP has many useful functions that can handle this just fine for the English language, in an effort to better-support our international customers we felt it prudent to allow you to define all of these versions of the word yourself.



Specify The Content

In IP.Content 1.x we provided an option on the database configuration page to allow you to indicate which field represents the "title" of a record. Because databases are so configurable, we needed to give you a way to specify this field so it can be re-used properly throughout IP.Content. In IP.Content 2.0, you will now also specify which field represents the "body" or "content" of a record. Some databases may have no use for this, but if you are setting up a database of articles, you will surely want to specify which field represents the "content". This designation is then used to determine which field to show as the "body" in a database feed, and in our next new feature we'll talk about...



RSS Feeds

Yes, you can now allow automatically generated RSS feeds in your IP.Content databases. Even better, RSS feeds are supported at both the database and the category level, automatically. You can also disable RSS feeds individually on a per-category level, should you wish to. This is useful if you have a private staff-only category of articles, for instance, which you do not want to publish via RSS with the rest of the articles in the database.




Settings have been added to both the database and the category configuration forms to enable/disable RSS feeds, specify how long (if at all) you wish to cache the feeds, and to specify how many records to include in the feed. The category configuration form also has a setting to exclude it from the global RSS feed, as mentioned previously. Feeds are cached, if configured to do so, for performance reasons.



Duplicated Sort Form

In the ACP record management screen, we have duplicated the sort/filter form to the top of the page. If you have a lot of record management duties to perform in the ACP, this can help you to more quickly drill down to find the records you need to work on by eliminating the need to scroll to the bottom of the screen each time you wish to change the returned records.

We have also added a "Save and Reload" button to the record add/edit form. You can stop with the PMs now Ditchmonkey! :lol:



Save and Reload

We've added a button to the add/edit record form in the ACP that will allow you to "Save and Reload" the record. If you are making may small changes to a record (for instance, you want to refresh the record on the front end to verify how it's displaying), this is useful as it will save your changes, and then immediately reload the form so you can continue editing the record, instead of forcing you to save, find the record, and click edit on it again to bring the form back up.



Meta Tags

Configuration fields have been added to the database and category forms in the ACP to allow you to define your meta keyword and description tags for your databases and categories. For records, meta tags by default will be automatically determined, just the same as happens in topics in the forum. You can, however, also manually override the meta tags on a per-record basis from the ACP by editing the record, should you need to.



Display Subcategories

Similar to how the board index will list subcategories underneath their parent forums, IP.Content 2.0 will now (by default) display subcategories of a category underneath the category title when viewing categories.





And more to come!

These are just a few of the changes we've made to the databases system in IP.Content 2.0 that we believe will make your databases more useful, more configurable, and more "your own". The changes better integrate IP.Content with the forums, providing a more seamless feel to the site, while at the same time enhancing IP.Content-specific functionality to let you better control your content.

Be sure to stay tuned for our future updates on IP.Content 2.0! We have a lot of other useful changes in store you'll surely want to take advantage of.
  • 4,369 views
bfarber

Spam Monitoring Service Update

Last year we introduced a Spam Monitoring service to combat the increasing problem of registrations on communities from spam accounts and the response to this service has been great! The spam service has been a great success so far and we would like to take the time to share some stats about how effective the service has been.

The service is only as effective as the number of communities that sign up and report data back to our system, so we are happy to report that thousands of communities have joined the service and are helping each other to reduce the amount of spam each receives. If you have not yet signed up, we would encourage you to take this opportunity to do so: the Spam Monitoring service is free to all active IP.Board license holders!* It is a great way to improve and protect your community while saving you time.

Thanks to the network of communities that have joined this service, we have been able to block tens of thousands of spammers from registering on communities that participate in this service! The spam service itself receives thousands of requests per hour and continues to build its database from that data. As always, your registration data is kept safe and is not permanently stored as transmitted data is only used to detect spammers.

We are continuing to monitor everything that is reported and look for trends to help the system better identify spammers that are registering on your communities. If you are signed up for the service and a spammer does register, please remember to use the Mark as Spam feature (both in the IP.Board AdminCP and the front-end for moderator use) so that we can receive that data and use it to improve the service for everyone.

If you are signed up for the spam service, please take a moment to check your logs (in the IP.Board AdminCP) and make sure that the service is working for you. We have noticed that some sites do not have the correct URL for their site so their requests to the service are not working as a result. If you are having any issues, please open a ticket and let us know.

New in IP.Board 3.1

Most of the processing for the service is handled by IPS servers but we are adding two enhancements in IP.Board 3.1: reporting false-positives and statistics.

Reporting False-Positives

Just as your email client sometimes flags a legitimate email as a spam message, our service sometimes tries to be a bit over-protective and will flag a legitimate account as belonging to a known spammer. You can currently "un-flag" that account and restore it to normal but that information is not passed back to IPS so the service could learn that a particular account was actually legitimate. In IP.Board 3.1, removing a spam status on an account will be reported back to IPS to improve the service.

Statistics

IP.Board 3.1 will include reports and graphs on how the service is protecting your individual community.


We hope you continue to enjoy the protection the service offers and if you have any suggestions, please post in our feedback forums. Thanks!




*The following packages include the services option, which the spam service falls under, and qualify to use the service at no cost:


IPS Hosting clients IP.Board Standard License IP.Board Business license IP.Board Community Suite license
  • 4,601 views
Josh

IP.Content 2.0 Dev Update: Useful updates to feed blocks

IP.Content 1.x has turned out to be a very solid, stable, and extensible application, allowing for a vastly diverse number of implementations that showcase many of it's capabilities. We're thrilled to see so many of our customers using IP.Content in different and creative ways. We've been gathering feedback from all of you to help shape the future of IP.Content, and to that end we want to share with you some changes you can expect to see in IP.Content 2.0.




Feed Blocks
Feed blocks are a very powerful tool in IP.Content. You can create blocks that feed data from any application in IP.Board (that supports IP.Content), as well as from any RSS feed. In fact, much of the data you will want to show on IP.Content pages is easily returned through a feed block (latest gallery images, recent topics, top posters, etc.) of one kind or another. With each release we put some effort into improving the feed blocks further to make them as useful as possible.



Database Comments

Some of you have requested a new feed block type that will allow you to pull database comments from IP.Content databases, and IP.Content 2.0 will now feature this capability. Some practical uses for such a feed type include a "Latest Article Comments" block, or a "Comments Awaiting Approval" block for moderators. Use your imagination, and let IP.Content do the rest.



Forum Feed: Honor Permissions

Presently in IP.Content, if you create a feed block and restrict the forums that content can be pulled from, the topics and/or posts are pulled, regardless of whether the user has permission to view the content. This was done by design, to allow you to have a hidden forum for news entries (for example) and still feed this to your home page. Some users have requested that we allow them to honor a user's view permissions when filtering content by forum, however, and this will now be supported in IP.Content 2.0. When creating a feed from the forums, there will be a checkbox to allow you to honor the forum permissions, and only content a user is able to see will be returned. This only impacts forum feeds where you have explicitly restricted which forums to pull content from (if you do not restrict the forums that content can be pulled from, the user's view permissions are already honored).



Filtering Database Feeds

Database feeds were implemented in IP.Content 1.x, however the filtering options are relatively restrictive. It is logical that some of you may want to restrict records returned in a database feed based on custom fields, providing you with more opportunities to define the parameters used to determine what content to display. With IP.Content 2.0, you will now be able to restrict database feeds to filter content based on most of your custom fields (the same ones you can use to sort/search within a database presently). You will be able to define up to 5 custom filters based on your custom fields. This opens up many opportunities for you to introduce creative new database feed blocks on your site.



Gallery Feed Improvements

Virtually everyone creating Gallery feed blocks will ultimately want to display the image thumbnail. While this is entirely possible in the current version of IP.Content, it requires you to add some code to your template manually; code that everyone ends up adding. To make Gallery feeds easier to use for everyone, the code to generate the image thumbnail is now automatically executed in the feed, and the thumbnail is available to the template as $r['thumbnail'].



Additionally, we've added a new filter setting under the category multi-select box. Enabling this new checkbox will tell the feed to also check in any albums (that the user has permission to view) under the selected categories. This means you could, for example, select the Member's Gallery and check this checkbox, and not have to manually select every album contained within the Member's Gallery (and it also means you won't have to continuously edit the block configuration to continue selecting new albums as they are created).



And a few other tweaks

In addition to the changes above, we've been going through some of the feed blocks to try better respect the returned data you expect to see. For instance, in a topic feed, the last_poster_id can sometimes be the last poster id in the forum, rather than the topic. We're taking some time to try to normalize the data returned from feed blocks so that you have better access to the data you want to use.




And a lot more to come...
We have a lot more in the pipelines for IP.Content 2.0 as well, and we can't wait to reveal what else we've got up our sleeves. We're hard at work improving the interface, performance, and usability of the system, and we are taking all received feedback into account while we work to make IP.Content the best tool of it's kind! We're very proud of IP.Content and hope that you are enjoying it so far. If you have any features you're just dying to see included, please be sure to post them in the feature suggestions forum. Similarly, if you have any questions or feedback about the changes discussed in this blog, please feel free to leave your comments. What we've discussed here is just the tip of the iceburg. We think you'll be even more excited to hear what else we've got in store when we roll out our next blog entry. Stay tuned!
  • 6,806 views
bfarber

IP.Board 3.1.0 Dev Update: Soft Delete

IP.Board already has many moderation tools, including the ability to "approve" and "un-approve" posts and topics to make them hidden from the general community. IP.Board also has a "Trash Can" forum which collects all deleted topics and posts giving you a chance to keep them and manually move them back if you wanted to do so.

Recently, we've had several requests for a "soft delete" option. This would work in a similar manner to the "approve" and "un-approve" system but with an extended permission set. Essentially, when you "soft delete" a topic or post, it vanishes for the general community (by default) but is still visible to moderators and administrators in-line. You can also add a reason why the item was deleted and it records the time stamp. If you have permission, then you can restore the post if desired with a click of a button.

The permissions model works like this:

Per Member Group:
- Can Soft Delete All Topics
- Can Soft Delete All Posts
- Can Soft Delete My Topics
- Can Soft Delete My Posts
- Can See Soft Deleted Items
- Can See Soft Deleted Content
- Can Restore Soft-Deleted Topics
- Can Restore Soft-Deleted Posts

Per Moderator: (Will override member group selection in the forum(s) they moderate)
- Can Soft Delete All Topics
- Can Soft Delete All Posts
- Can See Soft Deleted Items
- Can See Soft Deleted Content
- Can Restore Soft-Deleted Topics
- Can Restore Soft-Deleted Posts

This gives you many options. For example, you could allow your members to "soft delete" their own content allowing you the chance to restore it. Conversely, you may also want your members to see that some items have been deleted, but not see the actual content of what was deleted. The choice is yours.

Here's a few screen shots detailing the feature:


When the delete button is clicked, a new dialogue appears giving you the option to "remove from view" (aka, soft delete) or "Delete Now" which will either remove it from the database, or move it into the Trash Can forum if it is set up.


How the deleted post looks if you have "See Deleted Items" permission. The toggle button is visible for those with "See Soft Deleted Content" permission.


The forum's topic list shows a pink background with a delete icon for topics with "soft deleted" posts. Clicking the delete icon brings up a list of the deleted posts.


Clicking on the delete icon (that appears when you mouseover the cell) brings up a dialogue similar to the post one.


Showing the deleted item in the forum's topic list. Clicking the topic title link will take you to the topic if you have "See Soft Deleted Content" permission.

This feature also works with the multi-moderation allowing you to "soft delete" or "restore" many posts or topics at once.

Please keep in mind that the screenshots shown are based on a pre-beta build of IP.Board 3.1 and will likely receive a little polish before release.
  • 20,619 views
Matt

IP.Board 3.1.0 Dev Update: Ad Code Integration Part 2

Yesterday we showed IP.Board 3.1's ad code integration for the first time, today we'd like to give a quick update on the status of this new feature.

First of all, we were excited to read all of the positive feedback and great suggestions. We like to write these blog entries before features are 'set in stone', so that we can more easily and quickly include suggestions from our customers.

Group Setting

In response to your feedback, we've included a new setting that will allow you to hide ads for specified groups.



Ad Placement

Another common concern was the placement of ads within topic view. While we are not going to add an additional setting that gives you the option of showing the ad inside the first post, we do want to show you how easy it is to accomplish this. The ad code is passed into the template bit along with the first post, so you can move it any place you like within in that first post. Here is the code to display the ad:



<if test="adCodeCheck:|:$post['post']['_adCode']"> {$post['post']['_adCode']} </if> By default, we have this setup so that the ad is placed after the first post is completely printed. However, if you would like the ad displayed inside the first post, all you need to do is move that display code and place it after this code:

<if test="postSignature:|:$post['post']['signature']"> {$post['post']['signature']} </if> The same is true of the other ad codes, it's very easy to move them to any place in the template that you would like. Modification Developers There are also a few functions that may be of interest to modification developers. If you want to give users the ability to show ads in your mods, you can easily check permissions before displaying the ad using this new function: IPSAdCode::userCanViewAds(). This will return true/false depending on if the user can view ads or not. Much like the board index, forum view, and topic view, you can have your modification set it it's own global header/footer ads by using a simple function:

IPSAdCode::setGlobalCode( 'header', $yourHeaderAd ); IPSAdCode::setGlobalCode( 'footer', $yourFooterAd );


Once again, thank you for the great feedback!
  • 19,921 views
Josh

IP.Board 3.1.0 Dev Update: Ad Code Integration

Advertising integration has been an often requested feature for a long time, so we're pleased to announce that IP.Board 3.1 will include this feature! We've create a simple system that will allow you to insert ad code at various locations throughout the forum. The integration is not specific to any ad platform, so you can use this for Google AdSense, or any other platform that you may use for your site. We did not want to choose any specific advertising platform to keep the system flexible plus IPS would never get between you and your advertising revenue.

There are several predefined ad spots, all you need to do is paste the code for your ads into any of these locations.


Header and Footer Ads

The first two locations you can place ads are in the global header and footer, these ads will show on every page in the forum, except for redirect screens.



As you can see in the screen shot, this system uses a simple settings page for adding ad code, you can paste anything you want into these boxes. In addition, there are several areas that can override the global header and footer code with page specific header and footer code. The Board Index, Forum View, and Topic View are able to use this override feature, so that you can either not show ads on one of those areas, or show different ads.

Aside from the headers and footers, there are three other locations that you can place ads:

Board Index Side Bar

A simple hook will allow you to place ads in the sidebar of the forum index, you can use the existing hook ordering system to determine where on the sidebar the ad will be displayed.

Forum View & Topic View

You can also specify ad code that will be displayed inline with topics in forum view and posts in topic view, these ads will be displayed after the first topic or post. Here's a screenshot of each:





As you can see, this is a basic and easy to use system for placing ads in IP.Board. We have ideas for future enhancements to this system and will be improving things as we go but, even with this basic implemenation, you can now easily disperse advertisements throughout your community.

We hope that you find this helpful, and as always, we look forward to your feedback and suggestions!
  • 27,398 views
Josh

IP.Board 3.1.0 Dev Update: Skin Upgrader

One of the neat new features of IP.Board 3.0 was its integrated application/hook installer and upgrader. Using this took a lot of the headache out of updating modifications when the author produced a new version as you would have either needed to use a custom installer script or install a component dedicated to modification installations. This has helped out with the installations of modifications, but skins still install in essentially the same way, and there is nothing built in to the product to let you upgrade skins.

Currently, when a new third party skin gets updated by its author, it can involve a lot of work for board owners who use that skin to upgrade the copy of it on their site. The old procedure was to import the new version of the skin, move everyone who was using the old version onto the new version, and delete the old version. If you had customized anything to do with that skin template prior to initially installing it, you'd have to keep track of what changes you had made so that you could apply them to the new version of the skin. It should go without saying, this procedure was clunky at best.

Recently I stumbled across a post where this frustration was mentioned. This got me thinking about the issue. Surely there must be a way to upgrade a skin just like hooks and applications can be upgraded, right?

Right now I'm developing some additional functionality in the Skin Import/Export feature in IP.Board 3.1 to take care of this. Essentially how it will work is this: when you import a skin set, the skin info is checked to see if a 'skin set key' has been set. If it has, it checks if this key matches the key of a skin you already have installed. If it does match, and you check a box indicating you want to try and upgrade, it will attempt to upgrade your existing skin. Any replacements/CSS/templates that this new skin XML has will be checked against the existing items from the old version of the skin to see if changes are needed.

Thus far, I have it coded to show you the check box to indicate whether or not an upgrade will be attempted:



I also have a lot of the back end work done where it will see if it needs to upgrade an existing item instead of just inserting a new version of the item. There's a lot of checking involved to be sure I'm not duplicating elements, so this will require a lot of testing. I've got a few bugs to work though on this, but it should be in place pretty soon.

I think that this will be a feature that will be appreciated by a lot of folks. I welcome any feedback you may have. :)
  • 14,216 views
Michael

IP.Board 3.1.0 Dev News: Twitter Integration

I had previously blogged about the status update improvements coming in IP.Board 3.1.0. This blog runs through some exciting new integration features with Twitter.

As IP.Board already has Facebook integration, it makes sense to also integrate Twitter. This further lowers the bar when registering a new account on your forum. If your visitors have have a Twitter account, they can use this to register a new forum account or to "connect" their existing account with their Twitter account.



Integrating your Twitter account allows you to use your Twitter profile picture and description on the board.



You can also import your latest Twitter status onto the board, or post your board status to Twitter. If your forum status is longer than 140 characters, it will cut the status off and automatically add a Bit.ly URL pointing to your forum status update.





You may note that each status update on the forum has a little icon showing where the status originated.

These improvements should increase registrations on your board and generate more traffic to it.
  • 16,508 views
Matt

IP.Board 3.1.0 Dev Update: Modification Development Enhancements

There are a lot of enhancements being made to the application/hook system in IPB 3.1, many of which were discussed in a previous blog post. While that post focused on the hooks system, there have been many other changes made throughout IPB 3.1, and we'd like to highlight a few of those in this blog post. We hope that our modification community will find these changes helpful and can't wait to see what they do with this new version! As always, if there are any suggestions or comments, we would love to hear them.

Template Hooks: Replace Output

A new optional function has been added for template hooks called replaceOutput(), which receives the entire content of the page and replaces it with what is returned from your hook. This allows your hook to replace tags with whatever content you need, here's an example that adds the pid of a post next to the multiquote button:



public function replaceOutput( $output, $key ) { $tag = '<!--hook.'.$key.'-->'; $lastFound = 0; foreach( $this->registry->output->getTemplate('topic')->functionData['topicViewTemplate']['post_data'] as $pid => $post ) { $pos = strpos( $output, $tag, $lastFound ); $strToInsert = 'PID: ' . $pid; if( $pos ) { $output = substr_replace( $output, $strToInsert . $tag, $pos, strlen( $tag ) ); $lastFound = $pos + strlen( $tag . $strToInsert ); } } return $output; }

memberSync Changes

We've made a few changes to memberSync, in order to make a few of the functions a little more useful.

onGroupChange: The old member group is now passed into this function onLogin: The plain text password is now passed into this function onCreateAccount: The plain text password is now passed into this function


Extensible Forms

One of the new features we introduced with IPB3 was the ability for applications to extend the member and group edit forms in the ACP. We've now expanded that functionality to include the forum edit form as well. This works in the same way as the group edit form, by allowing your application to add a tab to the edit forum form. We've also updated the member form extender to determine tab ids automatically, exactly as the group form extender does in the 3.0. So you'll no longer have to worry about your member form conflicting with another applications member_form.

Attachment Plugins and Profile Tabs

Our goal with applications is to make them as independent of each other as possible, toward that end we've moved the attachment and profile tab plugins into the application extension directory of each application. Profile tabs will now be placed in YOUR_APPLICATION/extensions/profileTabs and attachment plugins will now be placed in YOUR_APPLICATION/extensions/attachments. The file and class names have remained the same, the only difference is their location within the file structure.

New Setting Type: Autocomplete Member Name

This new setting type will allow you to create fields that will then be turned into member name autocomplete fields by IPB.
  • 8,201 views
Josh

PHPDoc Developer Documentation

We'll keep this blog entry short and sweet, since there's not a whole lot to say.

Developers have asked for further documentation of IP.Board (and addon applications), specifically source code-level documentation of the various classes and methods that can be reused. Those of you familiar with phpdoc will know that it's the perfect tool for the job, and thankfully we wrote IP.Board 3 using phpdoc-style comments to facilitate this job.

After a lot of cleanup and tweaking, we have made the phpdoc developer documentation available for all. Please be aware that this is the first "release" of these documents, and there are likely going to be some oddities and under-documented functions. Please let us know where we can expand on the documents. We intend to add more code examples and to clean up the class-level documentation a little over time, but if you have any specific requests we'll focus on those first.

http://community.invisionpower.com/resources/phpdocs/index.html
  • 5,190 views
bfarber

IP.Board 3.1: Notifications

It's a well-known fact that one method of ensuring continued visitation of your site is to email members frequently to send reminders and notifications. For instance, if a user posts in a topic, they may forget that they posted after a day or two. If an email is sent to that user after someone else replies, however, it can remind the original user to return to your site to check on the updates.

IP.Board has a strong system of notifications, however we found that much of the code to handle this is scattered and duplicated throughout many files in IP.Board 3.0. The methods of managing your notification preferences are also inconsistent, making it confusing and difficult for new users to determine how to control notification preferences. If you are a moderator, you manage your report center notification preferences in the report center. You are only able to get email notifications of tracked topics. You can select to get email or PM notification of new comments and friend requests in your user control panel. Through these few examples, you can see that managing notification preferences can be made easier.

IP.Board 3.1 introduces many improvements to notifications, both on the backend and within the user interface of the board itself.

Inline Notifications
In overhauling the notification management options in IP.Board 3.1, we decided to add inline notifications. Essentially, this is a notification within the board itself, without actually issuing a private message or an email. There are many instances where a visitor might want to be notified of an action, but might not want an email to be sent to their email address, or they might not want a private message for such notifications (especially if your board has limits on the number of private messages an individual can store).

Visually, when an inline notification is first triggered, it will look identical to the existing private message popup. In fact, private messages no longer directly initiate the popup you have become familiar with - instead, they issue an inline notification (which initiates this popup). This was done on purpose for consistency, and for code reduction and reuse purposes.

A "Mark Read" button has been added to the popup so that, in addition to closing or viewing the notification, you can mark it as being acknowledged without having to leave the page.



A new option has been added to the profile dropdown to allow users to quickly access their inline notifications, as well.



Administrators can control how many inline notifications a single user can store on a per-group basis. If a user is allowed to store 50 inline notifications, and notification number 51 is issued, the user's oldest notification is automatically pruned. The user will see a notification popup on the board the next time they click a link. There is also an area in the user control panel where each user can list, view and prune their notifications. Additionally, a new board index hook will show up when a user has unread notifications (and automatically disappear once all of their notifications have been acknowledged).



Stronger control of notifications
A new area of the ACP has been added to allow administrators to better control notifications as well. Any registered notification events will be listed, and the administrator can control which methods to use by default for each notification event, which methods cannot be used at all, and will also have the ability to disallow users from overriding the admin-defined selection. For example, an administrator might want the default notification method for new private messages to be inline notifications (show a popup on the board). Administrators may also want to disallow users from electing to get an email notification when comments are made on their profile to reduce the number of email messages sent from the server. An administrator may also want to enforce that all users (with appropriate permissions) get an email notification when content on the board is reported. All of these things, previously not possible, can be configured from one page within the ACP of IP.Board 3.1.



Easier user configuration options
In addition to the new UserCP page to view your inline notifications, there is a new notifications page where all notification settings and options have been consolidated. New configuration options are available to control your notification preferences, as well. Each user will be able to select whether they want to receive email, PM, or inline notifications (or a combination of the above, or none of the above) for each notification event from one page. Methods that are not available per the ACP-defined preferences are removed from the user's options, while notification events that an administrator does not allow users to override are disabled but still displayed (so that a user can know how they will be notified when one of those events occur). A couple of screenshots should help clarify this.



If an administrator makes the following configuration in the ACP



A user can expect to see the following in their notification preferences



You'll also note from these last 2 screenshots that we've added the ability to get notified when someone quotes a post that you made.

Easier for developers
IP.Board 3.0 has well-abstracted code to make sending private messages and emails easy for developers. While this is true, code is duplicated throughout IP.Board 3.0 that is meant to handle sending either PM or email notifications. As a general rule, duplicated code is not a good thing to have. We also had to find a way to easily implement inline notifications (without adding yet more if/else style statements everywhere that sends notifications).

We have created a new notifications class which developers can easily use to allow third-party applications to plugin to the new notifications system. This reduces the workload needed to set up notification capabilities (and management) for new applications significantly.

A developer will first need to create a plugin file for their application to define notification events. A sample plugin file might look like this


/** * Notification types */ $_NOTIFY = array( array( 'key' => 'report_center', 'default' => array( 'email' ), 'disabled' => array() ), );
<?php









(Yes, this is the actual code for the "core" application of IPB to handle report center notifications). You define the default selections, and the options to disable by default. For example, you would not want a private message to issue a new notification by private message. This allows the developers to define the default handling of notifications for their applications.

Then, to send a notification, the following code can be used


// Notifications library //----------------------------------------- $classToLoad = IPSLib::loadLibrary( IPS_ROOT_PATH . '/sources/classes/member/notifications.php', 'notifications' ); $notifyLibrary = new $classToLoad( $this->registry ); $notifyLibrary->setMember( $user ); $notifyLibrary->setFrom( $this->memberData ); $notifyLibrary->setNotificationKey( 'report_center' ); $notifyLibrary->setNotificationText( 'This is the text to show to the user' ); $notifyLibrary->setNotificationTitle( 'This is the title of the notification' ); try { $notifyLibrary->sendNotification(); } catch( Exception $e ){}
//-----------------------------------------


















The most common implementation will be to use the email library to first "build" an email, and then to assign the subject as the title, and the message as the text. As you can see, however, it is quite easy to use the notifications class. The class itself will determine what the administrator has defined as being allowed and disallowed, and what the user has selected for their notification preferences, and issue all appropriate notifications automatically based on the ACP and user preference selections. You don't have to worry about ACP settings or user cp settings either, using this method. All of it is taken care for you!

Closing
Through implementing the new notification capabilities, we hope to be able to expand the notification capabilities in IP.Board easier in future versions. As you can see, we've already added one more area where a user can get notified of changes in activity, and have some ideas of other areas where we would like to have the ability to issue notifications as well. With the refactored code and easier configuration management, implementing these changes will be easy.

Also, please keep in mind that the screenshots you are seeing are very early screenshots taken of a development build. Rikki hasn't had a chance to put his magic touch on these pages, so most likely the final look and feel will be touched up a bit. We just wanted to share the new capabilities, complete with some screenshots to help you visualize them, as soon as we possibly could.

Please let us know if you have any suggestions or feedback about the new feature.
  • 18,543 views
bfarber

IP.Board 3.1.0 Dev Update: Status Updates

I blogged just before Christmas about the improvements to the status update feature in IP.Board.




A recent addition is the ability to locks a status update. A normal member can lock their status to prevent comments from other members, although a super moderator (and admin) can over-ride this and reply and/or unlock the status. When a super moderator (and admin) lock a status, it means that in addition to other members being able to reply, the status owner can not unlock it.

I have also improved the sidebar hook to allow on-the-fly commenting, updating and deleting without leaving the page.



You can see it in action, here:



We feel these minor 'social networking' style features add interest and a secondary reason to re-visit your forum. Members can receive email notifications when a reply is made to their status, or a reply is made to a status they have commented on. This will continually drive traffic back to your site and encourage more interaction between members.
  • 15,149 views
Matt

IP.Board 3.1.0 Dev Update: Hook System

In IP.Board 3, we introduced the hook system, the goal of which was to cut down on file edits from modifications and make modifications easier to install. We designed the system to be as flexible as possible, primarily using the HTML logic feature to create hooks in virtually every portion of the output generated. However, we knew there were still cases where a file edit was needed, to access certain data or to reach any area of the board that was not a template or an action file.

One of our primary goals with IP.Board 3.1, is to expand the hook system to further reduce the need for file edits, as well as to make installing them even easier. We've read all the feedback on hooks from modification authors and are incorporating as much of it as possible into 3.1. Here's a quick rundown of the changes that we have mode so far:

New Hook Types

Our first goal was to extend the hook system to cover areas of the forum that are not currently accessible to hooks. Toward that end, we are introducing two new hook file types to address this issue:

Data Hooks

Modifications often need access to add their own data to insert/update queries that are run by IPB, at the moment that data is not accessible and must be queried separately and then hook has to run another insert/update query. To address this issue, we have added a new hook file type called a Data Hook. This type of hook allows you to access certain data arrays before they are inserted into the database. For example, you can create a hook that will receive the $post array before it is inserted into the posts table, this will give your hook a chance to add any data it needs or modify any data being saved. Technically, a Data Hook does not even have to modify the actual data array, you can use them as a simple code execution point as well.

Unlike Template Hooks, which are essentially generated automatically, Data hooks are manually specified in the code, so if you have suggestions on where you would like to see these placed, please reply to this blog post and let us know. At the moment, data hooks are used in the posting library, the messenger library, and some areas of the profile screen.

Library Hooks

There are many classes used within IPB that are inaccessible to hooks, as they are not actions or templates. However, it is often useful to be able to modify these classes with your own methods or to add on to existing methods. This leads to the second type of hook file that we are adding in 3.1, the Library Hook. This type of hook will allow you to extend the libraries that we use throughout IPB, a common example would be class_forums. This works in exactly the same way as an action overloader, your hook will extend the library you have selected and allow you to add to it or replace method calls with your own. Like the action overloaders, you will need to remember to call the parent method from your overloaded method.

In order for a library hook to work, we have to update the require call that includes that library. We're going through the code to try and find as many of these require calls as possible, but during beta you should check any includes that you are interested in extending to make sure we haven't missed them.

Other Changes

Hooks in AJAX requests

In the current release, any output returned via AJAX is not passed through the hook system. This has been changed in 3.1, now all returned output is properly run through the hooks system, allowing you to hook into any AJAX generated output.

Export CSS Files

There is a new option when exporting a hook that will allow you to specify CSS files that is used by that hook. The CSS files will be included in the hook xml and then imported along with the hook and cached to the file system.

Access Function Data

One of the most frequent requests we've seen is for a way to access template function data, with IP.Board 3.1 this will now be possible. Any active hooks within a template function will be able to access the function data through a special class property called functionData. To save resources, this data is not saved for any template function that does not contain active hooks. Here's an example of how to access function data inside of the topicViewTemplate function:

Function Declaration:


function topicViewTemplate($forum, $topic, $post_data, $displayData) { All of this data will be accessible to your hook via $functionData:

$this->registry->output->getTemplate('topic')->functionData['topicViewTemplate']['forum'] $this->registry->output->getTemplate('topic')->functionData['topicViewTemplate']['topic']

Wrapping up

We've also made quite a few minor tweaks throughout the hook system, these changes include updates to the ACP interface, performance enhancements, a toggle to quickly disable/enable all hooks, changing hook positions without IN_DEV enabled, and more. If you have any suggestions regarding these changes or the existing hook system, please do not hesitate to reply to this entry and let us know about them. We're very excited to see what our community will do with these new features!
  • 9,593 views
Josh

IP.Gallery 3.1.0 Wrap Up

IP.Gallery 3.1.0 will be released soon, so we'd like to take a moment to summarize all the new features we've added in this new release.

Friendly URLs

We've integrated gallery into the global FURL system used by IP.Board 3, this will allow gallery to create friendly URLs for categories, albums, and images.

Category/Album Covers

When viewing an image, you will have a new option to set that image as the 'cover' for the category or album that contains the image. When a cover image is specified for a category or album, that image will always be displayed, in place of the last uploaded image thumbnail.

Sub Albums

Albums now support unlimited sub albums, which work exactly like gallery sub categories.

Profile Picture Album

You can now create a new kind of album, a 'Profile Picture' Album. After this album has been created, any images that you upload to it will be displayed on the change picture page in your User CP, making them easy to select as your profile image.

Image notes
Image owners are now able to add notes to sections of their images, positioning and resizing them to suit. Other members will be able to see the notes when hovering over the image. (An example)

Image rotation
Images can now be rotated in 90
  • 1,667 views
Josh

Platform

Solutions

Guides

Help & Resources

Account

Navigation

Search

Search

Configure browser push notifications
Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.