IPCommerceFan

The forums are always the right choice, since an answer here can be helpful for many. So I always prefer it over private questions. 

just fyi, i got annoyed with the interface issues, and on my toolbox app, one of the tabs that is added is "table imports", this allows you to insert the data thru like phpmyadmin/adminer and then import it into your application. 

I would strongly advise to use an application once you have to deal with database tables.
1. It's much easier to maintain the schema via the Application Dev Center, you'll literally only have to set up the fields and the framework will take care of everything else for you. There's no need to create manually any Install, upgrade and uninstall code, like for plugins.
2. Our support tools will try to fix only applications database tables and ignore any broken plugin database tables.
 

This should work inside your template:
{{if \IPS\Dispatcher::i()->application->directory == 'blog'}} Your code to show only inside blogs {{endif}}  

Oh man, thanks @Martin A.!
I wasn't aware PhpStorm could do that!

Facebook made just some changes which required some changes on our end and are included in a patch in 4.6. The issue isn't with login of existing users but rather a new user "registering" via the Facebook login provider.

You don't need that other program if you already have and use PhpStorm. Ctrl + Shift + F will give you an equal solution 🙂 

@Liloz01, I'd say the comments in the source files are a pretty good form of documentation.  I use a 3rd party app called FileLocator aka Agent Ransack to search the source files for these sorts of things:

We knew exactly what to search for in this case, but a search for just "moderator" would have ultimately led to the same result since the comment includes the word in line 72.
I'm no programmer, but this tool along with a good IDE like PhpStorm have made all the difference in developing my own plugins as the need arises!
As for how to know what you can do with \IPS\Member::loggedIn, I'd search for "\IPS\Member" and browse around to see how it is used, especially as it pertains to functions which accept a Member object.  (To find it used strictly in functions I'd search for "@param    \IPS\Member")
e.g.:   \IPS\Member::loggedIn()->memberPostCount() 
/** * Post count for member * * @param \IPS\Member $member The member * @param bool $includeNonPostCountIncreasing If FALSE, will skip any posts which would not cause the user's post count to increase * @param bool $includeHiddenAndPendingApproval If FALSE, will skip any hidden posts, or posts pending approval * @return int */ public static function memberPostCount( \IPS\Member $member, bool $includeNonPostCountIncreasing = FALSE, bool $includeHiddenAndPendingApproval = TRUE ) Hope that helps!

Ideally you'd not use queries like that in a template, and instead do that in a controller however life isn't always as neat so...
{{foreach( \IPS\Db::i()->select(...) ) as $row}} <strong>My name is: {$row['name']}</strong> {{endforeach}} Will do the trick.

I have an application that uses only $reviewClass and NO $commentClass which throws an error after upgrading to 4.6. This happens because loading the reviews then goes on to call the function _comments() from system\Content\Item::reviews() to load the data.
 
