Jump to content

Stuart Silvester

Invision Community Team
  • Posts

    3,633
  • Joined

  • Last visited

  • Days Won

    27

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Posts posted by Stuart Silvester

  1. It sounds good, but I think you might be missing my point.

    Going forwards if an Administrator chooses to use our Cookie Consent bar, your non-essential cookies won't be saved in the visitors browser unless they specifically opt-in to them. Not all customers will use the cookie consent banner, but for those that will you'll probably want to consider how to handle that.

    My point mainly for Adriano was not to just specify all cookies as essential, since that degrades the feature and may cause it to be non-compliant in some locales.

  2. 16 minutes ago, Adriano Faria said:

    It is probably the 4.7.11 cookie thing where you need to inform the cookies; not sure how to do with themes.

    Following…

    A cookie to control colour would probably not be deemed to be 'essential' any way, so be careful not just to specify all cookies in this method because that won't make sense.

    1 hour ago, drawncodes said:

    isn't working anymore on the last version, why?

    When the new Cookie Consent system is enabled, non-essential cookies will not be set unless the end-user has opted in to them. There are a few issues currently with 4.7.11 where some of the JS cookies may be getting blocked if the Cookie Consent is not enabled. We're working on fixes for the reported issues.

  3. 14 minutes ago, Adriano Faria said:

    Wow, so there's another issue there as it is working. 😄

    Are you going to release a patch or only next month with a new version?

    @Stuart Silvester, this is working for me:

    	public function _getEssentialCookieNames(): array
    	{
    		$appCookie = \IPS\Settings::i()->ntr_CookiePrefix . '_*';
    
    		return array( $appCookie );
    	}

    It shouldn't?

    You may not have the cookie consent mode fully enabled, currently it requires {cookies} and nothing else in the text box to activate, then you'll see two buttons.

    That however isn't going to work on the cookies page if the prefix can be changed, it uses that key to load the language strings to explain the reason why the cookie exists.

    We'll continue working on the issues we've got then evaluate how we're going to move forwards.

  4. 13 minutes ago, Adriano Faria said:

    cookies from this app are dynamic (stores the forum ID) and the new function doesn't seem to support this

    We're adding this (needed for forum passwords). Use a * at the end of the cookie name in that method ( I.e. ipbforumpass_* ). Will only work for PHP set cookies.

  5. On 6/17/2023 at 8:16 AM, PatrickRQ said:

    And nothing special/relevant in PayPal API call/error logs

    With due respect, that's something we need to determine. Looking at your stack trace, the response isn't what we're expecting so I would like to see what's different with that response. The logs I want to see will be sent to the 'checkout/orders' endpoint.

  6. On 6/16/2023 at 10:47 PM, Wolfie said:

     

    Error: Class "IPS\cms\Records1" not found (0)
    #0 /home/***/applications/core/sources/Setup/Upgrade.php(594): IPS\cms\setup\upg_104030\_Upgrade->step1()
    #1 /home/***/applications/core/sources/Setup/Upgrade.php(326): IPS\core\Setup\_Upgrade->step1()
    #2 /home/***/applications/core/modules/setup/upgrade/upgrade.php(47): IPS\core\Setup\_Upgrade->process()
    #3 /home/***/system/Helpers/MultipleRedirect/MultipleRedirect.php(93): IPS\core\modules\setup\upgrade\_upgrade->IPS\core\modules\setup\upgrade\{closure}()
    #4 /home/***/applications/core/modules/setup/upgrade/upgrade.php(32): IPS\Helpers\_MultipleRedirect->__construct()
    #5 /home/***/system/Dispatcher/Controller.php(118): IPS\core\modules\setup\upgrade\_upgrade->manage()
    #6 /home/***/system/Dispatcher/Setup.php(220): IPS\Dispatcher\_Controller->execute()
    #7 /home/***/admin/upgrade/index.php(34): IPS\Dispatcher\_Setup->run()
    #8 {main}

     

    Couldn't afford to do it sooner.  Also, push come to shove, I can just ask you all to do it. 😉

     

    Can you provide the logs for the two other issues I asked about? specifically those are something I would like to look at. This one is probably just a side-effect of the upgrade halting.

  7. This is another good reason to keep up to date. Many of those upgrade steps you've had to run were written 10 years ago and as @teraßyte mentions, may not be fully compatible with PHP 8 or some areas of the framework they use have drastically changed over time.

    I do have an issue open tracking some 3.4 upgrade issues based on previous feedback from @teraßyte and we'll try to address those where we can but please keep up to date with releases going foward.

  8. 1 hour ago, derpunker said:

    @Stuart Silvester

    Patch installed but still not working!

    Login iusse fixed => I can confirm.

    But the banner for guests keeps popping up unintentionally!

    For logged in Users:

    • Cookie banner pops up for an part of a second which is really anoying. Happen ins Chrome/Edge with mobile view.

     

     

    For guests:

    • If anything else than {cookies} is added in the AdminCP as text, the banner pops up after every reload.
    • Using only {cookies} as content helps in this case.

     

     

     

     

     

    Please fix and provide another patch.

    Thanks.

    I suspect that's related to the other item you posted, As a work around you could use the standard cookies tag and translate the 'cookies_message' string instead: 

    I have logged some information and we'll take a look at that next week. This patch was specifically to address the impacting appearance of not being logged in in some circumstances..

     

×
×
  • Create New...