Jump to content
View in the app

A better way to browse. Learn more.

Learn more

Invision Community Blog

Show all categories

IPB3: Banned User Management

The term 'ban' in IP.Board has a relatively loose definition and can often mean many different things. IP.Board supports an array of useful features to control access to the board, or in this case to restrict access to the board. Some examples of what 'ban' may refer to are


IP address ban filters Email address ban filters Username ban filters Placing a user in the 'Banned' group Suspending the user so that they cannot access the board temporarily Additionally an administrator can prevent a user from posting for a set amount of time, or require preview of all of their posts for a set amount of time.

Many users have asked us to make it easier to ban users - frequently an administrator finds that they want to do more than just one of the above actions, and usually against a specific user account who has been causing problems.

IP.Board 3 will help administrators control who can (and cannot) access their board. While all of the above features are still in place and can be accessed individually just as in IP.Board 2.x, there is now a centralized "Ban User" panel that an administrator can use when they are taking action against a specific user account.

When viewing the user account, there is a button you can click labeled "Ban User" (if the user is already banned, the button will read "Unban User"). Upon clicking this button, an AJAX popup window will present you with many options.

Firstly, IP.Board now supports a true "banned member" status, separate from their actual user group. This means you can ban a member without moving them into another group (for instance, if you do not want to upset the user's friends on your board).

The ban management panel will also allow you to move the user to another group (e.g. the "Banned" group included by default with the IP.Board installation routine). You can also ban the user's email address and username right from the popup window.

Additionally, every IP address that IP.Board can find that the user has used will be listed, and you will be able to ban each IP address just by checking the box next to each one.

Lastly, there is a textarea box provided on the popup that will allow you to enter in a note (which saves to the typical user notes area) for future reference.

As a convenience, links to suspend the member temporarily, remove the user's posting rights, and require moderator preview of the user's posts appear in the window, in case you determine you would rather take one of those actions instead.


The unban panel provides exactly the same options, but in reverse, allowing you to move the user back to their normal member group, remove their email address, usernames and IP address from the ban filters, and to remove the banned flag on their account, reversing the changes you just made.


Account management is important to administrators, and IP.Board 3 is taking steps to make such management that much simpler.
  • 14,042 views
bfarber

IPB 3: Styling IPBoard 3

One of the first items we determined for IPBoard 3 was that it was going to ship with a brand new skin. Our current skin has been with us since the first release of IPB2, and the style goes back even further than that. The Pro skin was introduced more recently, but its main intention was to simplify, rather than bring a significant update.

And so, the responsibility for designing and implementing the new skin came to me. This is a huge undertaking, both in terms of scope and sheer scale. The skin is the most visible part of any product; it is what forms your first impression, it is the part you use every moment. In addition, since we have big upgrades to the template system coming (detailed here), every aspect of the skin must be redone, from scratch. IPBoard is a huge application, so this is no mean feat.

Objectives
Before even considering the visual appearance of the skin, I wanted to set down some objectives for it. These are:

- Ensure semantic markup as far as reasonably possible
- Ensure XHTML validation (1.0 Strict)
- Ensure Javascript is unobtrusive

These objectives have real benefits for the modern web. Semantic markup is not only good for screenreaders, but it provides a solid base for skinners. When all stylistic decision is removed from the XHTML, those decisions can now be made in the CSS alone. My goal with the new skin is to minimize the need to edit templates, and semantic markup forms a part of this. The hope is the majority of skins will be achieved simply by editing CSS - I'm sure admins will appreciate how much easier upgrading will be when templates remain largely identical across skins!

Another great benefit of semantic code is that we will now be able to serve a printer-specific stylesheet, and do away with the 'print-view' code in IPB itself.

Javascript
IPBoard 3 is going to ship with the PrototypeJS library. I've always believed that the new generation of Javascript libraries are a big step forward for Javascript usability, so I'm looking forward to making use of them (Nexus beta testers will know we already use it heavily in that product). PrototypeJS allows developers to focus on writing features, rather than fixing cross-browser compatibility issues or poor support for a particular part of the language. We'll be making use of the excellent event-handling capabilities to get as much Javascript as possible out of the IPBoard templates.

Skins shipping with IPBoard 3
Our plan right now is to ship at least 3 skins with IPBoard 3. These will be: the default 'fancy' skin; a simplified skin intended to be used as a base for skinners; and a mobile skin, a lightweight version designed for use on mobile devices. This last skin will do away with the present lo-fi version, and become a full-fledged 'light' alternative, complete with posting, searching and so forth.

Style Guide
To ensure all developers within IPS are on the same track when writing XHTML and CSS, I developed a style guide that we will be using internally. This formalizes the practices we will be using and should help to ensure consistent output. I want to make the guide available to the public partly for review, but primarily so that our modding and skinning community can ensure their code follows our standards too, if they wish. Your feedback and thoughts on the guide are welcome.

IPS_style_guide.doc

Feedback
I'm deliberately avoiding showing the progress on the new skins, but they are underway. Once they are nearer to completion we will begin previewing the design itself. For now, I just wanted to introduce you to our line of thinking and aims for the interface side of IPBoard 3 development. If you have any feedback on things I've mentioned here, or more general feedback about improvements you'd like to see in the IPB3 skin, I encourage you to leave a comment.
  • 9,217 views
Rikki

Advancing the Login Manager

IP.Board 2 included a login manager utility in the admin control panel. Using this tool, you could tell IP.Board to authenticate login requests against third party databases, LDAP installations, or against IP.Converge, for example. You could even write up your own login methods and authenticate against any external data source of your choosing (i.e. the IP.Board 2.3 OpenID module). We used the login manager for conversions too - if you converted from another forum software, our login manager can understand the old password hashing schemes so that you do not need to reset all of your users' passwords (in most cases).

IP.Board 3 takes the login manager even further.

The login forms on the front end are all being consolidated into one template. This will make it easier to ensure that every time a login form is displayed, the same login form is displayed. You won't have to add options to multiple templates, as you did in IP.Board 2, if you want to customize the login form in any way. The login form has also been made "smart". Because you could potentially have a login method that requires a username and a login method that requires an email address, we decided to dumb down the form a little bit. You will be asked for your "sign in name" now (just one field) and IP.Board will figure out if you submitted an email address or a username.

We've removed the option of "passthrough" or "onfail" from the login manager. It is no longer needed, as you can now chain login methods together. For instance, you may want to try to authenticate a user against the local database first (if the account exists), but if that fails, load the member from a remote database. Or you may want to allow a user to login using one of a number of data sources you maintain. This functionality is now possible. The login methods in the admin control panel are reordered using drag-n-drop to make it easy to control which order they are checked in.

Some login methods need extra information from you. For instance, if you use LDAP, IP.Board would need to know the LDAP server host name, your username and password to login to LDAP to check the user, and so on. In IP.Board 2, this information is entered into a configuration PHP file. IP.Board 3 presents this information in the admin control panel to make it easier for you to check and update whenever you may need to.

In IP.Board 2 when a member is added to the local database after authenticating through a remote data source, the member would be required to fill in a display name, and potentially their email address, even if that information already existed in the remote source. In IP.Board 3, there is much more control over this at the login method level - you can pull ANY data you want from a remote source and use it in IP.Board. At the very least, this means if there is an email address and a username available in your remote data source, the user most likely will not be required to visit an intermediary screen before being allowed access to your forums. The name and email will be stored automatically, making for a very seamless login experience.

IP.Converge has received a slight update too - if you have IP.Converge enabled on your board, your users (who have already logged into the forum and configured their account) will now be able to use their username to login (if you enable username logins in the ACP). Behind the scenes IP.Board will find their email address and authenticate through IP.Converge using their email address, but your users won't have to know that.

Additionally, OpenID has being added to IP.Board 3 as a supported login method. If you are not familiar with OpenID, it is basically an emerging protocol allowing you to control your own login authentication. You submit a url to sites that support OpenID (such as Yahoo, Wordpress, Flickr, and AOL) and then you are taken to that URL to verify the request really is from you. You may be required to login to your OpenID provider to confirm what information you are allowing to be sent back to the requester (in this case, your forums). After you confirm this information, you will be automatically logged into your forum. Additionally, as long as the user allows their name and email address to be sent back to the forums, their account will be fully created and functional. IP.Board will support OpenID 1 and OpenID 2 with the Simple Registration, Attribute Exchange, and PAPE extension modules (meaning email, username, date of birth and gender will all be supported and remembered by IP.Board, and that you can supply a policy url to the OpenID provider). Please note that we will be using the PHP OpenID libraries from JanRain for the OpenID backend support.


If you don't need any of this functionality, it won't impact you at all! For those of you who have been requesting it, however, IP.Board 3 should cover all your bases.
  • 4,392 views
bfarber

IPB 3: Making Templating Easier

HTML logic has been a feature of Invision Power Board for quite some time now. Although we didn't make much use of the '<foreach>' tag so that skins could be backwards compatible, we did make good use of the <if> <else /> logic. Now that we have a clean slate with v3.0, we can really make some positive changes.

Invision Power Board 3.0 makes full use of the existing HTML logic and adds some more functionality. This allows for some dramatic customization without touching any of the PHP code. Where possible, each 'view' (board index, topic listing, viewing a topic) has a single template. Previous versions 'stitched' together several templates (as many as 30!) to create a single page view. This meant that some items were fixed and unable to be moved. For example, on the board index, it was not possible to move the board stats above the list of forums. Likewise it was not possible to move the active users below the board statistics.

Now you can. You can move any item to any place for that view without having to edit the PHP files themselves. This will really open up designer's creativity and allow some really unique looking templates.

Another leap forward for Invision Power Board 3 is the ability to use display logic in the templates themselves. Naturally, we were always able to use <if> and <else /> but you can now use the following standard tags:

The Date Tag:
Examples:

{%date="1210012321"|format="manual{d m Y}"%} {%date="-1 day"|format="long"%}
{%date="now"|format="long"|relative="false"%}



For the first time, you can now explicitly specify a date format on a per-use basis. The tag accepts either a unix 'timestamp' or a human string like 'now', '-1 day', 'tomorrow', etc. The format parameter can either be a standard IPB date format (long, short, joined, etc) or a manual PHP Date format.

The Parse Tag:
Examples:

<parse expression="substr( $data['name'], 0, 10 )" />
<parse expression="sprintf( "14", "There are %s apples in the bag" )" />


This parse tag allows you to make on-the-spot parsing using PHP code. This tag is replaced with the value returned from PHP.

The URL Tag:
Examples:

{%url="foo=1&bar=2"|base="public"%}
{%url="foo=1&bar=2"|label="Click Me"|base="public"|id="myLink"|class="linkCSS"|onclick="this.function()"%}


The first example will actually create the entire <a href='' ... >...</a> HTML chunk whereas the second example will only return a formatted URL. The main reason for this tag is to prevent hardcoded entire URLs or even fixing part of the URL to a setting. In IPB 2.3 it wasn't unusual to see this:



<a href='{$this->ipsclass->base_url}&act=login'>Log In</a>

The new method would be like so:



<a href='{%url="act=login"|base="public"%}'>Log In</a>

The 'base' value being 'public' tells the template engine to use the public URL and not the ACP url. The real power of this feature lies in the return value being automatically fed via formatURL() which can return a friendly URL if friendly URLs are enabled.

The Variable Tag:
Example:

<variable key="tdColor" oncondition="$foo == "green"" value="green" /> <variable key="tdColor" oncondition="$foo == "black"" value="black" /> <span style='color:<variable="tdColor" />'>Hello World!</span>
<variable key="tdColor" default="blue" />





In this example, depending on $foo having a value of green:


<span style='color:green'>Hello World!</span>

This tag allows you to decide in the template itself how part of the template should display without having to edit PHP code. This is a handy tag for use in foreach blocks to alternate between colours when showing posts, topics, etc.

Custom Tags
The tags URL and date tags shown above use the {%tag="foo"|param="bar"%} format. These are actually custom plug-ins. You can write your own custom plug ins and they are available immediately within the templates. You could even modify the default plug-ins to change their behaviour.

We're looking forward to how these new tools are used in your own templates!
  • 6,867 views
Matt

IPB 3: Creating a new framework using PHP 5

One of the biggest discussions we had during Invision Power Board 3.0's planning was whether or not to drop support for PHP 4 and require a minimum of PHP 5. The advantages of using only PHP 5 were numerous and we really felt like we could increase security and efficiency by taking advantage of the new PHP 5 features. This decision became much easier when we learned that PHP 4 was no longer being developed.

To really see the benefit of using PHP 5, one must first consider how Invision Power Board's new framework is made possible by PHP 5.

Although Invision Power Board 1 and 2 were loosely based on the 'front controller' design pattern, it had no real framework to hang the code on. The closest it had to one was the 'ipsclass' super-class.

'ipsclass' was a convenient method of transporting various classes and functions around Invision Power Board. Convenient, but not ideal. One had to pass this 'super-class' from class to class forcing PHP 4 to use a reference (and being severely punished when forgetting!). This super-class contained almost all the 'core' functionality of Invision Power Board. Member, input and database objects were attached along with numerous other classes and functions. None of which was ordered in any logical format.

We have recoded Invision Power Board 3.0's framework from the ground up. We have done away with the 'ipsclass' super-class and employed the 'Controller -> Command -> View' pattern. This allows us to quickly add new code and to allow fast refactoring of our existing code. This pattern is built upon the 'IPS Registry'. This is a singleton class which maintains interfaces to several other registry objects (database, request, settings and member). Each of these objects maintains a clear place within the registry. This allows us to pass core data through the different levels of our pattern. Other functions from 'ipsclass' are moved into singtons: "IPSLib"; disparate functions that do not belong elsewhere, "IPSText"; functions for parsing and cleaning text, "IPSCookie"; functions to handle cookie management and "IPSMember"; functions that deal with loading, saving and parsing members. This offers a clear structure with clear boundries for each singleton class. Being singletons, you do not need to pass or reference the class in other files.

Here's an example:

IPB 2.3 Code

$value = $this->ipsclass->settings['board_name']$id    = $this->ipsclass->member['id'];$this->ipsclass->input['f'] = 2;print $this->ipsclass->get_cookie('foo');$text = $this->ipsclass->txt_alphanumerical_clean( $text );print $this->ipsclass->class_forums->build_info();
print $this->ipsclass->input['name'];








IPB 3.0 Code

$value = $this->settings->getSetting('board_name');$id = $this->member->getProperty('member_id');$this->request->setField( 'f', 2 );print IPSCookie::get('foo');$text = IPSText::alphanumerical_clean( $text );print $this->registry->getClass('class_forums')->build_info();
print $this->request->getField('name');








It's worth noting that we have also applied the ArrayAccess interface to the registry, so you may access them like so:

$this->settings['board_name'];
print $this->request['name'];


Although the code examples use $this->request, $this->member, etc, these are set up in a constructor. You would pass the IPS Registry singleton into the class. Here's a typical constructor:

{    $this->registry = $registry;    $this->member   = $registry->member();    $this->request  = $registry->request();    $this->settings = $registry->settings();    $this->DB        = $registry->DB();}
function __construct( ipsRegistry $registry )








You could also access the ipsRegistry class directly, although this is strongly discouraged:


print ipsRegistry::instance()->request()->getField('name');
PHP 5 offers a much better OOP (object orientated programming) environment where references are assigned automatically. You can also chain along functions, which we make great use of. This allows us to do some neat trickery, like so:

IPB 2.3 Code

print $this->ipsclass->compiled_templates['skin_boards']->board_index( $data );
$this->ipsclass->load_template('skin_boards');


IPB 3.0 Code


print $this->registry->getClass('output')->getTemplate('boards')->board_index($data);

You'll note that you no longer have to implicitly load the template anymore. This is handled within the 'getTemplate' function if it's not already loaded. This object is then returned for use to chain onto 'board_index()'. This simple adjustment of code makes for less manual code and less room for error.

We are also making great use of PHP 5 abstract classes and interfaces to define extensible classes. This will make it much easier and clearer for others writing their own additions to Invision Power Board. Having a clear interface to work with will reduce errors in development and formalize how you may access Invision Power Boards class structures.

The 'controller -> command' structure is built so that you may add new modules and sections dynamically without the need to change a single line of code elsewhere in the script. Modification authors can just drop in new folders and Invision Power Board will run them when called correctly via a URL. The controller makes use of variables in a URL and safely loads a command file if a matching command file is located. For example: "appcomponent=core&module=global&section=login" is mapped to "applications/core/modules_public/global/login.php". We make use of the Reflection class functions to ensure that any potential command file is a sub-class of the controller to prevent the risk of tampering.

We've barely scratched the surface, but it's clear that Invision Power Board 3's framework is very powerful and code-efficient. This is only made possible by the advancements in PHP 5 that we've taken full advantage of.
  • 8,352 views
Matt

IP.Board 3.0 Development Introduction

We are moving rapidly on IP.Board 3.0 development along with its related IP.Blog, IP.Gallery, and IP.Downloads updates. As we approach being able to post these updates for a preview and an eventual release we think we are getting close enough that we can start talking about some of the new features we have planned.

I will be purposely vague in this first blog entry about IP.Board 3.0's development and let our development staff get into detail in future blog entries. While not promising a set schedule, you can expect an update from a developer almost weekly going into detail about a specific change or new feature.

Our full new feature list is very long but here is a sampling for everyone. Our development team will go into detail about each one in the coming weeks and also introduce all the other additions not mentioned in this introduction.

Interface
There will be a great focus on usability and streamlining functions. The introduction of a new template engine which allows for multiple default template sets, easier skin editing, and a brand new default skin is something we are very excited about. Search engine friendly URLs will not only make your community more interesting to search engine spiders but allow for more human-friendly linking.

Control
The overhauled BB Code manager along with moving all default BB Codes to the system so you can edit them will allow forum administrators greater control over how their users interact with the community. We are implementing greater configuration options including being able to turn off features you do not use and finer controls on current features. Finer tuning your user signatures, turning specific options off, or even removing entire sections such as the calendar will allow you to gain finer control of how you want your community to be presented.

Features
There will be quite a few new features but, for now, we will save those for our upcoming blog posts to reveal what's new. A quick sampling: user reputation system, more permission configuration options, moderator enhancements, and ... lots more.

Integration
We want you to integrate your community with the rest of your web site with minimal effort. To make this easier for you, we will be putting great focus on creating a new hooks system for developers, more advanced APIs, content syndication, login methods, and more. Our applications (IP.Blog, IP.Gallery, and IP.Downloads) more tightly integrated with each other and with IP.Board itself.

Coding
There will be a lot of low-level code improvements which will make working with our codebase much easier for our community of developers. Everything we do will be with an eye toward resource usage improvements to make our software lighter on servers.

Server Requirements
To take advantage of many new capabilities, we will be officially dropping support for PHP 4.x series and requiring a minimum of PHP 5.x for our software. The software will work on the MySQL 4.x database series but we will highly suggest using the MySQL 5.x version.

Oracle Database
Due to slowing demand over the past few years, we have decided to discontinue supporting Oracle database system. We will continue to support MySQL and Microsoft SQL Server.

Subscriptions Manager
Again, due to slowing demand, we have decided to stop updating the subscriptions manager in IP.Board. We will be fixing all current known bugs to make the system compatible with IP.Board 3.0 so those currently using the subscriptions manager will still be able to upgrade. Anyone currently using the subscriptions manager will still be able to upgrade and everything will work normally for you. From there, we will be looking for community developers to keep it up to date. We will be posting a blog entry when ready to ask for assistance in keeping the subscriptions manager up to date. Anyone wishing to use our new IP.Nexus commerce system when it's available will be able to migrate as well.



Of course this is just the short version. Keep an eye on our blog for more detailed updates and new feature reveals in the coming weeks. And finally, when will it be released? Right now we are thinking the fourth quarter of 2008 (IP.Board, IP.Blog, IP.Gallery, and IP.Downloads will all receive a new version at the same time) but of course that's subject to change... it could very well be sooner...
  • 7,699 views
Charles

IP.Blog 1.4 Preview

We've upgraded our blog to the new 1.4 version for the first round of testing. We will have a beta version available for download next week, until then enjoy the new version here and let us know what you think. We're very excited to hear your feedback and suggestions on this blog preview!

New Default Style

IP.Blog has been overhauled with a fresh new style, one which feels more like a traditional blog. Additionally, it has been designed with themes (see below) in mind, so there is plenty of room for theme authors to experiment in their designs.

Themes and Custom Headers

You can now install 'theme packs' and allow your users to choose which of these themes will be applied to their blog. Using themes you can completely change the look and layout of an individual blog (to see a demonstration of a theme in use, check out Rikki's blog). Users are also able to create their own unique theme, these user themes must be approved by an adminstrator before they are publically viewable by other users. The new custom header system allows you to create multiple header images for users to choose from.

Content Block Plugin System

It's now much easier to create your own content blocks, using a new plugin system. It's now possible to define settings for a plugin that apply to individual blogs, this means that you can integrate with 3rd party widgets that require a unique username for each blog. We've also included new content blocks in this release: Twitter, MyBlogLog, Google Reader, Friends Blogs, and Recent Visitors.

Social Bookmarks

A new bookmark manager allows you to define bookmark services for your blog system. These services will allow blog entries to be easily submitted to the bookmark services that you setup. There are several preconfigured services: Del.icio.us, Digg, Facebook, Mixx, Reddit, and Stumbleupon. Please feel free to suggest any services that you would like to see included by default.

Media Integration

The new tag allows you to automatically convert various media types into a more useable format. FOr example, [ blogmedia ]http://www.test.com/somemp3.mp3[/ blogmedia] would be converted into a mp3 player for the specified file. You can define any media type you like in the Media Tag manager, by default we include: Flickr Image Set, GameTrailers, Google Video, MP3 Player, MySpace Video, Veoh, and YouTube. Please suggest any additional media tags that you would like to see included by default.

Akismet Integration

It's now possible to use Akismet to filter spam for both the comment and trackback system.

Feedburner Integration

Users can now override the default rss syndication and use FeedBurner.

Other Changes:

Edit Entry Date Display article count for categories Blog Offline Mode Entry author replies in comments are now highlighted Admins can select a 'Featured Entry' to be displayed on the blog listing
  • 5,295 views
Josh

IP.Blog Status Update

We plan to release a small update later this month, with a slightly refreshed style and a few extra features. We haven't locked down exactly what these features will be, but we will be talking about it more soon. I know that many of you were expecting a larger release and we apologize for the link of time from the last major update to IP.Blog. The larger update is coming, which will be IP.Blog 2, is coming and will release along side IP.Board 3.

We plan to have a beta of 1.4 available in the next two weeks, it's not too late to suggest in minor tweaks and changes that you would like to see included in this release.

We're very excited about the future of IP.Blog and have many new features planned for version 2 and we thank you for your patience during this development time. We'd love to know what features you are most interested in for the next major release, now would be a great time to post those suggestions in the IP.Blog forum.

IP.Blog 2.0 Discussion
IP.Blog 1.4 Discussion
  • 2,265 views
Josh

OpenID Login Module available for testing

We have put together a login module which fully supports OpenID 1.x and 2.x protocol specifications.

This module is a beta release which we hope to expand upon. It is available freely to all customers with access to our official resource site in the IPS Releases category.

Click here to view this file

For those not familiar with OpenID, it is a protocol specification that allows a user to select a trust root (a site they can trust) and register. Then, on any site that supports OpenID, the user actually logs in through their trust root, instead of your site. Behind the scenes, your site and the trust root verify that the user is who they say they are, and if authenticated your site will allow access.

More information on OpenID can be found at openid.net (official site) and on Wikipedia.

This module only adds OpenID Consumer support - it does not add OpenID Provider support.

Please remember - this is a beta release of the login module, and as such there may be bugs or other issues with the module. If you are interested in using this login functionality you should test it out on a test site before applying it to your live site, to be certain there are no issues. As with any modifications, IPS does not support this modification directly. If you have issues with the module and require assistance, you should leave a comment on the file's download page.
  • 4,339 views
bfarber

Nexus and Dynamic Legacy

For those of you who have been with IPS for some time you may have been aware of a previous announcement regarding the development of two separate products called Nexus and Dynamic. Nexus was to be an ecommerce billing system and Dynamic was to be a content management system.

As we developed these products the Internet market had changed quite a bit so we have made the decision to totally discontinue Nexus and Dynamic production as they were. We know many of you were looking forward to either Nexus or Dynamic as they were first intended and we apologize if this disrupts your plans.

Instead we have decided to create a new product that combines the previous goals of ecommerce and content management along with a host of features including customer management, support, business organization, and a modular structure in which features are only limited by our imagination.

Since everyone at IPS loved the term "Nexus" to describe this system we decided to recycle that name and so IP.Nexus was born. IP.Nexus is a complete business management suite which includes many of the previously stated goals along with so many more. We look forward to releasing this new product line.

It is worth noting that this time around the new product is nearly complete rather than an idea in development. Expect a lot more information including the first public betas in the coming weeks! Watch our announcements forum and this blog for more information.
  • 4,744 views
Charles

Our next community project: Gallery Uploader Tool

In part due to the awesome success surrounding our first community-supported project, we are in initial stages of preparing our next Community project.

As many of you may already know, Stewart had been working for some time on a Gallery uploader tool - an application a user could install on their computer to easily manipulate and upload multiple images to an IP.Gallery web installation. Stewart made great progress on the tool before he left, and while we do have employees here capable of programming in the C# language the tool is written in, we felt this would be another great opportunity to launch a community-supported project, similar to IP.Tracker.

We would like to gather up a handful of members who are familiar and able to code with C#, and who are interested in working on this project for IP.Gallery, so that we can put the necessary final touches on the project and release it freely to the community at IPS Beyond.

The applicants will need to work closely with me, as a heavy part of the project will involve php code necessary to interact with IP.Gallery. Additionally, any users who are also versatile in perl (or a similar CGI language) could be of use in overcoming many of the php limitations we commonly face (maximum file upload sizes, maximum execution times, and so on).

If anyone is interested, please send bfarber a PM with some background and how you think you will be able to help. I cannot guarantee immediate responses to everyone, and almost certainly not everyone will be chosen, but we look forward to hearing from anyone interested.
  • 3,295 views
bfarber

IP.Gallery 2.2

While IP.Gallery 2.2 has not yet been released at this time, I wanted to take a moment to outline a few of the new features and touchups in Gallery that may not be as evident.

A strong focus for this release of Gallery was strengthening the backend - many Gallery users know that some core functionality was just missing and it was time to bring Gallery in line with the rest of our offerings. For example, users could not control the ordering of their albums, nor could moderators move images from/to albums. This has all been fixed. Additionally, Gallery has been updated to use IP.Board's caching methods to help reduce the number of SQL queries run on each page, and it has been moved over to a component for forward compatibility reasons.

Arguably, it's the little things that make or break Gallery software. You have to strike the right balance between the image (which is of course the main focus in a Gallery) and the rest of the content. We streamlined the image view page considerably to help make the image viewing more pleasant and less distractive. The exif/iptc data that can be extracted from images was moved into a popup/movable div so it doesn't display directly on the page. The edit/delete/etc. links were put into a single dropdown to reduce the number of buttons below the rest of the data. Here is a screenshot showing the drop down and the popup together



Another frequently requested feature was easier ability to hotlink images.



And of course the "Set as Avatar" has finally made it's appearance via an "Avatar" button next to the Options button.

Other small but important changes involve navigating the Gallery, which many users requested be simplified. We've added some things to make this easier for users. Firstly, at the top right we've added "First, Previous, Next, and Last" links which will take you to the respective images inside the container you are viewing.



Additionally, in the photostrip at the bottom of the page, there are << and >> buttons added (as appropriate) to allow you to cycle through the photostrip using AJAX. This can help you get a quick overview of the images in the container, and be able to jump to an image in the container easily. Go ahead, visit an image inside the IPB Community Personal Photos and try the AJAX navigation.



And of course, one of the more noticable changes is support for lightbox in the Gallery. For an example of how this works, view this page and then click on the image. This of course can be disabled if the administrator wishes.

There are many other important updates naturally, with some more notable changes being

Drag-n-drop support for reordering post form fields and categories Custom post form fields now automatically insert into the image view page and submission form Ability for admins to deny ability to members to create private albums Zip import support for members ACP language abstraction Slimmer templates for easier skinning Forum-style listing for albums Improved search capabilities Email notification options for comments and image submissions Image dimensions display on the image view page And many other smaller things you will have to find out when you install or upgrade your very own Gallery!
  • 2,765 views
bfarber

Resource Improvements for 2.3

One of the driving focuses for IP.Board 2.3 was resource usage. We wanted to spend some time on improving the underlying operation of IP.Board, even if this meant not adding a lot of new features on the surface. As with most applications that develop beyond a few releases, over time so many features have been stacked into IP.Board that, while not necessarily ineffecient, we felt we could revamp some of the underlying code to make IP.Board run even better.

We wanted to highlight a few of these changes for those who are interested.
The parse_member method of topics.php has been moved to ipsclass.php to make it more centralized, as it's used by many various classes in IP.Board. Similarly the member_set_information method out of profile.phpand into ipsclass.php as well. We've added a new feature that allows skin template bits to be shared across different skin files. With 2.3 you can now simply edit the some template bits and automatically update all skin files where those bits are used. There are several template bits making use of this functionality to help reduce the number of skin files loaded on any given page view.

If you would like to make use of this functionality (for example, with a custom modification), you can select to share a template bit to another skin file by going to Look & Feel -> Edit Template HTML for the skin -> (Select a skin group) -> (Select a template bit). Click the drop down button where you would normally edit the template's incoming data variables, and hit "Edit Cache Settings". You can select (or review) secondary skin cache files that will share the template bit you are viewing. We've added a few more database indexes based on our analysis of some common database queries that IP.Board runs. With 2.2, we introduced the new profile portal functionality in IP.Board. This uses an iframe to load center content, which requires a second call back to the server to load the center column content. In 2.3 we've pre-loaded the first tab's content to prevent this second request (on the initial profile page load) from being required. For 2.3 we've added a setting in the Admin CP under CPU Saving and Optimization labeled "Use multi-byte safe wordwrap". International users can continue using the word wrap function more suited to matching 2 and 3 byte character sets, while users with only English text on their forum can use a much more effecient word wrapping function that doesn't need to take multi-byte characters into account. We've also added a setting in the Admin CP under CPU Saving and Optimization labeled "Disable Topic Summary". Setting this to Yes will turn off the topic summary displayed at the bottom of the Add Reply page. This setting is Off by default (the summary will still display unless you turn it off). We've disabled the custom error handler by default in IP.Board 2.3, which prevents our custom error handling function from being called with every PHP Notice (which are not displayed). If you'd like to revert this functionality, just edit init.php and change

define( 'CUSTOM_ERROR', 0 );
to


define( 'CUSTOM_ERROR', 1 );
We've optimized our post parsing routine by preventing two expensive usort calls from being required, as they are already run when the associated data is saved in the admin CP. We've enhanced our MySQL database driver when doing field_exists and table_exists method calls byUsing a 'SHOW FIELDS' query rather than a 'SELECT COUNT(col)' query to determine if a database field exists We cache the fields in a table, and the tables in a database, the first time a field_exists or table_exists query is run to prevent having to query the database for the same data later during script execution Announcements, Private Messages, Calendar Events, and Topic Posts are now parsed entirely on save, rather than when displaying the data (or in the case of topic posts, half on save and half on display). This prevents the parsing from running on display, and prevents having to load several parsing libraries and associated caches when displaying the data. We've enhanced the rebuild posts tool to also support private messages, calendar events, and announcements for users who will upgrade and need to rebuild the content (to parse html and custom bbcode appropriately). Rebuilding posts will be necessary after upgrading in order to ensure all custom bbcode is parsed, however upon doing so we will be saving many resources at run time, which is by and far a more important consideration.

I hope this helps detail and clarify some of the resource improvements made for 2.3. The good news is that if you didn't notice any of these things already here on the company forums, then our changes are working exactly as we had hoped - same surface functionality, a much stronger backend to handle it.
  • 2,908 views
bfarber

IP.Tracker Now Available

We're pleased to announce that the first release of the bug tracker, now known as IP.Tracker, is available for download at IPS Beyond. We'd like to thank Michael, C_ind, and Krocheck for doing such a great job getting this first release available. We'd like to encourage everyone to stop by the tracker forum and post your feedback, as well as submit your own code for inclusion into IP.Tracker.

Download Link: http://www.ipsbeyond.com/forums/index.php?...p;showfile=1043
Support Topic: http://www.ipsbeyond.com/forums/index.php?showtopic=22774
Suggestion Forum: http://www.ipsbeyond.com/forums/index.php?showforum=76

We're very excited to see how the Tracker will evolve and plan on creating more projects like this in the future.

Please note that this free module is not included in your IPS support, if you need any assistance please use the support topic linked above.
  • 3,912 views
Josh

New Supported Skins

As many know, we are in the process of revamping IPS Beyond. Along with that, we will be offering many more supported resources from IPS.

The first will be a new supported skin that will be offered as a secondary default skin to the board. This first skin will be designed as a very basic skin (no gradients for example) thereby allowing for much easier color changes and such when you want to match it to your site. As a supported skin it will be updated between versions of our software.

We will be previewing the new skin on our company forums in the next few days and it will be available along with IP.Board's 2.3 release.
  • 2,554 views
Charles

Food Good

We just wanted to thank BoxerPals (http://www.boxerpals.org) for sending us that lovely box of cookies and fudge. You know how to go straight to our staffs' heart.

We occasionaly get thank you gifts from customers and it's always appreciated.
  • 2,013 views
Charles

Bug Tracker Update

I have a quick update for you on the bug tracker project now. I'm happy to announce that Michael and C_ind of IPS Beyond will be leading the bug tracker project. They both have a great track record and have been a huge benefit the the IPS Beyond community and we're very pleased to have them working on the bug tracker. We'll be delivering the code to them tomorrow, and then work will begin on getting the bug tracker into a releasable form.

They'll work on cleaning up what we have and getting an initial release out to the public. From there everyone will be welcome to submit code contributions to them and they will decide to include them or not. I know they have a lot of great ideas themselves, which I'm sure they'll post about soon.

We'll have more information on this soon, if you have any questions please ask in the comments and we'll do our best to answer them.
  • 2,905 views
Josh

Free Bug Extermination

One of our major goals is to support our modification community and today I'm excited to tell you about a new venture to help the mod community. As many of you know we have our own internal bug tracker that we use on these forums. We've had numerous requests to release it and now we're ready to do just that, at no charge to our existing customers. The bug tracker will soon be released to IPS Beyond for everyone to download.

This is going to be a unique project for us, we're going to have the IPS Beyond community run the bug tracker project. We'll be selecting a few IPS Beyond members to help us manage this project, they'll be responsible for reviewing and integrating community code contributions. Everyone will be welcome to submit a code contribution for approval.

We're really excited about this project and hope that all of you are too. There will be more details coming soon, such as license, availablity, and who will be heading up this project. We're still considering people for this, if you're intersted feel free to email me at [email protected], please include both your IPS Forum user name and your IPS Beyond user name. Please note that I may not be able to respond to everyone, but we do appreceiate anyone that offers their assistance.

This is just the first in a string of changes to both IPS Beyond and IP.Board that we hope will further energize our already great modding community. Keep checking this blog for news on future changes, they aren't far off. We'd also love to hear your feedback on this and any suggestions you have, please leave a comment and let us know what you think!
  • 2,472 views
Josh

Brandon Farber is now a ZCE

Zend, the company that makes the PHP engine, offers certification for users who are interested in measuring their PHP expertise and qualifying their PHP skill level. From Zend's FAQ:





http://www.zend.com/education/zend_php_cer...tion/faq#root_4

You are tested on your fundamental knowledge of the PHP language, as well as various classes used in PHP and design patterns PHP developers should be aware of.

I took the certification test this past Monday and passed the examination. I am now officially a "Zend Certified Engineer".

  • 3,861 views
bfarber

Evolution of a Feature: The Attachments System

A lot of the time a significant portion of development time is spent working on items that the end user will never get to see. A case in point is the attachments system.

The attachments system was introduced back in the early days of IP.Board. During the development of IP.Board 2.2 the attachment system came under focus for two reasons.

The first reason was that we were already testing the 'new' attachment system in IP.Dynamic (as shown in this movie) and we wanted to introduce that into IP.Board. The original system forced one to wait for an entire page reload before continuing with a post. The new version used a fancy concoction of javascript and iframes to upload data 'inline' - that is, without a page reload. Naturally, AJAX (XMLHttpRequest) would have been an obvious choice but it is impossible to upload data using current XMLHttpRequest methods.

The second reason was that the code was due an overhaul because it was originally developed long before we had our components system in place. This made the original system inflexible and not very extensible. Infact, Remco had to maintain his own attachments system for the IP.Blog component which duplicated PHP code, HTML templates and SQL information.

With this in mind, we abstracted the code into component friendly modules. This allowed one to simply create a new module to manage the component's settings and upload paths. The main attachment class handled the rest. This saved us a lot of code re-use and allowed us to store attachments from several components in one table.

We think the new interface alone is a marked improvement over the old system. It's much quicker and allows one to upload several attachments quickly.

We have plans to further abstract the attachments system in a later version of IP.Board to allow attachments to be saved and retrieved in different formats.

This rather minor feature really highlights how new web technologies and ways of thinking can push even a secondary feature further along and how we're always looking to improve the efficiency of IP.Board and its components.
  • 2,144 views
Matt

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.