IPCommerceFan

13 hours ago, Marc Stridgen said:

Content will of course. In terms of layout/theming etc, of course, you would need to visit that once v5 is out to update anything required. But that would apply to any area.

Its based on permissions, so if they have permission yes.

We would then need to an example. I would advise creating a new topic with your issue though, rather than in this topic

Excellent, thanks @Marc Stridgen.  Yeah the concern was primarily for the content since I generally use stock themes. 👍

If a site has clubs/pages meticulously set up and full of content, will it all carry over when it comes time to upgrade to V5?

On 1/15/2024 at 10:04 AM, sulervo said:

Also Stripe webhook is not working if it has anything to do with this.

If you mean Stripe isn't appearing as a payment method at checkout, remember to set it as an available method on each package in the store you wish to use it for.

This sounds like a net positive for developers.   Two primary issues (based on observation) have always been how long it takes for IPS to approve an app, and the fact IPS takes a cut.   This knocks them both out, so it seems like a win to me.

I wonder though, since the Marketplace is essentially a portal for paid downloads, will this change affect the need/desire for IPS to continue developing/maintaining the Downloads or Commerce apps in the long run (V5)?

I have great disdain for Safari. lol

We recently implemented some dynamic dropdowns which utilize jquery to populate the fields via ajax calls to a php script.  For whatever reason, they work perfectly on windows, linux, and android using a variety of browsers, and even with iPad and iPhone, but NOT with the latest version of Safari for iMac and Macbook.  I'm sure I'll figure it out, but it just goes to show Apple implements things quite differently from everyone else (even themselves! lol)

In my specific case, Facebook requested credentials to be able to see how the Facebook Connect app is using client data.   This involves giving them access to the Login & Registration --> View and Manage Login Methods area - and ONLY that area.

