Mark

That isn't an error that should happen - it occurs from an exception being caught in the multi-redirect code, in this case somewhere along the line it's trying to access the contents of a file which doesn't exist - which may indicate there is an error in uploading the image. I would recommend contacting support to help you resolve that issue - a log is written with more information if that error occurs, so the support team will be able to look at your logs to get a better idea of what happened there.

We don't have a list - the error codes are just so we can do a search of the code and find it easily. We try to make the error messages themselves provide as much information as necessary. If you post the code here though, I can look it up for you.

Everything should transition fine (though note that posts convert in the background after upgrading). I would not recommend running those queries, some are far too broad in scope and many will interfere with the correct converting of post data.

If, after upgrading, and posts have finished converting, you are experiencing issues, please submit a support request so we can figure out what's happening and include a fix in the software itself if necessary.

If you're a developer, you can also use the GPS of mobile devices quite easily (we actually use this in IP.Nexus to make the address input field autocomplete, you usually only need to enter your house number and it knows the rest), though I wouldn't recommend it for things like location-based advertising.

With GPS location, it requires both the user to have GPS-compatible hardware, and them to specifically allow access. While that's fine for specific cases, most users aren't going to allow access to their precise location unless they know what you want it for. And for things like location-based advertising, getting it based on their IP is specific enough (I assume you're going to do ads based on their country, or maybe state, but you're not going to show different ads to different streets, presumably ).

The methods available are:

/* IP address */
IPSGeoLocation::getByIp( $ipAddress );

/* Latitude and longitude (such as returned by the GPS) */
IPSGeoLocation::getByLatLong( $latitude, $longitude );

/* Manually */
$geolocation = new IPSGeoLocation;
$geolocation->addressLines = array( '123 Fake St.' );
$geolocation->city = 'City';
$geolocation->country = 'US';

So, if you wanted it, it's there. You'd just need to write the JS to ask the user for permission and post the values (which is just a couple lines of JS).

IP.Nexus is designed to give administrators the tools to monetize their community. Not only is this about selling products and services (or accepting donations) but promoting your site as well.
Many customers have asked us about a referral system. Until IP.Nexus, there would have been little incentive for members to use such a system. With IP.Nexus, not only can members refer their friends using banners you create, but they can receive commission on products and services that members they refer purchase through IP.Nexus.


You can enable referrals and configure the commission percentage in the Admin CP.


You can also set up the banners that members can use.

If you don't set any up (or in addition to any that you do), a simple text link will be available.
Banners can be uploaded images, or you can supply an image URL.


In the Client Area, members can view all the banners you've set up and the HTML and BBCode to display them.


If somebody then clicks a banner posted on a website by one of your members and registers on your community, IP.Nexus will create a link between the two members.
If that member then proceeds to make any purchases, and you have defined a commission percentage, IP.Nexus will award commission to the referring member in the form of account credit (we will discuss account credit in a future blog entry).

The customer page in IP.Nexus indicates who a members was referred by and any members they have referred. In addition, you can see how much commission a members has earned through referrals:

View full blog entry

Not only can IP.Nexus be used to sell specific items on your community. IP.Nexus can accept open donations targetted to any number of goals.

Please note that the interface shown in the screenshots is not finalised and subject to change.


A donation goal can be open-ended, that is, it has no target. For example, a personal community could accept donations towards the cost of maintaining the site. A donation can also have a specific target amount if you are asking donations towards a specific total.


Donation goals can be managed in the Admin CP.

When creating a goal you specify a name, description and if desired, a target.
You can create as many goals as you like.


Users can then donate towards goals in the User CP.

As you can see, all goals are listed and a progress bar is shown for goals that have specified targets.
To donate, a user simply enters in the amount they wish to donate and they are taken straight to the payment screen.

After payment, the user is shown a thanks page where they will see the progress meter again:

View full blog entry

There are many areas of IP.Nexus which the user needs to be able to manage: past orders, active purchase, support requests, etc.

We decided, rather than trying to shoe-horn these features into the User CP, which was not really designed for such functions, to create a new "Client Area", specific to IP.Nexus.
This is what it looks like:

