Mark

Enabling integration with Google Maps provides autocomplete functionality when a user enters an address (which is particularly useful if you are using the Commerce application) and can display maps when looking at IP addresses and elsewhere. Warning You need to enable three different API services. Make sure you follow all of the following instructions carefully. To enable Google Maps integration: Go to the Google Developers Console and sign in if you are not signed in already. In the top-left corner is the project selector. You may already have a project if you have previously integrated Google login on your community. If you do not have project, click the dropdown and create one. Select "Enable API's and Services" in the top left of the screen Click the "Google Maps JavaScript API" link and then click the "Enable" button. Click "Credentials" from the left menu, and select "Create Credentials". Choose the API Key option. You will be presented with an API key. Please keep hold of this key for the next step. On your community, to AdminCP > System > Community Enhancements > Google Maps. Here you need to select which items you wish to use. Here we have selected "Show Google Maps?" Important: You will see it then shows at the bottom which APIs you need to enable within 'Enable API's and Services' in your Google Developer Console. We just enabled one already in the previous steps, however you will need to enable any others showing. These will be different, depending on your selections Click on Continue, and in the API key given above here, then follow the instructions given on this page to restrict your API key, and create another secret key.

This release fixes a single issue where bulk mails may send duplicates, especially on sites with multiple languages.

This is a minor release to fix a small number of bugs: Broken @mention links. Merging members could cause follow records to be lost. Email digests. Incoming emails to Commerce. Announcements expiring at the wrong time. Error when editing database records or sidebar widget. Error trying to establish external connection to certain servers. Error redirecting from http to https.

This is a maintenance release to fix reported issues and add refinement to existing features. This release also contains a security improvement for older versions of PHP. In a recent change to their API, Google now requires an API Key to access their Maps API. After upgrading to 4.1.13, follow our Google Maps guide to restore this integration. This is especially recommended if you are using Commerce which uses the API for address input autocompletion. In addition to bug fixes and performance improvements, this release also includes following enhancements New per-group setting to highlight posts made by certain groups. 2 theme settings control the color and border, which are editable in the easy theme editor. New setting to make providing a billing address optional for purchases in Commerce. Personal conversation management improvements: Can now filter personal conversations to just read/unread. Can now move multiple personal conversations into a different folder at once. Can search by recipient/sender name. Notifications about Calendar events now include the event date. New setting to control which images sizes should have a watermark applied in Gallery. New setting to control which IP pool to use for SparkPost if you have purchased dedicated IP addresses. Better handling of upgrades if files have been modified. The sidebar widget for showing Downloads files can now show just free or paid files. When searching templates or CSS files in the AdminCP template editor, it will search for templates or CSS files with a name matching the term provided, in addition to searching the content of them. When viewing a log in the AdminCP, it will now show you on which page the log occurred and by which member. When the search index is being rebuilt, a message is now shown on the search results page to indicate why results may not be complete. The "details" modal for applications and plugins now has a tab which shows the hooks associated with that application or plugin. The placeholders that display on date/time inputs (e.g. "HH:MM") can now be translated. Rebuilding the search index, and rebuilding posts after a 3.x upgrade now processes newest posts first for a more user-friendly experience after upgrading. When a file is deleted, a log is created and a new setting controls how to keep these logs for. The following Pages features are also included: HTML pages are now editable via Designer's mode. Ability to rename, or delete a group of Database templates Ability to ensure the Page's title remains in all database generated links (categories, records, forms, etc) Reciprocal linking when using relational fields Date and time fields, and Yes/No fields are now filterable. Filterable custom fields now available when creating a record feed block Ability to make some custom fields unique, so that only one record per database can have the same value. Ability to delete a folder in the media manager Ability to use $record->field_key_name_here programatically to get and set values, instead of relying on $record->field_11 which may change when you export and import databases.

This is a security release to fix a number of security related issues. A vulnerability was recently discovered in ImageMagick, which, depending on your configuration, IPS Community Suite may use manipulate images. This update verifies that images sent to ImageMagick begin with the expected "magic bytes" corresponding to the image file type. We are engaging in a third-party security audit of IPS Community Suite and this update contains a lot of security hardening. Many of these issues are not critical but we do still want to get the updates to you. This release only contains security fixes only. 4.1.12 will be our next general maintenance release.

