Jump to content

teraßyte

Clients
  • Posts

    33,411
  • 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. Yes, this was a bug they fixed in 4.7.12. The fix for it was in the globalTemplate template, which is one of the most edited. You're missing that change most likely.
  2. Yes, theme updates count, and most likely the size is the problem. The marketplace allows files up to 2 MB. That file is at least 8 times larger. Your server doesn't have enough time to process the entire file. Usually, I would simply suggest asking your hosting to raise the timeout value, but given the size, I'm also curious as to what application you're trying to upload. Maybe you could also look into reducing the TAR's size by asking the developer if it's possible.
  3. Yes, that. However, the console is showing a generic 500 error, so you need to check your server's logs to find out the real error.
  4. Yes, it's possible to create a private page for moderators only if you have the Pages application. Simply select only the Moderators group after creating the page. Or you can edit a current page's permissions by clicking on the Menu and then the Lock icon. No, the only place you can add a link is the menu by using the Menu Manager. If you want a link on the ModCP page, you'll have to edit the template or have someone make a quick plugin for you. (Using a plugin allows the templates to auto-update in future versions)
  5. Steps to reproduce: Setup an RSS Feed Import for a Pages database and enter a value in the Title Prefix field. Check the imported feed items and you'll see the prefix is missing. If you setup the same feed to import into a forum instead, the title prefix is properly used.
  6. That doesn't tell much, unfortunately. Try looking at your browser's console, there should be a more specific error logged there.
  7. How big is the TAR file you're uploading? Have you tried installing any other applications or plugins? A timeout error means the server didn't have enough time to process it. I can think of various possibilities: The TAR file is too big The TAR file is corrupt or badly formatted (maybe it wasn't exported correctly or the install files aren't correct) Your server's timeout value is too low (you said installing from the marketplace works, so this is unlikely)
  8. Check your conf_global.php file and be sure the ibf_ prefix is properly set: <?php $INFO = array ( [...] 'sql_tbl_prefix' => 'ibf_', [...] );
  9. Just to confirm, when you look at the database on the old VPS, is the table also missing there? Or maybe it's marked as crashed? If it is, I can't see how the forum was working without it. That said, you're lucky because the table in the error doesn't hold any permanent data, but only temporary caches that can be recreated. You can recreate the table manually on the new server by running this query: CREATE TABLE `core_store` ( `store_key` varchar(150) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT 'Key', `store_value` longblob DEFAULT NULL COMMENT 'Value', PRIMARY KEY (`store_key`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; If your tables use a different collation be sure to change "utf8mb4 / utf8mb4_unicode_ci" to whatever other collation the database is using. The only problem now is to understand if this is the only missing table, or if there are others. 🤷‍♂️
  10. Indeed, you're missing a table. Looks like the database wasn't restored properly.
  11. 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.
  12. 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).
  13. 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. 😉
  14. 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
  15. 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:
  16. Given the situation, the only real option is a custom modification that adds a new API endpoint to create a group. 🤷‍♂️
  17. 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.
  18. 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.
  19. 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.
  20. 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); }
  21. 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).
  22. 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.
  23. Based on the description, this modification does what you want:
  24. 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
  25. 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.
×
×
  • Create New...