In this blog entry we'll be talking about the "Purchases" and "Invoices" sections of this Client Area.


Purchases

The "Purchases" section (shown above) will list all active purchases on your account.

Clicking the "View Info" button takes you to an overview page for the purchase:

Here you can update any custom package fields if the field allows you to do so (fields can be set to not be editable after purchase if you desire).

If the item has renewal terms and you are within the time you are allowed to renew the package, you can click "Renew Now" to renew. Doing this will take you straight to the payment screen, and once paid, the expiry date will be updated.

If the package is part of a group which allows upgrading and downgrading, you can click the "Change Package" button to do so:


Depending on your settings, upgrading may be free or they may be charged the difference, and if downgrading, they may be refunded the difference - exactly what will happen, along with the new renewal terms is shown for each selection.
If the user must pay the difference to upgrade, they will be taken to the payment screen and once payment clears, the package will be changed.
If the user is to be refunded the difference when downgrading, it will be applied as credit on their account (we will discuss account credit in a future update).


Invoices

This is what the Invoices screen looks like:


As you can see, invoices are separated into tabs:
Pending invoices are orders which the user has started but not finished or cancelled, or have been generated by the system (for example, when a package is due for renewal) or have been generated by an administrator.
Paid invoices are past orders which the user finished successfully.
Expired invoices are previously pending invoices which have now expired. The user can still pay expired invoices, but the service they relate to (for example if it is a renewal invoice) would have deactivated.
Cancelled invoices have been cancelled by the user or an administrator.

You can click on an invoice to view details:


If the user can pay an invoice, they will see the "Pay Now" button which will take them to the checkout page (which we discussed previously in this blog entry).
If the user has credit on their account, they will also see an "Apply Credit" button which will allow them to use their account credit against the invoice total.



This concludes the Invoices and Purchases area of the Client Area. We will be discussing other areas of the client area in future blog entries.

View full blog entry

In a previous blog entry we covered the ordering process for both the end user and administrator, but of course administrators can generate invoices manually. In this blog entry we're going to be demonstrating the how administrators can manage and generate invoices for users.

Please note that the interface shown in the screenshots is not finalised subject to change.



Managing Invoices

There are two ways you can view invoices, and we imagine most administrators will either use one or the other depending on the size of community.

Firstly, you can view all invoices in a list with the most recent invoices first. We imagine this will be useful to smaller communities.


You can also view the invoices for a particular customer from the customer page. We imagine this will be more practical for larger communities.

The customer page can be accessed either from a link in the normal "Edit member" Admin CP page or the Customer search page in the IP.Nexus section of the Admin CP.
We'll be discussing all of the features of the customer page in a future blog entry.


This is what the invoice details screen looks like:

As you can see, it lists each item in the invoice and any transactions related to the invoice.

It also shows information on the status, and if the invoice has been paid it will indicate the date that it was paid, and any additional information that may be necessary:






Generating an Invoice

You can of course generate an invoice manually for a customer. You do this from the customer page by clicking the "Add Invoice" button that is there.

You will see a screen like this:



You can add an item by clicking the "Add Item" button. This will bring up a dropdown menu with the different types of item you can add:

You can add a normal package by selecting the package from the packages you have created:

You can create a custom package:

You can add a miscellaneous charge (for example, a shipping cost or discount):

And if you have IP.Downloads integration enabled, you can add a paid IP.Downloads file:

(Note that if you have lots of files you will see a search box to enter a filename rather than a dropdown of all paid files).

You can also add a renewal for any of the user's existing purchases by clicking the "Add Renewal" button:


After adding each item, you'll be taken back to the first screen:

From here you can edit the quantity of any item (the price will be updated automatically by AJAX and taking into account any bulk discounts you have set up) or remove an item.

Once you're done, clicking the "Save" button at the top will generate the invoice. If you selected the invoice to be pending, the user will receive an Email notifying them an invoice has been generated, and if you selected the invoice to be paid, the packages will be added to the user's account straight away.

View full blog entry

In our last IP.Nexus Dev Update, we demonstrated the storefront and checkout process for the end user. In this blog entry, we're going to show you some of the Admin features for processing orders.

