Ryan Ashbrook

23 hours ago, The Old Man said:

Thanks, I still have the one open for you since 15th July from the issue with random bulk Gallery upload inconsistencies. Do you need a new one for this?

Yes, we prefer separate tickets for separate issues as they are easier to track if they need to move between different teams.

2 hours ago, Adriano Faria said:

Oh damn... Clicked in the wrong post to mark as solved.

😄

And apparently I can't undo it.

Fixed for you.

1 minute ago, The Old Man said:

Hi @Stuart Silvester

Can you confirm that this has been fixed in the recent updates, please?

I think I fell foul of this recently whilst experimenting with it from a Wordpress plugin and gave up thinking it was me at fault.

Thank you.

Yes, this is fixed in the latest release.

Try using the like() method instead. Also, you do not need to pass your query to query() - simply convert $select to an array using the iterator_to_array() function.

$select = \IPS\Db::i()->select( '*', 'news_artcms_news', array( \IPS\Db::i()->like( 'categorynum', 'main', TRUE, TRUE ) ), 'news_artcms_news.num DESC', array( 0, 12 ) );
$results = iterator_to_array($select);

Thanks, we'll be patching this issue.

The link is linking to where that admin currently is in the Admin CP - that is why there is no arrow next to your name, because it would just link to the page you are already on. 🙂 

We attempt to account for renamed admin directories. If that is not working, then there's possibly a bug somewhere and you should submit a ticket.

In your Admin CP > Members > Groups, edit each group and under the Blogs tab, make sure the options are enabled.

Yes, you should be able to specify the positioning of the parameters. Try this (of course adjust for your language):

<a href='%2$s'>%3$s</a> %1$s's in <a href='%4$s'>%5$s</a> was marked as the answer

The parameters should be able to follow PHP's sprintf() function identifier rules.

I'll take a look. The original change was introduced for security, so we'll want to test any changes thoroughly to ensure there's no regression on that front.

I corrected my post to clarify shortly after as I realized I forgot to mention that part specifically. 🙂 

Yes, when IPS4 checks for updates for itself, it also checks 3rd party items. That being said, however, that is largely dependent on the author setting a URL to send the update check to. 3rd party items linked to the marketplace will use version information from there.

16 minutes ago, Nathan Explosion said:

I'll ask the obvious question...are you using the correct dev tools for the installed version of software?

 

 

This - we were a bit busy, so we weren't able to update the Developer Tools immediately for 4.6. Try re-downloading them.

Take a look in your System Logs under Support. You should see some entries for template_exception which will provide the actual error.

Shameless self promotion.

We are aware and are working on the issue.

If you are on Cloud, we are aware and the issue should be resolved shortly.

That's fair - however I should note that the handling of banned members has not changed between the two versions.

I'd recommend using the demo instead: https://invisioncommunity.com/demo

When you use the insert output plugin, then file is then included. As a result, it has access to the IPS4 Framework, so you could do:

<?php

echo \IPS\Member::loggedIn()->name;

5 minutes ago, Interferon said:

Matt, I need your cell phone number. I have a lot of good ideas. (This is totally normal here.)

Yes, the purchases are deleted. Transactions are not, however, which would be the appropriate way to track financial history. Income reporting in the AdminCP, for instance, uses Transaction data, not purchase data.

You can just create a brand new theme and it will be default with no changes - just select Manual Mode when creating. 🙂 

Just now, CoffeeCake said:

Just logged into the client area and saw the initial response I got was that this would be a feature request and not a bug. Do you need me to create a thread in the feature request forum making a request that this behavior be modified?

There may be some confusion in the support response. Post Before Registering is completely invisible to us out of the box until the person goes through with registering. That we'd be prompted to look at content submitted that is otherwise invisible and decide whether or not to approve it before they complete the registration seems like a flaw to me. If they don't complete the registration, it will delete itself. I'd offer that the profanity/link filter should only be triggered when the registration is complete and the post is about to be published.

Indeed - I reached out to support and clarified. What you described is a bug, and I'm investigating.

8 minutes ago, CoffeeCake said:

Hi Ryan, I did last night. Not sure how to direct you to the ticket #.

I found it, thanks. 🙂