The error is because of this code added in system\Content\Item::_comments() to handle solved contents, statistics, and recognized content (lines 4349-4400):
/* Solved count */ $commentClass = static::$commentClass; $showSolvedStats = FALSE; if ( method_exists( $this, 'isQuestion' ) and $this->isQuestion() ) { $showSolvedStats = TRUE; } else if ( \IPS\IPS::classUsesTrait( $this, 'IPS\Content\Solvable' ) and ( $this->containerAllowsMemberSolvable() OR $this->containerAllowsSolvable() ) ) { $showSolvedStats = TRUE; } if ( $showSolvedStats ) { $memberIds = array(); $solvedCounts = array(); $authorField = $commentClass::$databaseColumnMap['author']; foreach( $results as $id => $data ) { $memberIds[ $data->$authorField ] = $data->$authorField; } if ( \count( $memberIds ) ) { foreach( \IPS\Db::i()->select( 'COUNT(*) as count, member_id', 'core_solved_index', array( \IPS\Db::i()->in( 'member_id', $memberIds ) ), NULL, NULL, 'member_id' ) as $member ) { $solvedCounts[ $member['member_id'] ] = $member['count']; } foreach( $results as $id => $data ) { if ( isset( $solvedCounts[ $data->$authorField ] ) ) { $results[ $id ]->author_solved_count = $solvedCounts[ $data->$authorField ]; } } } } /* Recognized content */ if ( \IPS\IPS::classUsesTrait( $commentClass, 'IPS\Content\Recognizable' ) ) { foreach( \IPS\Db::i()->select( '*', 'core_member_recognize', [ [ 'r_content_class=?', $commentClass ], [ \IPS\Db::i()->in('r_content_id', array_keys( $results ) ) ] ] ) as $row ) { if ( isset( $results[ $row['r_content_id'] ] ) ) { $results[ $row['r_content_id'] ]->recognized = \IPS\core\Achievements\Recognize::constructFromData( $row ); } } }  
To solve the issue I had to wrap the whole thing in an IF check for the class:
if ( isset(static::$commentClass) ) { //... {  

Stuart fixed this few days ago🤯, meaning it's going to be included in the next regular release:) 

Hello,
Thank you for developing this application!
We are upgrading from 4.4.10 to 4.6.5.1 soon, and one of the reasons we haven't upgraded yet is our dependence on the no-longer-supported Rules application.
We use it to perform actions both immediately after a purchase is made, as well as some amount of time later.
We can do the "immediately after" stuff via creating our own plugins, but not the "some amount of time later" things.  Its beyond my abilities to create a scheduler for that.
Upon installing (the 4.4.10 version) Email Drip Campaigns, I see a couple of areas for improvement that would really help our use case.
1.   The ability to evaluate the purchase custom fields to see if the campaign should be run or not.  For example, a vehicle's identification number informs a lot of these decisions.   If it is a 2011 Chevrolet Cruze, request some specific information about the transmission.  If it is a 2017 and up vehicle, request some other information.  If the purchase is for some custom widget, send an email to our warehouse staff to specifically package it up.
2.  In addition to the actions of "Send an email" and "Send a personal conversation", we would benefit from "Send a Support Request", where we also associate the purchase to the request.
3.  In lieu of adding a specific action, it would be nice if we could "Run custom php", and basically just use the same code we've always used, but triggered by EDC instead of Rules.
All in all, we are looking forward to replacing Rules with EDC because it fulfills all we ever used Rules for anyway.  We just need it to be able to create support requests, and evaluate custom fields.
Thanks again!

Agreed, adding campaign-specific options would be great.  I believe the first option may only ever apply to purchases (thus I would make it apply only to them), though I admittedly haven't considered how anyone might use it for any of the other campaign types.

I don't think I'd advocate for automated changes based on what is being brought up, but I wouldn't be opposed to some additional options on the campaigns.
Allow more than one instance of this campaign Automatically cancel this campaign if purchase/subscription is cancelled That first option would have to be implemented very carefully. The reason it behaves the way it does presently, as I recall, is because if you set a campaign to initiate when a user reaches 10 posts or whatever, you definitely wouldn't want the campaign to fire at 10 posts...and 11 posts...and 12 posts...and so on.

Why would you even use a translatable field with a validation?:D
What's going to happen if you're logged in with the "English" language in your ACP, and you set English and French and there's a typo in the French field? It won't return any error, right?;) 
So you'll literally have to save the form, change the ACP language to French and resave the form again to run the validation for the French field
 
Sorry, I'm just nitpicking, and I guess you know what you're doing, but had to mention it for anybody else searching for something similar and finding the topic and your (bad code:P ) 😄

In that same vein, if the originating "type" (like a purchase) is cancelled, I think it would be reasonable to expect the campaign instance to be cancelled as well.
e.g. Someone buys a product, a campaign fires and queues up an email to be sent 30 days later requesting a product review.   If the customer changes their mind and the purchase is cancelled, we wouldn't want that email to still go out.

I think I've mentioned this before, but since one can add a member to a campaign from the adminCP, it might also be very useful to be able to remove a member from a campaign there as well.

@liquidfractal, I discovered this need as well last night!
I've found that there is a check that asks "Does this campaign ID exist for this member already?".  If its true, then you can't add any more of the same campaign.
I think if we had some extra criteria added to Instances, we could get around this.
For example, maybe we could use the purchase id?
If the campaign ID and purchase ID pair exist for a given member, don't create an Instance.   If the purchase has never had the particular campaign run on it, run it!  This way a member can have multiple instances of the same campaign active,  but associated to the individual purchases.
To get the purchase id, maybe we could capture it when the instance is created via purchase?
We'd use the purchase id as the search criteria instead of the package id, then when actually launching the instance, we could save the purchase id as some variable, then redeclare the package id as the value for that function in order to keep it working the way it normally does (because we still want to only run the campaign only on certain packages).
Just some thoughts!

