Jump to content

Daniel F

Invision Community Team
  • Posts

    6,545
  • Joined

  • Days Won

    36

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Everything posted by Daniel F

  1. Yea, that's not intentional and I can't reproduce it myself on our own community and my priv. board with Safari. Are you seeing this here on the community or only on your own community? I guess a ticket would be the best guess to investigate this further:)
  2. Theres no task for this! Member accounts are only promoted when a members AR object is saved!
  3. What it does An AchievementAction extension allows you to define custom actions for Achievement Rules. Note that you do not ever have to think directly about points or badges. You just tell the system about your actions, and when they happen. The framework will handle including your actions in the UI that allows administrators to configure what points and badges are awarded from there, and handle giving them out (although you don't nee to worry about this, details of how this happens is below). A action always has a subject member. For example, the user making the post, logging in, or receiving a reaction. When you call the user-land code defined above, you call it on the subject member's \IPS\Member object. An action can also optionally have any other members (with the awardOptions() method in the extension). For example, the user giving a reaction, the user who originally posted a question which is getting an answer marked best, or the club leader(s) of a club being joined. This allows you to create single actions which can award points to multiple members. An action can have filters allowing the administrator to create different rules for different scenarios. For example, an administrator might want to award certain amounts of points for posting in one forum and other amounts for other forums. Again, all you need to do is tell the system about your filters (with the filters() and formatFilterValues() methods in the extension) and provide a callback in your extension for checking if a given scenario matches (with the filtersMatch() method in the extension). You do not need to do anything in your user-land code. In addition to filters for things like which node a thing is happening in, a common filter type will be a "milestone" filter - i.e. "if this is the member's first/100th/whatever time they've done this thing". This will be especially useful for allowing administrators to create badge-earning rules on specific occasions rather than points-based rules every time a thing happens. Despite it probably being a feature of most actions, it is ultimately just the same as any other filter. The framework will automatically log the event and the points/badges that were issued because of it, including checking that log to make sure the user doesn't earn rewards more than once. For example, if a member likes a post, unlikes it, and re-likes it, the framework will see from the log they have already earned rewards for that and not give them again. You do not need to do anything in user-land code to facilitate this, except provide a callback that return a unique string identifier (with the identifier() method in the extension). For example, if your action is for when a post is created, you would return the post ID. If your action is for when a reaction is given you would need to return a string that encapsulates both the content ID and the giver's member ID. Sometimes you can use this to get a bit creative. For example, the SessionStartDaily action is called every time a member logs in, and the identifier used is a string representation of the member ID + current date. This means the action can give points every unique day that the member logs in, and we don't need to implement any logic to facilitate that: we just set the identifier to be unique for the timeframe that it should occur within, and the system figures it out. If more than one rule matches for a particular action, they all execute. For example, if you have a rule that gives 1 point for posting in any forum, and another which gives 5 points for posting in a special forum, the user will earn 6 points for posting in that second forum. How to use 1. Create the extension and implement the below methods. 2. In userland code, call Member::achievementAction() to trigger the action. $member->achievementAction( 'your_app_key', 'YourAchievementActionExtensionKey', $anyExtraDataThatYouNeed ); /** * Get filter form elements * * @param array|NULL $filters Current filter values (if editing) * @param \IPS\Http\Url $url The URL the form is being shown on * @return array */ public function filters( ?array $filters, \IPS\Http\Url $url ): array { return []; } The filters method defines the custom form fields when the specific action is being used. /** * Format filter form values * * @param array $values The values from the form * @return array */ public function formatFilterValues( array $values ): array { return []; } The formatFieldValues method is called before the form is saved, allowing you to prepare the form values. /** * Work out if the filters applies for a given action * * Important note for milestones: consider the context. This method is called by \IPS\Member::achievementAction(). If your code * calls that BEFORE making its change in the database (or there is read/write separation), you will need to add * 1 to the value being considered for milestones * * @param \IPS\Member $subject The subject member * @param array $filters The value returned by formatFilterValues() * @param mixed $extra Any additional information about what is happening (e.g. if a post is being made: the post object) * @return bool */ public function filtersMatch( \IPS\Member $subject, array $filters, $extra = NULL ): bool { return TRUE; } /** * Return a description for this action to show in the log * * @param string $identifier The identifier as returned by identifier() * @param array $actor If the member was the "subject", "other", or both * @return string */ public function logRow( string $identifier, array $actor ): string { return "{class}"; } /** * Get "description" for rule * * @param \IPS\core\Achievements\Rule $rule The rule * @return string|NULL */ public function ruleDescription( \IPS\core\Achievements\Rule $rule ): ?string { return "{class}"; } /** * Process the rebuild row * * @param array $row Row from database * @param array $data Data collected when starting rebuild [table, pkey...] * @return void */ public static function rebuildRow( $row, $data ) { // This method runs the achievementAction on the table row from the table (or tables) you specified in rebuildData() // You are welcome to load any classes, etc you need here. //IPS\Member::loggedIn()->achievementAction( '{app}', '{class}', $row['field_id'] ), \IPS\DateTime::ts( $row['field_date'] ) ); } /** * Get rebuild data * * @param array $data Data stored with the queue item * @param array $filters The value returned by formatFilterValues() * @param \IPS\DataTime|null $time Any time limit to add * @return void */ public function preRebuildData( &$data, $filters, \IPS\DateTime $time = NULL ) { /* Any data for the rebuild task, must set $data['count'] for the progress bar */ } The preRebuildData() method allows the extension to calculate and store any data necessary prior to initiating the rebuild task and it also needs to include the number of items in the DB which are going to be processed for the progress bar.
  4. New Extensions: core\AchievementAction Supported PHP & MySQL Versions: The PHP min version was increased to PHP 7.2 in IPS 4.6, this means that your marketplace submissions are required to work with this version, but keep in mind that few clients are going to use php8, so I would really suggest to try to get your code working with both versions, which means that you'll need to implement some changes to avoid some BC breaks in PHP8. Here's a great list https://www.php.net/manual/en/migration80.incompatible.php Security Improvements: We have a new IN_DEV code check similar to the slash check, which will inform you about any outputs containing the CSRF key in the URL. This is a bad practice allowing attackers and 3rd parties to obtain the users CSRF key, so please try avoid this at any cost! We're not going to reject MP submissions because of this, but please try to avoid this as much as much as possible. New Content Framework Feature: Anonymous Content
  5. We took the opportunity for some spring cleaning and to clean up the 4.6 code, so we have finally removed most of the methods which were marked as deprecated. Removed \IPS\{app}\extensions\core\Uninstall\{extension}::onOtherAppUninstall() (use onOtherUninstall()instead). Removed \IPS\cms\Databases::getDatabaseDataFromStore() (use getStore() instead). Removed \IPS\cms\Pages\Page::getPageUrlStore() (use getStore() instead). Removed \IPS\Application::$ipsApps (use \IPS\IPS::$ipsApps instead). Removed \IPS\Login::handlers() (use getStore() instead, but note that the response is formatted differently). \IPS\Email::buildFromContent() now requires the $type parameter to be passed. \IPS\Email::buildFromTemplate() now requires the $type parameter to be passed. Removed \IPS\File::getConfigurations() (use getStore() instead). $isInternal and $isFriendly properties in the URL classes have been removed. Check instanceof \IPS\Http\Url\Internal and instanceof \IPS\Http\Url\Friendly instead. Removed \IPS\core\Rss::getAllFeeds() (use getStore() instead). Removed \IPS\Content\Reaction::reactionStore() (use getStore() instead). Removed \IPS\Content\ShareServices\Facebook::publish(). Removed \IPS\Db::SELECT_SQL_CALC_FOUND_ROWS. This behavior was already deprecated and throwing IN_DEV warnings in past versions. Removed \IPS\Email::buildUnsubscribe() (use setUnsubscribe() instead). Removed \IPS\Helpers\Form\Address::_calculateDefaultCountry() (use calculateDefaultCountry() instead, and note that it is a static method). Removed \IPS\Http\Url::getFurlQuery() (check $friendlyUrlComponent instead). Removed \IPS\Http\Url::csrf() (this method still exists for internal URL instances of \IPS\Http\Url\Internal). Removed \IPS\Http\Url::acpQueryString() (this method still exists for internal URL instances of \IPS\Http\Url\Internal). Removed \IPS\Http\Url::stripArguments()`. Removed \IPS\Http\Url::createFromArray(). Removed \IPS\Http\Url::rfc3986(). Removed \IPS\Http\Url::getFriendlyUrlData() (check $hiddenQueryString on an instance of \IPS\Http\Url\Friendly instead). Removed \IPS\Log::i()->write() (use \IPS\Log::log() and \IPS\Log::debug()` instead). Removed \IPS\Login\LoginAbstract`. This class provided an upgrade path for 4.2 login handlers when 4.3 was initially released. Removed \IPS\Member\Group::groupStore() (use getStore() instead). Removed \IPS\Member::get_pp_photo_type() (use the magic ->pp_photo_type property instead). Removed \IPS\Output::licenseKeyWarning() and \IPS\Output::licenseKeyDaysRemaining(). Removed \IPS\Theme::i()->logo_sharer and \IPS\Theme::i()->logo_favicon as these are no longer theme-specific images.
  6. Hey, we have published the first article of a series about upcoming 4.6 changes. We took the opportunity for some spring cleaning, so we have removed most of the deprecated methods! They were all marked as deprecated for a while, so you should already be aware of these methods, but here’s a full list of the methods and the new approaches to make your life easier, so if you haven’t already, now it’s the best time to review your code and make sure that none of these methods is used. Most of the changes can already be implemented while the 4.5.x lifecycle.
  7. In some cases, the group won't matter. Even if the user is in the admin group, he won't be able to access the ACP if the admin group was removed from being able to access the ACP ( Admin => Members => Administrators) Anyway, please see your ticket reply so that we can resolve this ASAP 🙂
  8. 500 errors should be logged in the servers error log
  9. There was a setting in vBulletin where you could define a time cutoff ( 30 days by default) and then it would just count the members which were online in these last X days and return them as active members. Quite useless statistic for the frontend IMO:)
  10. The recent submission of the 2.2.0 final release was unfortunately not approved, because it wasn’t following our marketplace guidelines .
  11. Hi, Do you mean real apiendpoints using the IPS REST API or regular own controllers inside app/modules/front/... ? If the latter, then you can use the Application::allowOfflineAccess method to control if the specific page should be accessible even in offline mode. /** * Can view page even when site is offline * * @param \IPS\Application\Module $module The module * @param string $controller The controller * @param string|NULL $do To "do" parameter * @return bool */ public function allowOfflineAccess( \IPS\Application\Module $module, $controller, $do )
  12. That's intentional, IN_DEV uses the applications/x/dev/lang.php files You'll have to enable this via the DEV_USE_FURL_CACHE constant You an disable this by setting the IN_DEV_STRICT_MODE constant to false.
  13. No We're providing a list of all changes incl. BC breaks once we release the first BETA version.
  14. I guess that's the problem then 😉 You'll need the dev files for all installed apps and plugins
  15. We have removed the CSRF key in many areas for 4.6 . Not sure about the filters
  16. We have fixed here few issues for an upcoming release:)
  17. Please submit a ticket so that we can take a look at this.
  18. Take a look at the log, then you'll know how many calls are being made;) That said, there's no way to disable logging globally, but you can enable/disable the logging for each endpoint.
  19. You can change this on the REST API - API Log page, but there's no way to disable the logging, you can only reduce the timeframe to 1 day.
  20. We have a free 3rd party app in our marketplace which could be used for this.
  21. Have you banned gmail? Review your ban filters in your ACP => Members => Ban Setting
  22. I guess you're meaning the new block inside topics? The feature is called Topic Summary and you can edit the settings or disable this feature completely in your ACP on the Forum Settings Page.
  23. What's eating up the space? The database or files on your filesystem? Are your tasks running? If not, the cleanup task which cleans up stuff like the guest cache is never called, which would explain a huge increase in the database size.
  24. Sounds like an issue with URL rewrites. Review your SEO settings in the ACP and make sure that the 4.5 htaccess file is present in the communities root directory.
  25. Does the user have permissions to edit the blog?
×
×
  • Create New...