teraßyte

I've seen this happen before on another site, and it was caused by a <DIV> element not being closed properly in one of the blocks' content. As Jim mentioned above, remove all your blocks, re-add them 1-by-1, and refresh the page each time to double-check that the sidebar is still in its correct place.

@Daniel F I guess the fix is in 4.7.8? I'm not seeing it in 4.7.7.

Yes, it's version 4.7.7 with IN_DEV mode enabled. PHP 8.0.23 in case it helps. I'll run some more tests later to see if I can pinpoint better why it's happening.

It's the Kitchen Sink application:

Recounting a member's reputation from a profile in ACP makes the code throw this exception: Whoops\Exception\ErrorException thrown with message "Object of class IPS\Db\Select could not be converted to int" Stacktrace: #11 Whoops\Exception\ErrorException in /dev47/system/Member/Member.php:1334 #10 Whoops\Run:handleError in /dev47/system/Member/Member.php:1334 #9 IPS\_Member:get_pp_reputation_points in /dev47/system/Patterns/ActiveRecord.php:335 #8 IPS\Patterns\_ActiveRecord:__get in /dev47/system/Member/Member.php:3509 #7 IPS\_Member:apiOutput in /dev47/applications/core/extensions/core/MemberSync/System.php:426 #6 IPS\core\extensions\core\MemberSync\_System:onProfileUpdate in /dev47/system/Member/Member.php:4033 #5 IPS\_Member:memberSync in /dev47/system/Member/Member.php:442 #4 IPS\_Member:save in /dev47/init.php:935 #3 IPS\_Member:recountReputation in /dev47/init.php:935 #2 IPS\core\modules\admin\members\_members:recountReputation in /dev47/system/Dispatcher/Controller.php:107 #1 IPS\Dispatcher\_Controller:execute in /dev47/system/Dispatcher/Dispatcher.php:153 #0 IPS\_Dispatcher:run in /dev47/init.php:935 The issue comes from the code below in /system/Member/Member.php on lines 3821-3830: /** * Recounts reputation for this member * * @return void */ public function recountReputation() { $this->pp_reputation_points = \IPS\Db::i()->select( 'SUM(rep_rating)', 'core_reputation_index', array( 'member_received=?', $this->member_id ) ); $this->save(); } Simply adding ->first() in the query fixes it: $this->pp_reputation_points = \IPS\Db::i()->select( 'SUM(rep_rating)', 'core_reputation_index', array( 'member_received=?', $this->member_id ) )->first();

As mentioned in the topic's title, in 4.4.7 with the new gallery version includes a new IMAGES profile extension when viewing a member profile. However, unlike other tabs (for example the ALBUMS TAB in the same gallery application) it doesn't check if the user has uploaded any images before deciding if it should be shown or not. This is the code inside /applications/gallery/extensions/core/Profile/galleryImages.php: public function showTab(): bool { return TRUE; } The ALBUMS profile extension in the same folder (gallery.php) does check if the user has any albums before showing the profile's tab.

If all your developer is doing is changing the values of the constants, then it would be better to create a constants.php file rather than editing init.php.

Often the issue is that the conf_global.php file has an HTTP URL in it, and your server tries to redirect to HTTPS. Check your conf_global.php file and also disable any automatic redirects server-side. The suite handles redirects on its own.

That upgrade data is cached. Try clearing the files in your /datastore folder and retry.

On a big site with 1.5M rows in the plugin's table the queries are extremely slow and take up to ~3 seconds. Looking at the table and the code, I found there are no indexes that can be used to speed up the queries. After manually adding a couple of indexes the queries are almost instant. Here are the 2 indexes I added: ALTER TABLE `followspecificusercontent_data` ADD INDEX `cfe_rel_id_member_id` (`cfe_rel_id`, `cfe_member_id`); ALTER TABLE `followspecificusercontent_data` ADD INDEX `cfe_type_rel_id` (`cfe_type`, `cfe_rel_id`);

