IPS Staff
  • Content count

  • Joined

  • Last visited

About Rikki

  • Rank
    IPS Brit
  • Birthday 08/17/1983

Contact Methods

IPS Marketplace

  • Resources Contributor
    Total file submissions: 3

Profile Information

  • Gender
  • Location
    Lynchburg, VA :o
  1. 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!
  2. It's something we've been discussing, but there's no firm plans/timelines in place yet.
  3. There's no way of limiting the number at the moment I'm afraid - the plan would upgrade for the following month (but you can downgrade again after that).
  4. Hello, You'll need to have a license (either active or inactive) in order to download from the Marketplace
  5. Hi Mark, I just replied to your sales email too, but yes, converting to 3.x and then upgrade is certainly viable right now while 3.x is still available (although it is End of Life now). Thanks
  6. Most people would naturally use Commerce within the community, but there's no reason why you couldn't use it as a standalone store instead. What is it that you're planning to sell?
  7. There's no reason why you can't create full websites with Pages - in fact, our own website is built entirely with Pages I am not intimately familiar with Wordpress myself, so I can't give you a direct comparison, but we have features like: Reusable blocks that have full access to our template logic/framework (and can also be embedded in external, non-IPS4 webpages) Databases, which allow you to build entirely custom data-driven areas of your site. There's ~a dozen custom field types, and you have full access to the templates so you can customize how your pages appear completely. An example of a database is our guides section. Pages can be written using HTML or PHP, or you can use our visual editor which allows you to create WYSIWYG areas that you can drag into different areas of your page - no coding is necessary to create pages unless you want to. Regarding badges, we have simple badge functionality built in - see the staff badge under my photo Each group can have a badge, and a member's primary group badge will show under their posts in the forums.
  8. We are not overly concerned with CSS validation. The errors you pasted are: 1. In 3rd party CSS files, or 2. Rules that are implemented by browsers but not yet in the standards, or 3. Vendor-specific rules Validating CSS is largely meaningless and in no way is a measure of the quality of any particular CSS or, indeed, the product as a whole
  9. We have a guide on using license keys within Commerce available here:
  10. Hello, Thanks for your interest 1) You would need to renew both 2) Yes, that's fine - you'd just need to renew to make your license active.
  11. In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13. Read/unread filtering The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in. Search improvements Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by. Easier moving Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them. While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users.
  12. Hi Therese, There's a third-party French language pack available here, so once that's installed users would be able to choose either French or English and toggle between them. Hope that helps!
  13. Hi Wyatt, For oAuth2 integration you would need to build your own login handler. We use oAuth2 for a few of the built-in services we support, but there's no generic oAuth2 handler. If you're familiar with PHP and oAuth2, it shouldn't be too difficult to adapt one of the existing login handlers
  14. Yes that's no problem - licenses aren't based on the IP of the person who owns the license
  15. In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious. It's easy to use some custom CSS to replace all of the icons - lets see how. First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too. The basics Here's the basic CSS to replace the icon for all forums with your custom image: body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to. The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen. Using a different 'read' icon By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add: body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited. Using different icons for redirect or Q&A forums If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so: body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.