I have a suggestion regarding members and campaigns.
To use my current case as an example: when member X purchases product Y they are added to a drip campaign for emails for thanks, followup, etc.  However, as EDC currently stands, if X purchases Y again in a few weeks' time (or ever, in fact) they won't receive any more messages because they're already part of the DC for product Y, which is now listed as completed. 
OK, I see a certain logic in this in some cases.  But in my case, I have clients making repeat purchases of hours packages, and they're often buying for others (e.g. their children, who are students) and may not pay a lot of attention to/may forget/may just delete the initial followup emails/messages, which in my case contain a link to the Store and other useful information for repeat purchases.  I would have to go into their adminCP Member profile and manually restart their campaign (which can be time-consuming if you have lots of people making repeat purchases).
I think this could be alleviated by removing a user from a campaign as soon as it's completed.  I realise that, depending on the nature of the product and the campaign associated with it that timelines could get a bit choppy, and that perhaps there isn't a one-size-fits-all solution, but sometimes it makes perfect sense for the campaign to restart with a repeated purchase.
OR.....could this be toggled on a per-campaign basis?  What if one could configure a campaign to automatically restart if it is re-triggered by a member's repeat purchase before it is completed the first time around?
[Or (just spitballing here) if each step could be configured to either execute once or to repeat with repeated triggers?  (Not sure about this last one - it just came into my head while I was typing!)]
I hope this makes sense.  

Hello,
Thank you for developing this application!
We are upgrading from 4.4.10 to 4.6.5.1 soon, and one of the reasons we haven't upgraded yet is our dependence on the no-longer-supported Rules application.
We use it to perform actions both immediately after a purchase is made, as well as some amount of time later.
We can do the "immediately after" stuff via creating our own plugins, but not the "some amount of time later" things.  Its beyond my abilities to create a scheduler for that.
Upon installing (the 4.4.10 version) Email Drip Campaigns, I see a couple of areas for improvement that would really help our use case.
1.   The ability to evaluate the purchase custom fields to see if the campaign should be run or not.  For example, a vehicle's identification number informs a lot of these decisions.   If it is a 2011 Chevrolet Cruze, request some specific information about the transmission.  If it is a 2017 and up vehicle, request some other information.  If the purchase is for some custom widget, send an email to our warehouse staff to specifically package it up.
2.  In addition to the actions of "Send an email" and "Send a personal conversation", we would benefit from "Send a Support Request", where we also associate the purchase to the request.
3.  In lieu of adding a specific action, it would be nice if we could "Run custom php", and basically just use the same code we've always used, but triggered by EDC instead of Rules.
All in all, we are looking forward to replacing Rules with EDC because it fulfills all we ever used Rules for anyway.  We just need it to be able to create support requests, and evaluate custom fields.
Thanks again!

Looking at your first and second code there's also something else..;)
if ( $val AND @preg_match( $val, NULL ) === false )
In your first attempt you were assuming that $val is a string, but it's literally an array with the language ID as key and the string as value .
This means that even your current code with $val[1] could result in an error!

This was supported since 4.0.x !
Take a look at applications/core/extensions/core/FrontNavigation/CustomItem.php for an example 🙂

Those are interesting use cases.
Running custom PHP, specifically, is not very complicated. The rest would require a bit more time and energy investment.
I would be interested in seeing if anyone else has a need or use for those suggested additions.

I’m alive, COVID tried to kill me, but I’m alive. The application linked above is technically 4.4 compatible, but most have had no issues on 4.5. I’m working on the update for 4.6, slowly but surely. There is more to the app than just the login handler I’m afraid. Also, to meet the IPS MP requirements, which I don’t right now. I’ve got to make some additional code changes beyond just the smaller changes others have had to make.

Not sure how they can change that to be more obvious, other than maybe altering the language bit there to say "Changelog / Previous Versions".
Maybe make that an actual button rather than just a subtle link?
🤷‍♂️