paul2009

You can hide buttons with CSS, like the example I have provided below. The exact CSS may depend on your site settings and whether you want to hide all buttons.
/* Hide all list item buttons */ .list-item-content__button.sqs-button-element--primary.sqs-block-button-element { display: none; } Did this help? Please give feedback by clicking an icon below  ⬇️

Take a look at the solution I published here: Make Squarespace list items clickable.
This takes the link that you've assigned to each CTA button and applies it to the entire list item. This means that users can click the image or any other aspect of an item to trigger the CTA action.
Did this help? Please give feedback by clicking an icon below  ⬇️

Yes. You can do this by adding CSS within style tags. Please take a look at my guide Customising the Squarespace order confirmation page.
Did this help? Please give feedback by clicking an icon below  ⬇️

No it is not possible. Permissions are not granular enough.

Many thanks, Paul2009. I have disabled the Ajax Loading, as the most suitable work-around for now; I do not suspect that OpenTable will re-write its code to function alongside Ajax Loading. With the AL disabled, the issue has now been resolved. Thank you for your assistance.

This is because Ajax Page Loading is enabled (a v7.0 Brine-family feature) but the code doesn't support this. Please see my guide Why does Squarespace code only work on refresh?
Did this help? Please give feedback by clicking an icon below  ⬇️

The change from "*" to "(required)" is part of the Form Block update, currently being rolled out to all sites.
Have you checked the Language & Region settings on your sites (in Settings > Language & Region > Region) to check they are correctly configured for French?

If you're looking for a CSS solution to restore the asterisk on form titles, please try this:
/* Hide required on field titles Tip by sf.digital */ .form-wrapper .react-form-contents .field-list .title .required, .form-wrapper .react-form-contents .field-list .fields .description.required { visibility: hidden; } .form-wrapper .react-form-contents .field-list .title .required:before, .form-wrapper .react-form-contents .field-list .fields .description.required:before { visibility: visible; content: "*"; font-size: 1.5em; line-height: 1em; } .form-wrapper .react-form-contents--submitted .required:before { visibility: hidden!important; } Let me know how you get on.
Did this help? Please give feedback by clicking an icon below  ⬇️

Your CSS will work if you place it in Design > Custom CSS (without the style tags). This is supported on all website billing plans, including the Personal Plan. However, you cannot "inject" code in the Personal Plan, so you won't be able to add CSS to individual pages using page injection or using the header/footer injection options.
Did this help? Please give feedback by clicking an icon below  ⬇️

Never mind! I figured it out.
I had to change the href to the URL I was pointing to.
ie. change "https://www.amazon.com/dp" to my URL
Thanks Paul, you're a legend!

@paul2009 Thanks - that's perfect - just what I need !!
 
Cheers, Ed

cheers @paul2009!

@BabbR @conrad1956 I see this issue on your site and I believe it is due to a Squarespace bug that affects some sidewide animations. Try disabling them to see if this resolves the issue. 
Did this help? Please give feedback by clicking an icon below  ⬇️

It's by Will Myers.
Did this help? Please give feedback by clicking an icon below  ⬇️

Which workaround are you using? You'll find my workaround here:
 

Thank you Paul! This fixed the issue!

This is the item added popover that appears when items are added to the cart from the Product List Page. It uses the siteBackgroundColor for the text, which is currently set to transparent. If set to white, it would look like this:
As a first step, try changing your colors in Site Styles.

Integrating another platform will require code, so it's best to go to the Coding and Customization section and ask a question there. As a shortcut, you can click this - Ask a Question. When you post your question, please ensure you provide:
a working link to the site. If your site isn't live yet, please set a public password and tell us what it is too. details of the other platform, including full details of the code they asked you to add and links to any technical documentation that they provided.   We like to know if our posts help. If it has, please click a 'Like' or 'Thanks' icon below  ⬇️