@Daniel F This was already fixed in 4.7.5 or 4.7.6 I believe. At least I'm not seeing the issue on 4.7.6. His (custom?) theme probably needs an update.

Looks like you solved it. The memory limit is set to 1024M, and the error is gone.

Unfortunately, reCAPTCHA is quite useless nowadays. Try switching to use hCaptcha instead:

Your issue is that it's the first post. First posts never have the delete option. To delete them, you need to delete the topic itself. Your user can find the Delete (topic) option in the Moderation Actions menu above instead.

Just hit a "table already exists" error installing a plugin locally because this bug isn't fixed. 🙄 Adding a check in the upgrade file to not execute the create table query is an option, but that's just a workaround and not the proper fix.

The only way would be to compare the list of tables to a fresh install and account for the additional tables added by installed modifications. That's how I usually do it, especially after a legacy upgrade.

@Adriano Faria In case you want to add it in a future version, here's the code I added right before the code to uninstall the plugin in order to convert old background data: # Plugin column available? Convert the background data if ( \IPS\Db::i()->checkForColumn( 'core_members', 'ProfileBackgroundImage' ) ) { \IPS\Db::i()->insert( 'profilebackgrounds_data', \IPS\Db::i()->select( 'member_id, ProfileBackgroundImage', 'core_members', 'ProfileBackgroundImage IS NOT NULL' ) ); } Also, I had problems getting the image to display in the profile. I was receiving this error: Unknown column '' in 'where clause' After debugging, the problem is in the file /applications/profilebackgrounds/hooks/memberModel.php. The profileBackgroundImage() function currently uses this code to load the background data: return \IPS\Db::i()->select( 'pb_location', 'profilebackgrounds_data', array( 'pb_location!="" AND pb_member_id=?', $this->member_id ) )->first(); Unfortunately, some MySQL versions are picky and don't like double quotes in queries. Once I swapped around single and double quotes in the WHERE parameter it started working properly: array( "pb_location!='' AND pb_member_id=?", $this->member_id )

Here's a guide on the options currently available: Also, as long as FB and/or Twitter are set up, when posting a new item (topic, file, etc) there is also a checkbox you can select to automatically share the content: As shown above, you have to manually do it though, there is no option to automatically do it in specific forums right now. You can either contact the developer of the previous modification to see if they're willing to update it or hire another developer to make it for you: https://invisioncommunity.com/third-party/providers/

@Daniel F No idea honestly. I'm just helping someone upgrade their site from 4.4. There are 5 such items in the table. And after you mentioned it I looked also for \IPS\gallery\Album\Item and there is 1 such record. Looking at the database there are 5 albums like that, all promoted in the second half of 2017. And based on the upgrade history table, the suite was on version 4.2.3. An old bug maybe? I guess the proper fix here then would be to update any \IPS\gallery\Album in the promote_class column to \IPS\gallery\Album\Item instead.

