Mercury Forever

Will this feature ever be available for onprem installations?

This version resolves the bug (only over MacOS 14) Version 118.0.5993.88 (Official Build) (x86_64)

Dear, just to complement, this is a Google bug for those browsers based on chromium. https://bugs.chromium.org/p/chromium/issues/detail?id=1487920

I just did another test from my computer, I entered my community with another user and the date and time looks fine, is there any parameter at the account level that is related to this? Connected to my Admin account. Logged in as another user

I have verified that from the cell phone it looks good, the strange thing is because it shows it wrong on my computer. I don't understand why it happens like this.

This is my team's configuration in relation to the time zone, it is the same as the server, but every post I see is all with 3 hours.

Are you telling me that the date/time with which the post is registered in the database is taken by the client??? being a Web application??? Is the interpretation correct? What I am seeing is that the registry does not take the time zone and all the posts are left with a future time.

Hello everyone, I have the following problem (and I don't know how long, I only realized today). The server has the correct date with the correct time zone for my country, but when creating a topic the time of the post does not take the time zone. Post date server

In my case it was like this, which left me pleasantly surprised, I think it was a plus and knowledge of the engineers who did the work, the only adjustments I made were: 1) enable my IP address in the firewall to enter cPanel services and via ssh. 2) copy the crontrab at the linux level 3) make an adjustment at the Apache level for the Worker number that my community supports, with the default value 150, it doesn't work, I must adjust it to 1000. In summary, this was the level of changes I made post migration of the configuration I contracted. Regards,

Unfortunately I do not have the technical details of the change, since this was a service that I contracted with my hosting provider. I imagine that via cpanel & whm, it is possible to review these URLs that may support or provide some guide. https://docs.cpanel.net/knowledge-base/technical-support-services/cpanel-migration-services-and-guides/?_ga=2.15552561.609972242.1694896984-1056579917.1690244026 https://docs.cpanel.net/knowledge-base/transfers-and-restores/how-to-move-all-cpanel-accounts-from-one-server-to-another/ https://docs.cpanel.net/whm/transfers/transfer-tool/?_ga=2.251476993.609972242.1694896984-1056579917.1690244026 https://www.youtube.com/watch?v=tAMsOI_AuhA&ab_channel=RedServerHost Regards

I recently changed servers after the end of support for Centos 7. New configuration: AlmaLinux 8.8 and MariaDB 10.6. Everything works perfectly. Regards.

Hi @Miss_B, Indeed, that line of php.ini (disable_functions) is blocked. Now it works when you remove it.

Hello @Daniel F, How can I validate that? As background, last weekend I made a server change, to update from Centros7 to AlmaLinux 8.8, this was a server change from a scratch implementation. Regards,

This is the content of the file, I don't know if it is corrupt or has something inconsistent. phpinfo.php ( PHP script, ASCII text ) <?php /** * @brief Display phpinfo * @author <a href='https://www.invisioncommunity.com'>Invision Power Services, Inc.</a> * @copyright (c) Invision Power Services, Inc. * @license https://www.invisioncommunity.com/legal/standards/ * @package Invision Community * @since 4 December 2020 */ namespace IPS\core\modules\admin\support; /* To prevent PHP errors (extending class does not exist) revealing path */ if ( !\defined( '\IPS\SUITE_UNIQUE_KEY' ) ) { header( ( isset( $_SERVER['SERVER_PROTOCOL'] ) ? $_SERVER['SERVER_PROTOCOL'] : 'HTTP/1.0' ) . ' 403 Forbidden' ); exit; } /** * Display phpinfo */ class _phpinfo extends \IPS\Dispatcher\Controller { /** * @brief Has been CSRF-protected */ public static $csrfProtected = TRUE; /** * Execute * * @return void */ public function execute() { \IPS\Dispatcher::i()->checkAcpPermission( 'get_support' ); parent::execute(); } /** * Support Wizard * * @return void */ protected function manage() { phpinfo(); exit; } }

Hello everyone, I finally identified the problem, it was indeed a third-party application called "Subscription Privacy" by Thomas, which no longer exists in the Market. The truth is that I don't know what function it served "other than not making the module work." By removing it, I no longer have the "blessed" 500 error (very generic and related to Apache otherwise) Greetings to all who contributed, responded and helped reach the RCA. Regards,