Please note that the interface shown in the screenshots is not finalised and subject to change.


There are two stages to processing an order:

• Approving the transaction
  IP.Nexus can automatically process transactions that the payment gateway reports as successful. Some users may wish to set all transactions to be manually approved for extra security, and in some cases, transactions may also need to be manually approved if the payment gateway reports a problem.
• Shipping the items
  If a user has purchased physical items which needs to be shipped, a shipping order will be generated to let you know what items need to be shipped and who to ship them to. If a user makes an order with multiple items using different shipping methods, multiple shipping orders may be generated.

Some orders of course may require both of these steps and some will require neither, depending on your configuration and what the user purchases.

On the Admin CP Dashboard you will see a notification if there are any pending transactions or shipping orders:

This uses the IP.Board Admin CP Dashboard Notification Center which was added in 3.1.


Approving Transactions

You can view all transactions that are awaiting your approval on a page in the Admin CP:


From here you can approve a transaction by "View" link or mark it as paid or failed by clicking the appropriate icon.

The transaction details screen looks like this:

You can see details about the transaction, the invoice it corresponds to and the reason it is pending approval.

After a transaction has been marked complete, the details pane will show a message indicating who did so:



Once a transaction has been approved, the invoice it is associated with will be marked paid and any purchases the user has paid for will be activated.
If the order includes any physical items, a shipping order will be generated at this time.


Shipping Orders

You can view all shipping orders that are awaiting your approval on a page in the Admin CP:


You can view a shipping order by clicking on the link. The details screen looks like this:

As you can see, the shipping address and items to be shipped are listed.

Once you have shipped the items, you can click the button in the top right to mark the order as shipped. This will send a notification to the user that the items have been shipped and archive the shipping order.

View full blog entry

In our previous blog entry, we covered how to create packages in IP.Nexus. This blog entry will cover the storefront and ordering process for the products that you sell.


The Store

The front page of the store looks like this:


The front page allows users to view products items (you can configure which products are featured in the Admin CP) or the most popular (i.e. most sold) products.

Users can navigate the store using the category menu on the left. When you navigate into a category, it opens a tree with subcategories.


The bar on the left shows the products currently in your shopping cart, including any tax and discount costs.


As discussed in a previous blog entry, you can configure products to have custom fields or associations with other products. When adding these products, you will see a screen like this:



Viewing Your Cart

After adding an item, or by clicking the "Edit Cart" link the sidebar, you'll see a page like this:


As you can see, you can edit quantities for products which do not require custom fields by entering a new number in the box (or remove all of that product by clicking the remove link). For products which have custom fields, each item is listed individually, so you can remove the one you want.


Checkout Process

The checkout process is only available to registered members. If a guest clicks "Checkout" on the store, IP.Nexus will remember their cart and direct them to the registration screen. After registration is complete, when the user logs in, IP.Nexus will redirect them to the checkout page.

All steps of the checkout process have a cancel button that the user can use to cancel the purchase.

Clicking checkout from the cart screen, the user will be asked to enter their shipping address:

Of course, if the items the user is purchasing are not physical, or the user has already provided this information in a previous order, this step will be skipped.

Next, the user will be asked to select their shipping method:

The available shipping methods and shipping costs are calculated automatically based on what the user is purchasing. If the user purchases several items which have different available shipping options, more than one dropdown may be available.

In this case, IP.Nexus will automatically work out the minimum number of shipping orders to create based on the selections.
Again, if the items the user is purchasing are not physical, this step will be skipped.

The next page will show the user the total cost with shipping included and allow them to enter any coupon codes they have or apply account credit.

After selecting a payment method, the appropriate fields will automatically be shown:



After submitting, the user will either be taken back to the payment page if payment failed, or be shown a success page.


If you have configured IP.Nexus to hold all payments until you manually approve them, the success page will indicate this:


And of course if the user chooses to pay by a manual method (such as a check) they will be shown information how to pay:

View full blog entry

IP.Nexus allows to you to create packages with a variety of options and even create custom packages for your users.
In this blog entry we wanted to go through some of the options available to you.

Please note that the interface shown in the screenshots is not finalised subject to change.