I agree about the privileges model. I've been advocating for improved permissions for years (and requested this as a feature). It was probably fine for most sites where there's a single user, but as Squarespace are now targeting professionals and agencies, I would like to see some improvements.
Regarding a specific contributor role of "Developer" (as opposed to Designer), I see this as providing the same as access as Administrator but without access to areas that contain financial or personal information that do no need to be disclosed to a developer who is coding the site. For example, preventing access to Orders, Analytics and Contacts/Profiles. 

As a developer I have found for most of my clients I need full access to everything as most of my clients are not Squarespace experts and need help with many of the features across their sites.
I need to be able to see what they are seeing because I can't be sure they are explaining accurately what is going on when they have issues because they don't have the experience.
As far as security, in my observation, SS is not showing sensitive information directly in the editor, like full credits card numbers.
So my question would be what specifically would be excluded in this Developer Privileges level?
I think that the real issue here is that the privileges model SS uses just isn't adequate to the task. I'm thinking that SS needs something more like a UN*X permissions model. Obviously the concept would need to be adapted because we aren't dealing with file systems but access to records in databases.
SS could set up some default groups and users that allow much the same behaviour we get now. But advanced users could set up their own to meet their needs.
I doubt this will ever happen. Such a system would be much more flexible and once set up, SS could step back and let their users decide what access is needed for contributors.

TL;DR
Product URLs always include a /p/ before the customisable URL slug on Squarespace 7.1. You cannot remove or change it.
 The "p" appearing in the browser's address bar shouldn't have any negative effects for customers or merchants. However, if you are coming to Squarespace from another platform and have previously used URLs with a different format, you can use URL mappings to redirect users from your old URL to the new one with the 'p'. For example, if both your old and new sites used 'store' as the store URL slug, and the same names for the products, you could use the following mapping to automatically redirect all old product pages to the new format:
/store/[name] -> /store/p/[name] 301 Longer Explanation
When Squarespace overhauled Squarespace 7.1 Store pages in 2020 with the launch of "Product Collections 2.0" they introduced a number of new features that laid the foundation for modern e-commerce experiences on Squarespace stores.
They increased the product limit from 200 products to 10,000 products on a single Store page and, to improve the experience for customers and merchants, they added support for up to 1000 categories and provided new SEO-optimized category URLs that didn't require URL queries. For example, a stationery store selling blue notebooks may have a category URL slug of /store/notebooks/blue instead of /store?category=blue.
To accommodate the improved SEO for online stores, they needed a way to distinguish individual product pages (known as Product Detail Pages or PDPs) so they added the '/p/' in the URL slug of PDPs. For example, if you had a product called "Notebooks" and a category called "Notebooks" then
the category URL slug would be /store/notebooks the product detail page URL slug would be /store/p/notebooks  
Note that this forum is not routinely monitored for product feature requests but if you want to raise a feature request with Squarespace, you can open a ticket through Customer Care. They'll document your feedback and share it with the appropriate team.

As I stated above, product URLs always include a /p/ before the customisable URL slug on Squarespace 7.1. You cannot remove or change it.

Sadly there aren't any Buy Now, Pay Later options currently available for Squarespace Commerce (through Stripe) in France at the moment.
However, I would expect the situation to improve in the next couple of years as Squarespace Payments becomes more widely available 🙂.
Did this help? Please give feedback by clicking an icon below  ⬇️

I wouldn't generally recommending changing URLs unless there is a good reason for doing so. However, if they do need to change, for example, products will inherit "/p/" as part of the URL on v7.1, then you can create redirects in the URL mappings panel.
Did this help? Please give feedback by clicking an icon below  ⬇️

Thank you! That's rotten to hear — it makes Squarespace's option of "Digital Products" much less helpful for those of us doing online education. But I very much appreciate you being clear about this.

You cannot capture custom information as part of the purchase workflow for a "Digital Product".
A workaround may be to use a "Customer Activity Automation" in Email Campaigns to send an email after someone purchases a Digital Product, asking the customer to complete a form. However, this will require an Email Campaigns subscription.
For anyone reading this, I should point out that Custom Product Forms are available for Subscription Products, but they must be Service or Physical products. They are also available for Download products.
Did this help? Please give feedback by clicking an icon below  ⬇️