When testing the login though, I noticed the "Log Out All Users" button was still available.  I'd really rather not have a Facebook agent clicking that button maliciously or by accident, so I can't comply with their request to log in and review the settings. (I'm currently waiting to see if they complain about it)

More broadly though, I can imagine anyone with a need to delegate specific admin tasks would benefit from blocking this button.   

e.g. someone who processes reports, invoices, 3rd party add-ons (like Drip Campaigns), doesn't need the ability to log all users out.

I'd like to restrict a particular admin from being able to access the "Log Out All Users" button, however it appears there is no built-in way to do this.

I'd suggest adding this to the list of things we can restrict in a future version.  👍

Thanks for the heads up!

I really would rather get to the bottom of it if possible, so yes lets open up a ticket.  Thanks!

I dug around some more, and it was doing this even when we were on 4.6.10.

It seems it only happens with non-US addresses, so its a rather fringe issue for us.  If there is no "low hanging fruit" solution to this, I'm OK just living with it until we switch to Stripe.

This may be coincidence, but we upgraded from 4.6.10 to 4.7.8 recently, and ran into this again using the Braintree PayPal integration:

Quote

US state codes must be two characters to meet PayPal Seller Protection requirements.

The difference here is:

• I've verified the fix that was applied last time was retained.
• PayPal orders have been flowing just fine since the upgrade.
• The billing address that threw this error is in Mexico.

In any case, I've updated my site access info, and the Transaction # in question is 30656.

I'll also just state that this was duly noted!

Yup I'm figuring maybe the initial encoding is defaulting to some format the REST API on the php side isn't interpreting correctly.

Nice, I have a co-worker who keeps telling me I should learn C#, then F# since they're pretty much ubiquitous.  I've thus far ignored him and continue on my merry way with in php/mysql-land. lol

I don't know C#, but I would try sending a text field for troubleshooting purposes instead of trying to get an image to work.  If it sends over garbled text, then you may discover it is sending the text in the wrong encoding and can course-correct from there.

I ran into this recently with a Selenum script, where I used javascripts btoa() function to base64 encode some text, but when I received it on the php side, it was a bunch of gobbledegook.  In my case I had to say:

base64_decode(urlencode($_GET['stuff']));

instead of what I previously had:

$html = base64_decode($_GET['calidpanel']);

urlencode did the job of "un-garbling" the text before base64 decoding it.

For your case, Google led me to this result, which you may find useful:

https://stackoverflow.com/questions/46093210/c-sharp-version-of-the-javascript-function-btoa

Specifically:

Quote

Worked it out. For anyone wondering the encoding used is iso encoding. The btoa function in javascript can be replicated by using the following c# method:

public string encoding(string toEncode) { byte[] bytes= Encoding.GetEncoding(28591).GetBytes(toEncode); string toReturn = System.Convert.ToBase64String(bytes); return toReturn; }

Will do!

I noticed the release notes mentioned:

Quote

Added og:image tag to product pages.

I took that to mean Packages, but maybe I misread it and it really means all product-related pages.  Can you confirm it indeed covers Package Groups?

Thanks for taking care of this!

Incidentally, the Similar Content feature works nicely! 

@opentype's 'OG Image for Commerce Products' marketplace item popped up, and I purchased it.  👍

Hi,

When linking a Nexus product group to somewhere like Facebook, no image or the wrong image appears because the groups do not have og:image meta tags configured by default. 

We currently deal with this by running a mysql script periodically to add meta_url's and meta_tags to the core_seo_meta table.  ( the live tag editor )

We use this application as well, with PHP 8.0.23, and its been fine, however we have not updated to 4.7.2 yet.  It was last updated in July, so I'm optimistic @rebraf will update it now that this issue has come to light.   I'm guessing any update would be very minor and mostly a formality.

These work for me:

Default app:

$defaultApp = \IPS\Application::load(\IPS\Request::i()->app)->default;

Default module:

$defaultModule = \IPS\Application\Module::get(\IPS\Request::i()->app, \IPS\Request::i()->module)->default;

Ah yes, try this:

^(([1-9]\.([4-9]{1}|[4-9]{1}[0-9]))|[2-9]{0,9}\.[0-9]{1,2}|[0-9]{2,9}\.[0-9]{1,2}|[2-9]{0,9})$

Made an edit, try this:

^(([1-9]\.([4-9]{1}|[4-9]{1}[0-9]))|[2-9]{0,9}\.[0-9]{1}|[0-9]{2,9}\.[0-9]{1,2}|[2-9]{0,9})$

Updated!

https://regex101.com/r/iqeDII/6

^([1-9]\.([4-9]{1}|[4-9]{1}[0-9])|[2-9]{0,9}\.[0-9]{1}|[0-9]{2,9}\.[0-9]{1,2}|[2-9]{0,9})$

My understanding was that you only wanted to use 1 decimal place (only 1 dot allowed), which is why the original pattern didn't account for 1.40.

How many decimal places should be accounted for?

Glad you figured it out!

I'm going to post this here anyway, in case someone stumbles on this thread while searching for similar:

^([1-9]\.[4-9]{1}|[2-9]{0,9}\.[0-9]{1}|[0-9]{2,9}\.[0-9]{1})$

https://regex101.com/r/iqeDII/3

I tinkered with the idea in the form of a plugin, but couldn't quite reach the finish line due to having other obligations take priority.  Its just a few steps to reproduce, so I'll share the progress here in case anyone wants to pick up the baton:

• Create a new plugin
• Add a setting where we can save new field data
  
   
• In \plugins\<thenewplugin>\dev\settings.php, Create a Stack form element so that you can edit the plugin settings to add new lines.

  $form->add( new \IPS\Helpers\Form\Stack( 'addGtags_add_line', \IPS\Settings::i()->addGtags_add_line ?? array(), FALSE, array(  'stackFieldType' => 'Text', 'removeEmptyValues' => FALSE ), NULL, NULL, NULL, 'addGtags_add_line' ));

  
   
• Optionally display this field on the GA Form by hooking into \IPS\Helpers\Form::__construct()
  
   

  if(\IPS\Request::i()->app === 'core'
      && \IPS\Request::i()->module === 'applications'
      && \IPS\Request::i()->controller === 'enhancements'
      && \IPS\Request::i()->id === 'core_GoogleAnalytics' ){
      $this->add( new \IPS\Helpers\Form\Stack( 'addGtags_add_line', \IPS\Settings::i()->addGtags_add_line ?? array(), FALSE, array(  'stackFieldType' => 'Text', 'removeEmptyValues' => FALSE ), NULL, NULL, NULL, 'addGtags_add_line' ));
  }

• Create a Theme hook for core front: global -> globalTemplate
  • CSS Selector:  html
  • Action:  Insert content before the chosen elements(s);
    • We want to override the ga_code setting as early as possible in the template
  • Content:

    {{$stringFields = implode(' ', \IPS\Settings::i()->addGtags_add_line);}}
    
    {{ \IPS\Settings::i()->ga_code = preg_replace('/(.*\bgtag\W+\w+\W+\w+-\d+-\d+\W+;)/i', '\1' . $stringFields, \IPS\Settings::i()->ga_code); }}
    

    Select the UA-XXXXXXX-1 line, then add our fields after it
    
    
    How the line is selected
    
    This is where I couldn't quite 'bring it home', but I did confirm you can do a preg_replace on \IPS\Settings::i()->ga_code to accomplish selecting the line that contains UA-12345678-1, then replacing it with itself plus the contents of the Stack element we created strung after it:
    
    
    All we've done here so far is break out the lines into separately manageable items that can be glued after the 'config' gtag, but the goal is to take each line, modify it so that the template logic contained therein actually works, then insert the final value into the ga_code setting. (this does not save over the contents of the setting, only changes them when it is time to display it)
    
    My idea for making the template logic work was something along the lines of selecting anything in {} that looks like IPS logic via regex, declaring it somewhere so that it gives us its value, then saving whatever it produces to a variable, and reinserting that variable into the line.

If I can get back to playing with this later this week, I'll certainly give it a shot.  Otherwise, any more experienced eyes would be appreciated in case I'm over-engineering it or there is some simpler solution I'm overlooking.

Ultimately what we really need is for anything called in as {setting=variable} to also have any template tags parsed when it gets displayed on the template.  I dug around looking for a way to do this, but came up empty.

Ah, I didn't double check to see if the 4th parameter was even an option! lol

I'd been dealing with forms so much that it just seemed logical anything called upon via Form would have it.  Even addMessage has it!

Thanks for the tip!

This might not be a bug per se, but something that could be clarified via some comments in the code for addHeader maybe?

I'm working on an app which would allow an entire section to be toggled on or off.

Part of this involves hiding a section header (via a YesNo for example) by its assigned ID.

When I tried doing:

        $form = new \IPS\Helpers\Form;
        $form->add(new \IPS\Helpers\Form\YesNo('yesno_toggle', FALSE, FALSE, array('togglesOn' => array('my_header', 'text_field',)), NULL, NULL, NULL, 'yesno_toggle'));
        $form->addHeader('my_header',NULL,NULL,'my_header');
        $form->add( new \IPS\Helpers\Form\Text( 'text_field', NULL, FALSE, array( 'placeholder' => 'Enter some text here' ), NULL, NULL, NULL, 'text_field' ) );

It did not work, however when I changed 'my_header' to 'form_header_my_header' in the 'togglesOn' list, it worked.

        $form = new \IPS\Helpers\Form;
        $form->add(new \IPS\Helpers\Form\YesNo('yesno_toggle', FALSE, FALSE, array('togglesOn' => array('form_header_my_header', 'text_field',)), NULL, NULL, NULL, 'yesno_toggle'));
        $form->addHeader('my_header',NULL,NULL,'my_header');
        $form->add( new \IPS\Helpers\Form\Text( 'text_field', NULL, FALSE, array( 'placeholder' => 'Enter some text here' ), NULL, NULL, NULL, 'text_field' ) );

When toggling other form elements, just using the assigned ID works, so I feel like this should follow suit without the manually-added prefix.  Its also of concern that it wasn't clear this was necessary.

Maybe anything in a "togglesOn/togglesOff/toggles" array could be run through something that checks whether the id ties back to a form header or not, and applies the prefix automatically? 

I actually set out to report this as a bug with addHeader toggling simply not working, but in typing it up I realized what was actually going on and modified this post.  Its funny how many things can be solved on your own by trying to tell someone about it. 😅