Package Groups

IP.Nexus allows you to split your packages into package groups. You can have as many groups as you like, and groups can be children of other groups going as deep as you like.
This is the main "Manage Package" screen in the Admin CP:


You can click on a group to view the packages within that group:


And click on a package to edit it:



Physical Items

You can set an item as physical or not. If an item is physical you can also specify the shipping methods available. Shipping options can be flat rate or based on the weight of items being shipped.
When a user orders a physical item, a shipping order will be created which the Administrator can marked as filled. Shipping orders will be discussed in a future blog entry.

If a user makes an order with multiple items, IP.Nexus will work out which items have the same shipping methods available and group them into as few shipping orders as possible.




Associated Items

You can specify that one package can (or must) be associated with another package. For example, if you are selling software and also have an addon product, you could specify that the addon must be associated with the main product.
If a user purchases both the main product and the addon product at the same time, IP.Nexus will automatically work out that they are to be associated, and if the association is required, the user won't get an error message telling them they need to purchase the main product first.

When a purchase is associated with another purchase, this will be indicated both on the customer page, and in any support requests the user creates.




Discounts

IP.Nexus includes two discount options for packages. We call these "bundle discounts" and "loyalty discounts".

"Bundle discounts" allow you to specify a discount if the item is purchased with a different item. For example, here at IPS, if you purchase an IP.Blog license with an IP.Board license, you get a 5% discount on the total order - that would be possible within IP.Nexus.
You can specify whether the discount can only be used alone or if it can be combined with other bundle discounts. If it can only be used alone, IP.Nexus will automatically calculate the best discount applicable according to what is in the user's cart.

"Loyalty discounts" allow you to specify a discount if the user already owns a certain number of a certain item.
For example, you could make it so that if the user already owns 2 of an item, they get the third cheaper - or if the user has purchased a special item (for example some kind of premium membership) they get a discount on all products.
You can build up tiers so that if the user owns x items, they get y price, but if the user owns even more of the item, they get an even cheaper price - IP.Nexus will automatically work out the best discount.
If you have a loyalty discount set up so, if for example, the user gets a cheaper price if they already own 2 items, and the user tries to purchase 3 of that item at the same time - IP.Nexus will still take the loyalty discount into account, and provide the discounted price for the third item.




Upgrading Member Groups

You can specify that a user be moved into a different user group (primary or secondary) or have an additional permission mask assigned to them when they purchase an item.

You can also specify a renewal term for your license (the renewal price does not have to be the same as the base price) and have the user automatically demoted if they do not renew their item.




Upgrades & Downgrades

If in a product group you have different levels of a package, you can allow members to upgrade or downgrade between packages, which they can do themselves through their User CP.

You can specify whether to allow upgrades or downgrades (you can allow both, neither or either of the two) but also, you can specify whether or not the user needs to pay the difference between the prices when upgrading.
If this is set, when the user attempts to upgrade, they will need to pay the difference, and then be automatically upgraded. If this is not set, the user will be upgraded with no intervention.

On the other side, you can also set it to issue users with a refund of the difference when they downgrade their product, this is given in the form of account credits.




Custom Page

You can provide custom content that the user will see when they select their purchased item in the User CP. This could be used to display download instructions, hidden content or anything else you like.

In addition, you can also choose to display a "Submit Support Request" form on this page, and specify the support department it should be routed to.
We'll discuss support requests in more detail in a future blog entry.




Custom Package Fields

You can specify "custom fields" that the user can (or must) fill out when purchasing an item. An example of how this might be used is if you're selling clothing and you need the user to select their size; or you're selling software and you want to force the user to provide the URL they will be installing the software on.

Textbox and dropdown field types are supported, there are also two special field types: "username/password" and "ftp information" which allow you to ask for what we expect will be frequently requested information but without using 2 or 3 custom fields.

