Jump to content

teraßyte

Clients
  • Posts

    33,395
  • Joined

  • Days Won

    47

 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 teraßyte

  1. Unfortunately, a 500 error is too generic. Look at your server's logs to check what the real error is. Also, version 4.2.5 has a PHP 5.6.0 required version and a 7.0.0 recommended one. Anything higher or lower might be what's causing the error, too.
  2. A problem with hook186 in #7 most likely. You can look up from which Application/Plugin the hook ID is in ACP > Support > View XXX Third Party Hooks (right sidebar).
  3. Based on what you posted I now have a clearer idea of what you're doing, but I still see a few issues and optimizations that can be made: You can use a quick in_array() check for the group instead of multiple OR checks. Also, note that your code doesn't take into account secondary groups, if you want to check also those, you need to adjust the code. The $assign_point variable is not defined before the IF check, if the user is in a group outside of the listed IDs, PHP 8 will throw an error about an unknown variable. I see that you're basically loading the credit balance from a table, adding 250 to it, and then updating the same table back. The whole process can be simplified in a single query instead. The reset DB prefix code can be moved inside the IF check, if the user doesn't need a credit balance update, there's no point running it. Here's an updated code based on the points above: protected function processAfterCreate($comment, $values) { # Comment/uncomment either line below based on what you want #if ( \in_array( \IPS\Member::loggedIn()->member_group_id, array( 3, 4, 7, 8 ) ) ) # This line checks only the primary group if ( \IPS\Member::loggedIn()->inGroup( array( 3, 4, 7, 8 ) ) ) # This line checks also secondary groups { # Temporarily disable the DB prefix $previousPrefix = \IPS\Db::i()->prefix; \IPS\Db::i()->prefix = ''; # Update credit_balance column to add 250 credits to its current value \IPS\Db::i()->update('plug_mailing_master', "credit_balance=credit_balance+250", array('user_id=?', \IPS\Member::loggedIn()->member_id)); # Reset prefix \IPS\Db::i()->prefix = $previousPrefix; } return parent::processAfterCreate($comment, $values); } The code checks if the user has one of the specified groups, and adds 250 to their credit balance value based on their member ID. No need for anything else. P.S.: If you use the Code button in the editor the code you post will look better and formatted for the appropriate language. 😉
  4. Sorry, I have nothing else right now. Maybe someone else will be able to spot something I missed. 🤷‍♂️ Out of curiosity, if your developer goes back and tries the code that was giving the first exception, what does he get now? In theory, he should still get the latest exception (since it triggers before the invalid recipient one): { "errorCode": "1C374\/2", "errorMessage": "INVALID_SENDER" } But I'm wondering if he still gets the other one instead: { "errorCode": "1C374\/3", "errorMessage": "INVALID_RECIPIENT" } I'm talking about this post => https://invisioncommunity.com/forums/topic/475882-documentation-on-how-ips-message-is-created/?do=findComment&comment=2957027
  5. Yup, it's been mentioned on the forum already, and while IPS did list the change in the changelog, it wasn't clear at all what the removal would actually entail: See this topic:
  6. Given the situation, the only real option is a custom modification that adds a new API endpoint to create a group. 🤷‍♂️
  7. The content remains the same, the display of the posts simply changes to show an upvote/downvote option. Oh, and the ordering changes, too. The posts will be ordered by their votes by default instead of their date. In case the order change is a problem, I have a free modification that sets it back to date.
  8. Steps to reproduce: Enable IN_DEV. Go to a blog that the account can manage. Click on Manage Blog > Edit Blog to load the ajax setting popup. Click Save. This exception is thrown by the core extension EditorLocations/Blogs: RuntimeException thrown with message "Unknown canBeModerated: blogs-blog-3" Stacktrace: #9 RuntimeException in /applications/blog/extensions/core/EditorLocations/Blogs.php:83 #8 IPS\blog\extensions\core\EditorLocations\_Blogs:canBeModerated in /system/Helpers/Form/Editor.php:721 #7 IPS\Helpers\Form\_Editor:getUploader in /system/Helpers/Form/Editor.php:185 #6 IPS\Helpers\Form\_Editor:__construct in /applications/blog/sources/Blog/Blog.php:417 #5 IPS\blog\_Blog:form in /applications/blog/modules/front/blogs/view.php:241 #4 IPS\blog\modules\front\blogs\_view:editBlog in /system/Dispatcher/Controller.php:107 #3 IPS\Dispatcher\_Controller:execute in /applications/blog/modules/front/blogs/view.php:54 #2 IPS\blog\modules\front\blogs\_view:execute in /system/Dispatcher/Dispatcher.php:153 #1 IPS\_Dispatcher:run in /init.php:936 #0 IPS\Dispatcher\toolbox_hook_dispatcherStandard:run in /index.php:13 The code is "blogs-blog-3" because I was editing the blog with ID 3.
  9. Steps to reproduce: Create a new blog. When on the blog page click to open the menu Manage Blog. Now open the first link Edit Blog, but do it in a new browser tab/window. You'll get this error: Error code: 2S119/1 ==================== The CSRF protection key did not match. This may indicate a plugin or theme is out of date. Please contact technical support for more information.
  10. I'm having a really hard time understanding your code because it's all partial or missing context and variables. Anyway, you can temporarily disable the prefix in the database class if your tables don't have it. Or you can keep using manual query() calls, but there is no need to use mysqli_fetch_assoc. See the code below, I tried to update your processAfterCreate() function above with more consistent code: public function processAfterCreate($comment, $values) { # Remove prefix $previousPrefix = \IPS\Db::i()->prefix; \IPS\Db::i()->prefix = ''; # Vars $reward_mailing_points = 10; # Not sure where you're pulling this value from, so I set an arbitrary 10 here as example $cc = 0; # Get result - If this query always returns only 1 row, it can be changed to use ->first() $result = \IPS\Db::i()->select('*', 'xxxx', array( 'user_id=?', \IPS\Member::loggedIn()->member_id ) ); foreach( $result as $row ) { $cc += $reward_mailing_points + intval($row['cc']); } # Update database with new $cc value \IPS\Db::i()->update( 'xxx', array( 'credit_balance' => $cc ), array( 'user_id=?', \IPS\Member::loggedIn()->member_id ) ); # Reset prefix \IPS\Db::i()->prefix = $previousPrefix; return parent::processAfterCreate($comment, $values); }
  11. This one, I'm really not sure... This is the code that throws the exception: /* Make sure there is a valid sender */ if ( !isset( \IPS\Request::i()->from ) OR !\IPS\Member::load( (int) \IPS\Request::i()->from )->member_id ) { throw new \IPS\Api\Exception( 'INVALID_SENDER', '1C374/2', 404 ); } It gets triggered if the from value is missing, or if there is no member with the specified ID. Based on your screenshot above the member ID 10 exists, though. 🤷‍♂️ The funny thing is that this exception is thrown before the other INVALID_RECIPIENT one you posted above. Was the member with ID 10 deleted perhaps? If it was working before, I have no other idea why it doesn't now. EDIT Taking another look at your last screenshot, I see the from value is being passed as a string rather than an integer: 'from' => '10' I don't think it will change anything, since the code is casting it as (int), but try changing that row to: 'from' => 10 P.S.: You have the session cookie, authorization key, etc., in that screenshot. Probably best if you hide them. (Unless you've already regenerated them after the screenshot).
  12. A few things: In the query, you are using $user_id, but there is no such value defined anywhere in the code. You are not saving the updated $cc value back to the database, that's why it's not working. You're using a mix of IPS and non-IPS functions to access the DB data. You should stick to using a single method to keep things consistent. Is the table you're trying to update in the same database as Invision Community? If it's in an external database, you're using the wrong code to connect to it. Using simply \IPS\Db::i() will try to load the table from the forum's database, not your external one.
  13. Based on the description, this modification does what you want:
  14. Yup. The problem is that the from value is an integer, but the to value is an array instead and he's passing it as an integer: to array One or more user IDs conversation is sent to
  15. As Nathan said, the htaccess files are different: The htaccess file for friendly/rewrite URLs goes into the root folder (where the conf_global.php file is located). The htaccess file for the API goes into the /api folder.
  16. You can use the DB class to run queries, there is no need to use a separate dbconnect.php file:
  17. Are the vBulletin files available on the server where Invision Community is installed? Unless they are on the same server, and in a folder the converter application can access, it won't work.
  18. Indeed. Based on your screenshot, there is no API KEY being passed as a parameter. Your developer can read more about it on this page: https://invisioncommunity.com/developers/rest-api
  19. The second setting Rewrite URLs? in your screenshot is disabled. When that setting is disabled all your URLs will contain the index.php?/ part I added above for the API URL. Enabling the setting and uploading the required .htaccess file will get rid of that part. And the original API URL in the documentation will work without having to use the updated URL I provided in my previous reply.
  20. Since you have Friendly URLs disabled, your developer needs to use this URL instead: https://forum.pinpics.com/api/index.php?/core/messages I suggest enabling FURLs on the server, though. The URLs will look cleaner and will be easier to read. Also, Friendly URLs will be a requirement in v5: It would be best to enable them now and also have the links indexed by search engines with that format from the start.
  21. The unique hash for the RSS is generated in this order: If the user is a guest, it generates a random string. If the user is logged in and has a password hash, it generates a unique key based on it. (People who login with a 3rd party account, like FB or X, might not have it.) If the user is logged in but has no password hash, a random unique hash is generated for their account, and there is no way to edit it. (It would require a modification, or you can edit it directly in the database.) So, to make a quick summary, as long as you change the account's password, the unique hash is regenerated and the old URL won't work anymore for them.
  22. Add the Custom Blocks widget from the Pages app in the sidebar, then edit its settings and select the trending topics block.
  23. Check that mod_rewrite is available and enabled. You can disable FURLs as a workaround, but it would be better to get mod_rewrite working.
  24. Unless you share the "XXX Latest Topics" feed link, nobody can access it. It contains your member ID and a unique key for your account. Since it's a private club, people without access to it will never even see the link.
  25. Have you checked that the webhook in Stripe is setup properly? I know someone who had the same issue recently, and their webhook was missing several events. Because of this, the site was not receiving the correct data and left the payment marked as pending.
×
×
  • Create New...