If a log needs to be written and logging to the database fails, the log is written to disk instead. For example, this might occur if the database is completely inaccessible. By default, logs are written to the /uploads/logs directory. To change this, add the following line to your constants.php file: define( 'LOG_FALLBACK_DIR', '{root}/directory' ); Changing the "{root}/directory" place to be the location on your server where the logs should be written. If you include {root} then that will be replaced with the directory to where IPS Community Suite is installed.

This is a very small release to fix a few rather annoying issues from 4.1.8. Sorry about that Fixes an issue where incoming emails were not being received correctly. Fixes an issue where guests could do a partial account registration which could cause some confusion to the administrator when editing. Fixes an issue where the AdminCP dashboard may incorrectly report tasks aren't running when they actually are.

This is a maintenance release to fix reported issues.

Products Products are the things which are available in the store for users to buy. Most Products are Normal Products, but if you want to sell Advertisements or Hosting Plans, these are also types of Products. For more information about how to create Products, see Products & Purchases. Invoices Invoices, or Orders as they are called on the front-end, are the things that say a particular user is buying particular things. They can be created in 3 ways: When a user clicks "Checkout" in the Store, an Invoice is created. If a member has any Purchases which have renewal terms, an Invoice is created automatically when the renewal payment is due. An administrator can create Invoices manually in the AdminCP. An Invoice is made up of items which will usually be Products but could also include paid files from the Downloads application, donations, or anything else a user can pay for. Any shipping costs, adjustments for coupons, etc. will also be shown on the Invoice. Invoices will always have one of the following statuses: Paid - the user has paid the invoice (using Transactions) or the invoice has manually been marked as paid by an administrator. Pending - the user has not yet paid the invoice. Expired - the user did not pay for the invoice within the time period set by the "Invoices must be paid within" setting (AdminCP > Commerce > Invoices > Invoice Settings) and so the invoice is expired and they cannot submit payment. An administrator could resend the Invoice in the AdminCP to put it back to Pending. Canceled - either the user, or an administrator, manually canceled the invoice. Payment may have never been submitted, or may have been refunded. Transactions A Transaction is how a user pays for an Invoice. For example, when a user submits their card details, that creates a Transaction. An Invoice may have more than one transaction, for example, if their card is declined and then they use a different card, the Invoice will have two Transactions associated with it: one failed, and one approved. Transactions are usually associated with a Payment Method which processed (or attempted to process) the payment (for example PayPal, Stripe or Authorize.Net). However, if the user chooses to use credit on their account to pay, this will also show as a Transaction with Account Credit if specified as the method. In addition to Transactions created by the user checking out, they can also be created automatically. If a user has Purchase with renewal terms and also has a credit card on file, a PayPal Billing Agreement, or account credit when the renewal term is due, a Transaction to take that payment will be generated automatically when the Invoice is generated. Transactions will always have one of the following statuses: Approved - the payment was received successfully. Held for approval - usually means that the payment was received successfully, but was halted by a Fraud Rule. An administrator will need to manually approve or void/refund*. This status is sometimes also used if there was an error in the Payment Method and the system is not sure whether the payment was received or not - an administrator will need to confirm and either approve or refund the Transaction. Under review - the Transaction was previously Held for approval and an administrator has marked it for review. An administrator will need to manually approve or void/refund*. Failed - the payment was unsuccessful (for example, their card was declined for insufficient funds) or was voided by an administrator. Refunded - the payment has been refunded by an administrator. Partially Refunded - the payment was successful, however the user has been given a partial refund, so it's status is partially Approved and partially Refunded. Waiting - the user has indicated they will pay via a manual method (for example, post a check or send a bank wire). The administrator should mark this as approved once they receive payment, or cancel it if payment is not received. Pending - it is unusual to see this status, but indicates that the user submitted payment and the payment method has not yet confirmed or denied receiving it. It will automatically change to one of the above statuses or be deleted automatically. * Sometimes you will see a "Void" option for a Transaction and other times, "Refund". When a user makes a payment, most Payment Methods will first authorize the transaction (meaning they are holding the funds), but not capture it until it has passed the Fraud Rules check. This is to avoid unnecessary refund fees for you. In this state, you will see the "Void" option, which will cancel the payment completely, while the "Approve" option will capture and complete the payment. If the transaction has already been captured (some Payment Methods don't support separate authorize and capture, and some have a limit on how long a Transaction can be in this state for) you will see a "Refund" option. Shipments If an Invoice contains physical Products which need to be shipped, then once the Invoice is paid, Shipments are generated. These contain the items and quantities to be shipped, the Shipping Rate to ship them by, and the shipping address. Sometimes more than one may be generated, for example, if the user is purchasing two different Products with different Shipping Rates. Shipments will always have one of the following statuses: Shipped - the shipment has been sent. Pending - the shipment is waiting to be shipped. Once it has been sent, an Administrator should mark is as Shipped. Canceled - the shipment has been canceled, it is possible that payment was refunded (and therefore the Invoice was no longer marked Paid) before the shipment was sent, or it has been manually marked Canceled by an administrator. Purchases Once an Invoice has been marked as Paid, the details of any Products, and certain other items (for example, Files in the Downloads application) are stored as a Purchase. A Purchase may have an expiry date and renewal term, which will cause renewal Invoices to be generated automatically.