If several of your items are going to have the same custom profile field (for example, if you're selling several different T-Shirts and they all need a custom profile field for "Size" - you only need to create it once and assign it to all fields.




Removing Packages

When you remove a package, you may also want to cancel the service for any members who have purchased that item, or even switch them to a different package.

IP.Nexus allows you to remove a package from all members in the way you choose.




Managing Purchases

Once a user has purchased an item, you can edit the purchase to change the renewal terms for that member - this allows you to for example, create custom variations of a package for different users.

You can also of course manually edit the custom fields, cancel a purchase (this will revert them to their original usergroup if applicable) and even transfer a purchased item to another member.





Custom Packages

Not only can you customise purchased items but you can create a custom package for an individual user through the Admin CP, specifying a package name, cost and renewal terms.

View full blog entry

I had previously blogged about the API in IP.Nexus allowing other applications to process payments using IP.Nexus. We have implemented this in IP.Downloads to bring paid file support.

You can specify which groups can add paid files, and which groups (for example the admin group) can download paid files without paying.

You can also specify how much commission to take from sales and what to give to the user who submitted the file when it is purchased.

A member who has permission will be able to specify how much to charge for a file when submitting it.


When viewing a paid file, instead of the "Download File" button, users will see a purchase button.


When clicking this button, the user will be taken to the payment screen and payment will be taken. If payment is successful, the user will be taken straight back to the download page where they will now see the normal "Download File" button.



The commission to be given to the member who submitted the file will be applied in the form of account credit, which, if allowed, he can request be paid out. This will be discussed in a future blog entry.

As you can see, the IP.Nexus & IP.Downloads integration is very simple to set up and use but allows IP.Downloads to be used by those selling digital files without the need for a complete billing system.

View full blog entry

One of the first things I wanted to talk about with IP.Nexus is how easy it is for third-party developers to integrate with IP.Nexus.
You could for example, have an area of your application that you only want available to users who pay a fee. IP.Nexus makes this possible.

There is a special class in IP.Nexus called commerceApi that allows you to generate an invoice, and check if an item has been purchased.
In addition, you can make use of special extension files to automatically run when an item from your application is purchased, expires or is renewed - and your items can appear in the Admin CP "Generate Invoice" page.

For example, we have written integration for IP.Nexus with IP.Downloads using this functionality, which we will demonstrate in a future blog entry.


For developers, to generate an invoice, you simply call the commerceApi::generateInvoice() method. This is the code we use within the donation module of IP.Nexus:

try { $title = "Donation: {$goal['d_name']}"; $invoiceID = commerceApi::generateInvoice( $title, $this->memberData['member_id'], array( array( 'act' => 'charge', 'app' => 'commerce', 'type' => 'donation', 'cost' => $amount, 'itemName' => $title, 'itemID' => $goal['d_id'] ) ) ); } catch( Exception $e ) { $this->registry->output->showError( "An error occurred while trying to generate your invoice. Please try again or contact an administrator. ({$e->getMessage()})", 12345 ); } $this->registry->getClass('output')->silentRedirect( $this->settings['base_url'] . 'app=commerce&module=payments&section=pay&id=' . $invoiceID );

As you can see, the code passes some information about the item(s) being purchased. At this point, commerceApi generates an invoice, and then the user is sent to the payment screen.
Once payment has been processed, the user will be sent right back to the file.

Using this functionality you can:

• Specify a base cost for your item
• Specify renewal terms
• Provide a URL to the item which will be linked to on the invoice screen
• Specify a member who should get commission for the purchase and how much commission to give them (for example, if the item was added by another member)
• Specify a URL to return the user to once payment has been received

Later in your code, to check if a user has purchased an item (for example, when they try to access a restricted area) you just call commerceApi::itemIsPurchased() to check if they have paid for the item.

if ( commerceApi::itemIsPurchased( $this->memberData['member_id'], 'myapp', 'item_type', $data['id'] ) != 'ACTIVE' ) { // Item not purchased... }

commerceApi::itemIsPurchased() will return a value indicating whether the item was purchased, and if the renewals are active.


As you can see, the API is very simple to use and means mod authors do not have to worry about implementing payment systems in their own applications. We're really excited to see how mod authors will use this functionality and as always, if you have any questions, please post them in our feedback forum.
Our next blog entry will demonstrate how we used this functionality to implement paid files within IP.Downloads.

View full blog entry

While I would love the suggestion you have suggested, I would take it a step further.

I have found this really cool way that the Rich Text Editor can be tweaked to add great image function to it.

The main link is here, talking about it and how it's done.

[url="http://allmybrain.com/2007/10/16/an-image-upload-extension-for-yui-rich-text-editor/"]http://allmybrain.co...ch-text-editor/[/url]

Here is a link to a working Demo:

[url="http://allmybrain.com/2009/07/01/example-image-upload-with-yui-rich-text-editor-270/#comment-1041"]http://allmybrain.co...0/#comment-1041[/url]

Here is a screen shot of how the uploader looks.

Now, I think if IPS adds this type of image handler to IPB it would be great!!

Jamie

Maybe a little overcomplicated?

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.

View full blog entry

Very very VERY bad idea.

I disagree. For some communities I can certainly see the use.

So i do know what am talking about but w/e

I didn't say you didn't... but we can't ignore standards just because you don't care about them.

to be honest I don't care about what W3C agrees on, and I dont rly care about XHTML validation.

We do, as do most web designers. Not to mention, the SEO fanatics would have your head for saying that ;)

Oh yeah, and the version of Minify you ship carks it quite horribly if you add any extra CSS files (check out Forcize skins sometime - they actually require you to upgrade Minify when installing any of their skins!)

Well that would be a bug which should be reported ;) I've never heard of or seen this issue.