Starting the process to rebuild achievements from ACP throws an error rebuilding a gallery album as promoted content. The issue specifically happens in the file /applications/core/extensions/core/AchievementAction/ContentPromotion.php inside the function rebuildRow() on lines 249-255: case 'core_social_promote': $promote = \IPS\core\Promote::load( $row['promote_id'] ); $promote->object()->author()->achievementAction( 'core', 'ContentPromotion', [ 'content' => $promote->object(), 'promotype' => 'promote' ] ); break; The problem in the code above is that when it hits a gallery album entry, which is a node, it tries to call \IPS\gallery\Album::author() which exists only in content items. The correct code for an album would be \IPS\gallery\Album::owner() instead. This is the error's backtrace: Error: Call to undefined method IPS\gallery\Album::author() (0) #0 /home/admin/web/domain.com/public_html/forum/applications/core/extensions/core/Queue/RebuildAchievements.php(141): IPS\core\extensions\core\AchievementAction\_ContentPromotion::rebuildRow(Array, Array) #1 /home/admin/web/domain.com/public_html/forum/system/Task/Task.php(47): IPS\core\extensions\core\Queue\_RebuildAchievements->run(Array, 103) #2 /home/admin/web/domain.com/public_html/forum/applications/core/tasks/queue.php(43): IPS\_Task::runQueue() #3 /home/admin/web/domain.com/public_html/forum/system/Task/Task.php(375): IPS\core\tasks\_queue->IPS\core\tasks\{closure}() #4 /home/admin/web/domain.com/public_html/forum/applications/core/tasks/queue.php(55): IPS\_Task->runUntilTimeout(Object(Closure)) #5 /home/admin/web/domain.com/public_html/forum/system/Task/Task.php(274): IPS\core\tasks\_queue->execute() #6 /home/admin/web/domain.com/public_html/forum/applications/core/modules/admin/settings/advanced.php(751): IPS\_Task->run() #7 /home/admin/web/domain.com/public_html/forum/system/Dispatcher/Controller.php(107): IPS\core\modules\admin\settings\_advanced->runTask() #8 /home/admin/web/domain.com/public_html/forum/applications/core/modules/admin/settings/advanced.php(38): IPS\Dispatcher\_Controller->execute() #9 /home/admin/web/domain.com/public_html/forum/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\admin\settings\_advanced->execute() #10 /home/admin/web/domain.com/public_html/forum/admin/index.php(13): IPS\_Dispatcher->run() #11 {main} As a temporary measure, I've replaced the code above with this one: case 'core_social_promote': $promote = \IPS\core\Promote::load( $row['promote_id'] ); if ( $promote->object() instanceof \IPS\Gallery\Album ) { $promote->object()->owner()->achievementAction( 'core', 'ContentPromotion', [ 'content' => $promote->object(), 'promotype' => 'promote' ] ); } else { $promote->object()->author()->achievementAction( 'core', 'ContentPromotion', [ 'content' => $promote->object(), 'promotype' => 'promote' ] ); } break; Not the best fix though, so you'll probably want to implement something different. 😋 === EDIT: Forgot to mention that the bug is still present in 4.7.7 Beta 3.

Can confirm the fix worked. 👍

After updating the application to the latest version (2.5.5) we're getting an error trying to delete an account: Error: Call to undefined method IPS\deletemyaccount\Members::setMemberData() (0) #0 /home/admin/web/domain.org/public_html/forum/system/Task/Task.php(47): IPS\deletemyaccount\extensions\core\Queue\_membersTable->run(Array, 0) #1 /home/admin/web/domain.org/public_html/forum/applications/core/modules/admin/system/background.php(87): IPS\_Task::runQueue() #2 /home/admin/web/domain.org/public_html/forum/system/Helpers/MultipleRedirect/MultipleRedirect.php(93): IPS\core\modules\admin\system\_background->IPS\core\modules\admin\system\{closure}(Array) #3 /home/admin/web/domain.org/public_html/forum/applications/core/modules/admin/system/background.php(138): IPS\Helpers\_MultipleRedirect->__construct(Object(IPS\Http\Url\Internal), Object(Closure), Object(Closure)) #4 /home/admin/web/domain.org/public_html/forum/system/Dispatcher/Controller.php(107): IPS\core\modules\admin\system\_background->process() #5 /home/admin/web/domain.org/public_html/forum/applications/core/modules/admin/system/background.php(42): IPS\Dispatcher\_Controller->execute() #6 /home/admin/web/domain.org/public_html/forum/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\admin\system\_background->execute() #7 /home/admin/web/domain.org/public_html/forum/admin/index.php(13): IPS\_Dispatcher->run() #8 {main} As the error says there is no setMemberData() function in the \applications\deletemyaccount\sources\Members\Members.php file. I just see 5 class variables defined inside it with no functions at all. Since it's a staging site we also tried removing and reinstalling the application from scratch just in case. The error is still there and comparing the files nothing changed.

Email notifications are always sent by default. But there is indeed no option for inline or push notifications currently.

From your first replies, I had assumed you'd already updated. What forum & PHP version are you currently using?

PHP 8 is required starting from version 4.7.4+. If you switch back to PHP 7.4 after the upgrade you'll get errors all over.