This is a maintenance release to fix reported issues. Please note that in this release we have updated the copyright data in many source files. This means that if you are upgrading through the Admin CP the update will take slightly longer to download and extract than normal.

This is a maintenance release to fix reported issues.

IPS Community Suite 4.0 is nearly here, and we'll be distributing betas very soon. But 4.0 is really just the beginning; with the new tightly integrated, one-version suite of applications, we're already starting to think about all of the features we'd like to add in the future. This brings us nicely to the final 4.0 feature we'd like to talk about: the upgrade system. In 4.0, when a new version is released, you'll see a message like this pop up in the Admin CP: Clicking the "Download" button will allow you download, right from the Admin CP, a zip file with the new version. This zip file will contain just the changed the files from the version you're using (in technical terms, this is called a delta update) to save time and bandwidth when uploading the new version to your server. The system automatically knows what apps you have installed (so you don't have to download a separate zip for each application) and even knows if you've renamed your AdminCP directory and accommodates for that. Here's a video of the process in action:

IPS Community Suite 4.0, the most significant update to IP.Board and the rest of our apps we've ever made, is fast approaching a state where we'll be ready for a public preview and, soon after that, public beta testing! We know most of you are just as excited as we are about this and can't wait to try it out. With 4.0, we've made some significant leaps in terms of modernization, and it's possible that you might need to do some preparation before you're ready to install it. Notably, our minimum PHP and MySQL versions have gone up. It's the first time we've needed you to do this in 6 years, and the versions we need you to have have been around for a long time, we're not requiring the latest versions. In addition, 4.0 is UTF-8 only (if you don't know what that is, it's a way text can be stored in your database which you may or may not be using at the moment) and while the 4.0 upgrade process will ask you to convert your database if you're not already using it, this is a moderately time-consuming process, so if you convert your database now, it's one less thing to worry about on upgrade day. To make this process as easy as possible, we have created a little script which you can upload to your server to test if you're ready. Download Now

A while ago I blogged about some of the internationalization and localization changes in 4.0. One of the things I mentioned is a "Visual Language Editor" which allows you to quickly change any of the verbiage used throughout the suite just by clicking on a word of phrase. Not only is the really useful for those who want to translate the IPS Community Suite into another language, it can also be used to easily change words and phrases as you like (for example if you want a link to say "Register" rather than "Sign up") - it can even be used to rename forums, categories, etc. Before I couldn't show you it in action as we weren't quite ready to show the front-end interface but now here's a video of the feature in action:

Effective moderation features are essential for online communities. Forums, blog entries and member-to-member messaging are particularly attractive for spam bots and nuisance users alike. IPS Social Suite has always been best in class when it comes to moderation features with features like the free IPS Spam Service that are completely unmatched by other web applications. Over this series of 5 blog entries I'm going to introduce you to some of the new moderation features in the IPS Community Suite 4.0. Part 1: Setting up moderators Part 2: Approval Queue Part 3: Reports Part 4: Effective Moderation Part 5: Warnings Introduction A lot of what I'm going to cover in this blog entry is similar to the warning system in 3.x which was recently overhauled. Since warnings and moderations are such an important aspect of running a community though, I wanted to reintroduce the system, showing off the new UI for 4.0 and highlighting some of the tweaks that have been made. The warnings system in the IPS Community Suite is point-based. When issuing a warning to a member, you select a reason, and each reason is tied to a number of points, and then when a member reaches a certain number of points, an action (such as to ban them from the site) is taken. This is the setup page for reasons - I've set up each one to give one point which is never removed. For each reason, I can choose if moderators can override that or not: This is the setup page for actions: I've set up a number of actions so that the following flow happens: You can control whether members can see their previous warnings or not. Moderator Permissions For each moderator you can control is they can see, issue and revoke warnings, and control how often they can give warnings: Viewing Warnings You will be able to see the current warning points for a member from their hover card (which shows whenever you hover your mouse over their name throughout the suite) and can see the details in their profile. Clicking on a warning brings up the details which show a link to the content the user posted which prompted the warning, the notes both for the member and for other moderators, and lists the actions taken (points given, if the member was suspended, etc.): In addition, when viewing content (posts, comments, etc.) if that post prompted a warning, this will be shown to moderators: Issuing Warnings When issuing a warning, selecting a reason will automatically fill in the number of points and actions to take based on the number of points the member already has (these can be changed if the administrator has allowed it). You can clearly see the pre-defined actions for each point level on the right. You can optionally add notes, both a note for the member and for other moderators. Acknowledging Warnings You can optionally set the system so that members have to acknowledge a warning before they can post again. When this is the case, the member will se a message on every page: Viewing the warning details will have a button allowing the member to acknowledge the warning: Even if you do not require warnings to be specifically acknowledged - members who have restrictions applied to their account (are on moderator queue, are restricted from posting or are banned) can clearly see this and the reason why. For example, this is what a member who is on moderator queue sees when making a comment: Revoking Warnings A new feature in 4.0 is that warnings can be revoked. You can reverse all the actions of the warning, or just delete the record of it: [*]On the first warning, nothing happens (it's a verbal warning only) [*]On the second warning, all posts the user makes for the next day will need to be approved by a moderator. [*]On the third warning, the user will be banned for one day and all posts the user makes for the next week will need to be approved by a moderator. [*]On the fourth warning, the user will be banned for a week. [*]On the fifth warning, the user will be permanently banned.

I can distinctly remember 5 years ago reading a blog entry on this site about the "personal conversations" feature in IP.Board 3.0, which we were working on at the time. Up until then, the messenger system in community software and other websites was much like email - you sent one message at a time, with little continuity between messages. We were one of the first, on the entire of the web, to introduce what we called "personal conversations" - a sort of "private topic" between invited members - it was a really exciting idea back then. For 4.0, we wanted to really focus on the experience of using the messenger - making it super fast and easy to compose, navigate and participate in conversations. Starting a conversation When browsing the site, you'll see a messenger icon at the top of every screen just like you do now. When hitting the "Compose Now" button inside though, the form to send your message will appear as a modal window, and when you send, it will disappear again with no page reload. This makes it incredibly fast and easy to send a message from wherever you are, without interrupting your flow. You can also send a message to a specific member by hovering over their name wherever you see it on the site and clicking the "Send Message" button in the hover card that shows. Browsing conversations We've completely redesigned the main messenger pages. You now see a (infinitely scrolling) list of all your messages on the left-side. Clicking on any message opens it up in the main pane. All the common actions are enhanced with AJAX so you can open a conversation, add a user and reply all really quickly. Mobile We've not forgotten about mobile devices! The new responsive design in IPS 4.0 means the whole messenger works and looks great whether you're on a desktop or on your phone. Summary We recognise that when members send a new message, it is often as a response to content read in all areas of the suite. You can now send messages in place without disrupting your flow. We have improved all aspects of sending, receiving and managing messages and are confident these changes will make communicating with other members in private simpler and faster.

Copying Settings Sometimes you need to change the same setting across multiple categories. For example, let's say up until now I've not allowed comments on files and now I want to enable it for most categories. In IP.Downloads for 3.x, I'd have to go into each category one by one and toggle the setting on. In 4.x, when editing a category, each setting has a "Copy" button next to it, when opens a window asking which categories to copy that setting value to, so I can make the change to one category and then copy it to others (or all) quickly. This feature is also available when editing things in other applications, such as forums in IP.Board or products in IP.Nexus. New Settings We've moved some settings which were previously global settings into per-category settings to give you even greater control over your community: "Require approval of comments" "Log all downloads" and "Prune download logs" - we also added a new per-category setting: "Allow file submitter to view log?" "Allowed file extensions" (this used to be managed using complicated "Mime Type Masks" - now you can just provide the extensions which are allowed in that category, or allow any file type). "Enable versioning control" and "Number of revisions to keep"