IPB does try to detect if Minify will work and disable it if not.
If for whatever reason the detection doesn't work you can disable it in the ACP - if you'd had contacted support from the start they would have recognised the problem straight away ;)

The main problem for Minify not working and IPB not being able to detect it is due to it's reliance on changing the include path - I did contact Minify a little while ago about this and they told me they would be changing that.

Have you tried clicking the "Get Help With This Page" link on the user agent page?
It will take you to here: http://community.invisionpower.com/resources/official.html?record=293

If you feel that article can be improved, you need to let us know what it's missing... that is what the comment feature is for.

Although it does answer the question being asked:

Regex - This is what IP.Board actually uses to detect if the user is using this user agent. It should be a regular expression which will be performed on the user agent string - if it matches, IP.Board will match the user with this user agent. For the simplest use, you can just enter in anything that will be in the user agent - for example, you could just enter "googlebot" for Google.

If you're interested in learning more about Regex, this is a good place to start.
With regards to "." vs "\." though - "." in Regex represents any character, so for the sake of detecting "bestsearchengine.com" - it doesn't really matter if you enter "bestsearchengine.com" or "bestsearchengine\.com".

Possible, and I agree with you, Mark. However, most of us run medium sized boards that aren't dependent on a business structure, or rather a good number of IPB run sites are. I just think that the feature should be something that can be turned on or off, depending on the preferences of the Admin. I would like to see a feature in the next version that allows the Root Admin to toggle that feature on or off, according to usegroup.

Mark, do you think this would be something that could be added?

You can configure who can submit reports, but not who reports can be submitted about.

I can't say whether it will or will not get added, I just personally don't see the point ;)

This has got to be my biggest complaint about IPB3.

With IPB 3, Administrators are protected from receiving warning strikes, from being banned and basically from receiving any kind of punishments. They are protected from such restrictions. However, there's one problem. Administrators can still see their posted messages and topics subjected to being "Reported." Shouldn't the Admin usergroup be protected from having their posts "reported" on by other members? I think that if this is set by default that there should be some way to disable it for certain groups.

I disagree. Let's say I was posting a reply to pre-sales question and I mistakenly typed that a license costs $14.99 instead of $149.99 - reporting the post would be the obvious thing to do so that it can be corrected.

If you give those errors to your hosting provider, they should be able to edit the configuration to fix them.

If you want to remove the GMail module, just delete the sources/components_public/utr_classes/utr_gmail.php file.

You're welcome! :)

I will be happy to read more replies from the staff :cool:

Great to know that we're able to provide you with a level of service you're pleased with.
While it seems I've never dealt with one of your tickets myself, I'll mention this topic to the techs that have ;)

Thanks for taking the time to post this. As always, if there's anything else we can do for you, just let us know :)