• IPS Hosting clients
• IP.Board Standard License
• IP.Board Business license
• IP.Board Community Suite license
  

<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!

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
  

/** * 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.

During the latter stages of IP.Board 3.0.0's development, we added in very basic status updates in users profiles that was further enhanced by the index page sidebar hook. We've seen this feature get a lot of use on our own community and we wanted to take it to the next logical step and allow archived statuses and status replies.

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!

http://yoursitehere.com/forums http://yoursitehere.com/forums/index http://yoursitehere.com/forums/index.php http://yoursitehere.com/forums/index.php? http://yoursitehere.com/forums/index.php?act=idx

http://yoursitehere.com/forums/

There are many other variations that will do the same. But which one is correct? How can a spider know which version to index, or should it index them all? At the end of the day, they are all different urls, and can potentially be treated differently by a search engine spider. With dynamic software, such as IP.Board, it is often difficult to ensure that the URL used to reach a page is the "correct" version and to redirect appropriately. It is not difficult, however, to tell a search engine which version of the URL SHOULD be used. When a search engine reaches the board index page in IP.Board 3.1, through any URL listed above, or any other variation not listed, the canonical tag will instruct the spider to use one specific version of the URL for that given page. This will help consolidate inbound link weight to the single/correct version of the page, and consolidate duplicate results in search engine listings to the single/correct version of the page.

More improvements for the board index

Many users have requested that we provide a way for them to specify the page title to be used on the board index page. The board index page is going to be the most important page of your forums (in the eyes of a search engine spider), and having complete control over the page title is important. Prior to IP.Board 3.1, the "Board Name" setting was used for the board index page title. This works well for many users, however it is also appended to the end of the page title for many other pages, so depending upon your specific needs, you may want to use different text for the two locations. IP.Board 3.1 has a setting to allow you to change the page title for the board index page specifically. If left blank, the board name will be be used, just as with previous versions.

Additionally, we have added settings to allow you to specify the meta keywords and meta description tag values in the new Search Engine Optimization setting group mentioned earlier. The end result is that you now have much more control over SEO aspects of your board index, arguably the most important page of the forums for search engine spiders.

De-emphasize unimportant pages

IP.Board 3.1 will now issue a meta robots tag with the value "noindex" for some common non-content pages. Examples include the login page, the register page, and the lost password request page. The purpose of the tag is to suggest to the search engine not to index the page at all. Every IP.Board installation on the internet will have effectively the same login, registration and lost password pages, and these pages have no valuable content that search engine spiders want to index anyways. By de-emphasizing unimportant pages, more emphasis is placed on the content-heavy pages we want search engine spiders to spend their time on.


Wrap up

We've got some more feedback and suggestions we would like to take into account and implement in a future version of IP.Board, however we feel that for 3.1 we've taken the most important changes that do not require many invasive core changes to the software and implemented them in a manner that will benefit customers the most. We are working hard to ensure we've done our part to help your forum stand out from the crowd, and are confident that the changes made to IP.Board will have actual, useful benefits to your forum with regards to search engine indexing.

• IP.Board 3: Friendly URL Enhancements
• IP.Board 3.0 Search Engine Optimization
• IP.Board 3: Friendly URLs at last!
  

• Capitalize all letters
• Lower-case all letters
• Capitalize just the first letter of the string
• Capitalize the first letter of each word in the string
• Remove excess punctuation

• TinyMCE
• CKEditor
• CodePress
• EditArea
• (None/default textarea)

• You can now submit multiple files at one time per file record.
• You can now submit multiple screenshots per file record
• When submitting links you can identify a link "type" (i.e. a mirror, for instance)
• Due to the improved file uploading process, a progress bar is now shown for all files uploading