Jump to content

-FP

Members
  • Posts

    857
  • Joined

  • Last visited

  • Days Won

    2

Reputation Activity

  1. Like
    -FP reacted to Matt for a blog entry, We're now using Invision Community 4.3!   
    Cue the music; switch on the dramatic lighting, we've got fantastic news!
    We're now running Invision Community 4.3 on here for some advanced testing before we unleash the first beta release.

    There's a subtle hint above
    If you need a recap of what was added, take a look at our product updates blog which takes you through the highlights.
    As this is a pre-beta release, expect some funkiness as we scurry around and tidy up our custom theme wrapper and other areas as we spot them.
    If you you find a bug, we'd love for you to report it with as much detail as you can muster in the bug report area.
    We'd love to know what you think, let us know below.
  2. Like
    -FP reacted to Matt for a blog entry, 4.3: Commerce Subscription Manager   
    We've recently spoken about how we've brought our Gallery and Blog apps up to date with interface overhauls to bring them inline with the high standards our customers expect.
    Keeping this in mind, we're thrilled to announce that we've taken Commerce right back to 2009.
    This needs an explanation.
    Way back in 2009, Obama was inaugurated as the 44th President. Minecraft was put into beta, Slumdog Millionaire was released to critical praise and we had a product called IP.Subscriptions.
    IP.Subscriptions was a lightweight member subscriptions manager that allowed members to purchase elevated permissions via a user group upgrade.
    It was a fine little app. However, on the horizon we had a brand new eCommerce app in development. Then called Nexus, now called Commerce (we took months to come up with that).
    It made sense for us to merge the products into one app given they both had overlapping functionality. They both could create packages to promote members to a new user group. Commerce was much more developed as an invoicing and billing system.
    Everyone was happy.
    Almost.
    Commerce has grown to be an incredibly powerful app. It can sell anything from physical products like t-shirts, to digital products such as license keys and it can even manage your hosting set-up.
    We use it for our support and billing systems, so we know how robust it is.
    While it's an incredibly powerful commerce system, setting up basic subscriptions packages became a little more complex.
    Over the past few years we've received a lot of feedback on this.
    We've listened.
    Commerce Member Subscriptions
    We've built a brand new section into Commerce specifically for membership subscriptions.
    Let's take a look at this in more detail.
    On the front end, there's a very clear and easy to understand page for membership subscriptions.

    The main subscriptions interface
    Here you can see all the available packages, which one you're currently subscribed to and the upgrade and downgrade options.

    A simple way to upgrade
    There's several choices for costing upgrades in the Admin CP, here we have chosen to charge the difference between packages.

    Get to your subscriptions easily
    Your subscriptions are easily found in the user menu.
    If the Admin allows, the package you're subscribed to appears as a badge on your profile.

     
    There's also a little widget showing the packages which you can drag and drop to the sidebar for an additional prompt for non-subscribers.

     
    This gives Invision Community a very clear and easy to understand interface for subscriptions which lives outside of the Commerce store and its packages.
    Now, let's dive into the Admin CP
    The main engine for this feature is the package list. This is in a separate area within Commerce.

     
    The list also shows the number of currently active and inactive subscribers. This links to the list of subscribers.

     
    Other than Bob having a total nightmare, you can easily view which members are currently active. The buttons link you to the Commerce invoice and purchase.
    If you wish to add a member to a subscription without charging them (you generous soul, you), then that is easily possible.

     
    Creating a new subscription package is very straight forward. We've built a new form which is stripped down to the fundamental items you'll need for a subscription.

     
    As you would expect, there are several settings to control the system.

     
    A few things worth mentioning here:
    You can force new members to purchase a subscription on sign-up You can show or hide the profile badge indicating which package they purchased. You can choose to allow upgrades or downgrades. You can choose how you'd like to charge for upgrades or downgrades Thank you to everyone who has provided feedback over the years. We're really pleased to present this new feature and hope that it'll make your daily lives just a little easier.
    Let us know what you think!
     
  3. Like
    -FP reacted to Charles for a blog entry, Invision Community 4.3   
    We are happy to announce the new Invision Community 4.3 is available!
    Some highlights in Invision Community 4.3 include...
    Improved Search
    We now support Elasticsearch for scalable and accurate searching that MySQL alone cannot provided. There are also enhancements to the overall search interfaces based on your feedback.

     
    Emoji
    Express yourself with native emoji support in all editors. You can also keep your custom emoticons as you have now.

     
    Member Management
    The AdminCP interface to manage your members is all new allowing you easier control and management of your membership.

     
    Automatic Community Moderation
    You as the administrator set up rules to define how many unique member reports a piece of content needs to receive before it's automatically hidden from view and moderators notified.

     
    Clubs
    The new Clubs feature has been a huge hit with Invision Community users and we are expanding it to include invite-only options, notifications, exposure on the main community pages, paid memberships, and more.
    Custom Email Footers
    Your community generates a lot of email and you can now include dynamic content in the footer to help drive engagement and content discovery. 
    New Gallery Interface
    We have reworked our Gallery system with a simplified upload process and more streamlined image viewing.
     
    The full list follows. Enjoy!
    Content Discovery
    We now support Elasticsearch which is a search utility that allows for much faster and more reliable searching. The REST API now supports search functions. Both MySQL and Elasticsearch have new settings for the admin to use to set search-defaults and default content weighting to better customize search logic to your community. Visitors can now search for Content Pages and Commerce Products. When entering a search term, members now see a more clear interface so they know what areas they are searching in and the method of search. Member Engagement
    Commerce can now send a customizable account welcome email after checkout. You can whitelist emails in the spam service to stop false-positives. REST API has many enhancements to mange members. Ability to join any OAuth service for login management. Invision Community can now be an OAuth endpoint. Wordpress OAuth login method built in. Support for Google's Invisible ReCaptcha. Groups can be excluded from Leaderboard (such as admins or bot groups). All emails generated by Invision Community can now contain admin-defined extra promotional text in the footer such as Our Picks, and Social Links. Admins can now define the order of Complete Your Profile to better control user experience. Clubs
    Option to make a Club visible but invite-only Admins can set an option so any Club a member is part of will also show in the parent application. So if you are in a Club that has a Gallery tab then those image will show both in the Club and in the main Gallery section of the community. Club members can now follow an entire Club rather than just each content section. There is a new option on the Club directory page for a list view which is useful for communities with many Clubs. If you have Commerce you can now enable paid memberships to Clubs. Admins can set limits on number of Clubs per group. If a group has delete permission in their Club, they can now delete empty containers as well. Members can ignore invitations. Moderation and Administration
    Unrestricted moderator or administrator permission sets in the AdminCP are visually flagged. This prevents administrator confusion when they cannot do something as they will be able to quickly see if their account has restrictions. You can choose to be notified with a new Club is created. Moderators can now reply to any content item with a hidden reply. Download screenshot/watermarks can now be rebuilt if you change settings. Support for Facebook Pixel to easily track visitors. Moderators can now delete Gallery albums. Automatic moderation tools with rules to define when content should auto-hide based on user reports. Totally new member management view in AdminCP. More areas are mass-selectable like comments and AdminCP functions for easier management. New Features
    Commerce now has full Stripe support including fraud tools, Apple Pay, and other Stripe features. Commerce packages can now have various custom email events configured (expiring soon, purchased, expired). Full Emojii support in the editor. Complete overhaul of the Gallery upload and image views. Announcements system overhaul. Now global on all pages (not via widget) and new modes including dismissible announcements and top-header floating bar option. Many new reports on traffic and engagement in the AdminCP. Blog has new view modes to offer options for a traditional site blog or a community multi-member blog platform. The content-starter can now leave one reply to Reviews on their item. Commerce now makes it much easier to do basic account-subscriptions when there is no product attached. Useful Improvements
    Forums has a new widget where you can filter by tags. If tags are not required, the tag input box now indicates this so the member knows they do not have to put in tags. Member cover photos can now be clicked to see the full image. Any item with a poll now has a symbol on the list view. Twitch.tv embed support. You can now update/overwrite media in the Pages Media Manager. Mapbox as an additional map provider to Google Maps. Technical Changes
    Direct support for Sparkpost has been removed. Anyone currently using Sparkpost will automatically have their settings converted to the Sparkpost SMTP mode so your email will still work. Your cache engines (like Redis) will be checked on upgrade and in the support tool to ensure they are reachable. Third-party applications will now be visually labeled to distinguish them from Invision Community official applications. The queued tasks list in the AdminCP is now collapsed by default as queued tasks are not something people need to pay much attention to during normal operations. When upgrading from version 3 series you must convert your database to UTF8 and the system saves your original data in tables prefixed with orig. The AdminCP now alerts you these are still present and allows you to remove them to reclaim storage space. On new installs there are now reasonable defaults for upload limits to keep people from eating up storage space. Categories in all apps (forums, gallery albums, databases, etc.) no longer allow HTML in their titles. This has been a concern both in terms of security and usability so we were forced to restrict it. Large improvements to the Redis cache engine including use for sessions. The login with HTTPS option has been removed and those who were using it will be given instructions to convert their entire community to HTTPS. Images loaded through the proxy system now honor image limits for normal uploads. We now consider BBCode deprecated. We are not removing support but will not fix any future issues that may come up.
     
    There's a lot to talk about here so we are going to lock this entry to comments so things do not get confusing. Feel free to comment on upcoming feature-specific entries or start a topic in our Feedback forum.
     
  4. Like
    -FP reacted to Charles for a blog entry, Invision Community 4.3 Coming Soon   
    Our recent release of Invision Community 4.2 was the most well-received version ever! The feedback we received on new features like Clubs, Reactions, and Promotes was better than we could have hoped and we really enjoyed seeing all the creative uses as people implemented them on their own communities.
    We have been hard at work on version 4.3 with a goal of improving on all the great new features. It is well under way and we are happy to able to start announcing what's new over the next few weeks.
    Invision Community 4.3 will not only contain new features but also have a core focus on refinement from 4.2's new features. You will see many improvements to Clubs, new integration options, large application improvements, new promotional features, and more changes large and small.

     
    You can expect to see news posts about new features and changes very soon with a release date in early 2018. Follow our news section or subscribe to our newsletter to receive updates.
  5. Like
    -FP reacted to Rikki for a blog entry, Theme Tip: Color coding tags   
    We were recently asked if it's possible to color code tags - the customer in question used tags as statuses on topics, and so wanted 'resolved' to be green, and so on. Despite being a great idea, this isn't something that is currently possible 'out of the box' - although we'll add it to our internal feature idea list to follow up on later!
    But just because it isn't built in, that doesn't mean it isn't possible! In fact, with a little CSS, this is quite easy to achieve now.
     
    Writing a CSS selector
    We can do this by writing a CSS selector that matches the tag URL for the tag we want to style - a handy way to use CSS that can be applied to lots of other ideas within the suite!
    Lets say we have a tag called 'resolved', and we want to make it green. Add the following CSS to your custom.css file:
    .ipsTags a[href*="/tags/resolved/"] { background: SeaGreen; } html[dir="ltr"] .ipsTags a[href*="/tags/resolved/"]:before { border-color: transparent SeaGreen transparent transparent; } The first style is the main part of the tag element; the second matches the :before pseudo-selector which we use to make the 'point' of the tag.
    Another tag we'll style is called 'needs help'. In this case, there's spaces in the name, which are represented by the + symbol in the URL (since it's URL-encoded). We'll make it purple this time:
    .ipsTags a[href*="/tags/needs+help/"] { background: Purple; } html[dir="ltr"] .ipsTags a[href*="/tags/needs+help/"]:before { border-color: transparent Purple transparent transparent; }  
     
    Supporting prefixes
    This little CSS snippet won't change prefixes, however - they'll still be shown in the default color (specified by your theme settings). If you want to change prefixes too, you need to adjust the CSS as follows - replace the previous CSS with this version:
    .ipsTags a[href*="/tags/needs+help/"], a.ipsTag_prefix[href*="?tags=needs+help"] { background: Purple; } html[dir="ltr"] .ipsTags a[href*="/tags/needs+help/"]:before, html[dir="ltr"] a.ipsTag_prefix[href*="?tags=needs+help"]:before { border-color: transparent Purple transparent transparent; } (Note: Notice the slightly different string we're matching in the href attribute; once you upgrade to 4.1.14, this won't be necessary - both selectors can use the same href format, e.g. /tags/needs+help/. Prior to 4.1.14, tags and prefixes used slightly different URL formats.)
    That's it - now everything looks correct!
     

    Topic View
     
     

    Forum View
     
  6. Like
    -FP reacted to Rikki for a blog entry, Theme Tip: Create a per-forum feed block   
    An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
    However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
     
    Creating conditional blocks
    The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
    The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
    In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
     
    Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
    {{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
    To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
    I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!
  7. Like
    -FP reacted to Rikki for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases   
    Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
    In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
    As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
    Setting up blocks
    The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

    Creating one of the blocks we'll need
     
    Adding the field
    Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
    Here, though, I've just created the Number field, and named it Forum ID.

    Setting up the database field
     
    Using the field formatter to show the correct block
    Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
    {{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

    End result, with the correct block pulled in based on the ID we provided to the record
     
    Going further
    So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
    Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
    {block="content_for_{$record->author()->member_id}"}  
    I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!
  8. Like
    -FP reacted to Rikki for a blog entry, Theme Tip: Using custom template bits   
    We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
    Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
    With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
    We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

    Example custom template bits in a custom theme
    Using them is simple:
    {template="_customHeader" group="global" app="core"}  
    I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
  9. Like
    -FP reacted to Rikki for a blog entry, Theme Tip: Advanced uses for Pages database fields   
    Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
    Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
     
    1. Adding an optional badge to records
    We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

    We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
    {{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
    2. Using fields as a way to configure the record display
    Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
    Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
    You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
     
    3. Pass data to 3rd-party integrations
    Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
    Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

    This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
     
    I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
  10. Like
    -FP reacted to Rikki for a blog entry, Theme Tip: Use HTML logic to display content to specific groups   
    HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
    Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
     
    Showing or hiding content only to guests
    We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
    {{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
    Showing content only to specific groups
    Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
    Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
    {{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
    Working with multiple groups at once
    Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
    {{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
    Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
×
×
  • Create New...