socceronly

Whatever you choose would be applied to all existing purchasers.

I just can't see continuing to use this.

It is 14 mouse clicks 3 pages and 1 tab I have to close for each shipment. 

Doing this ten thousand times, or more is simply not tenable. 

I have tagged our developers who are better placed to be able to answer the question for you there. Someone will be in contact as soon as possible

Never before the first coffee 😄 

As mentioned on the message there, you would just visit  /admin/upgrade and complete the upgrade in that scenario. Its likely the query timed out there, but I have completed that off for you in any case
 

Thank you so much.

We had thousands of people trying to buy tickets in the space of a few minutes and I was trying to keep it down to members and screwed up.

Thank you so much!
Greatly appreciated.
Jamie

Thank you so much.

We had thousands of people trying to buy tickets in the space of a few minutes and I was trying to keep it down to members and screwed up.

Thank you so much!
Greatly appreciated.
Jamie

Because it's in the Moderator CP on the front-end.

Great...I would hate to shut down the store when all those people are there. 

Thanks, tomorrow is going to be interesting.... 🙂
JM

Great...I would hate to shut down the store when all those people are there. 

Thanks, tomorrow is going to be interesting.... 🙂
JM

There isnt anything to prepare for there. Our cloud infrastructure is already set up to cope with large volumes. 

This would save an immense amount of time if you ship a lot of things. 
I currently have about 2000 things to ship, and it is going to be more.    It may not look like that in my list but we had to switch the membership to a digital product because we had so many shipping errors. 
Right now I have to print twice, staple those together, pack, pull it apart cut out the label and attach it to the package.
If the invoice could have a better formatted address on it all the info would be in one place.  It could be folded and use as a packing slip.
All that would be required is to copy the Print Label formatting into the address part of the Invoice.
Anyone else have any better ideas?
JM
 
 

When adding the CNAME files, do you add them and leave the existing ones, or add them and replace/delete the old ones...
It's not clear in their docs, or anywhere I searched.
Thanks
JM
 

Wow, what a spectacularly good memory!
Yes, I tweak content to so that English text is shown in Pages if English is selected but Esperanto when the user changes language.
There are a couple of different techniques. The one I've used most often is to add some code within the article itself:
<h1 class="longer-text"><span>{{if member.language()->id === 1 }}We’re a charity which has the aim of providing education to people in and about Esperanto.{{else}}Ni estas bonfara asocio, kiu celas eduki homojn en Britio, kiuj volas lerni Esperanton.{{endif}}</span></h1> English is the language with the id 1, so if the member is using English, then the text in the if-clause shows; otherwise, they see the else-clause.
Another approach is to use blocks, giving them names with a language marker differentiating them, so block_en and block_eo. That would come in handy for longer pieces of code because you're not forever writing out if-conditions. I can't remember where I've used this but looking through some old blocks, it seems that I have a particular block which creates a variable with the value "en" or "eo" depending on what the current language is:
{{\IPS\Settings::i()->lingvo = substr(\IPS\Member::loggedIn()->language()->short, 0, 2);}} (The variable gets its value from the first two letters of my language packs: en_GB and eo_XX.)
I presume I must've used that block on a page and then at relevant points added a line within an article to call the relevant block:
{block="block_{$lingvo}"} or something like that.
My site is such a mess, though, that I can't track down anywhere using that approach. It might be that it didn't work, I suppose. My first approach definitely does work, and a similar one to this second one does with Pages databases too:
<p>{{if substr(\IPS\Member::loggedIn()->language()->short, 0, 2)=="eo"}}{$record->customFieldDisplayByKey('people_bio_eo', 'display')|raw}{{else}}{$record->_content|raw}{{endif}}</p>  This was all very experimental a few years ago, though. Now I just stick to the first approach, even though it means dozens of if-clauses. It's a headache at the time but if you're not going to change the content, then it's survivable.

The whole IPS system isn’t built for translatable content at this time. 
In theory, you could create custom editor fields to hold the other languages and then change all the Pages database templates to call the right field based on user’s language settings. It’s doable. I’ve done it for client once, but it’s really not a clean solution. You would also have to think about indexing through search engines and things like that. 
If I remember correctly @Meddysong uses this as well and has explored the ways to deal with this. So he might know more. 

We have some ideas on making blocks and pages more flexible, though they are in their early stages. As things stand right now, custom templates are your best approach, but I certainly hope we can provide something more intuitive and robust in future.

I don't think I am simply saying "Just do better".  I am saying this output is unlike any CMS out there for displaying a list records in a block.  
Imagine something simpler.   A website that has a single database with articles in it.   Unless that front page is set to the article page with the DB embedded in it set to Article view....  well what are your options? 
If on your front landing page you want your recent articles in a column, gallery images in another say, twitter feed ect....   any combination of perfectly normal things.... that article block will not remotely look like any website on the Internet doing something similar.  It's just not how articles on any system I can think of are displayed in a block.   Thumbnail, Title or Teaser.   Or if images are not required in the record, just the title and or teaser would be better, cleaner and simpler. 
 
 
 

I mean all of my templates survive upgrades but I choose to do most of it in CSS because the data will never change so the most "updated" things you normally need to do is through CSS but only if you've completely customized it.
The above are using other IPS blocks that I just made minor customizations of DATA for myself.

I'm not saying paid. I customize all of my own block templates to work the way I want. So for example:


 

Last I checked this was the default Articles/Pages block:

 
 

So not sure which block you showed them but its completely doable but not out of the box. It would just be a custom block template. Super easy to do but not something that is just available.

The work around right now is through the permissions. I'm still troubleshooting the tab issue though.
Could you take a screenshot of the exact area and I'll see if there is a hook point you can switch to there.
Gallery/3rd party app support is being worked on now. Pages is a little more complicated but it might be included in the next update as well.

I'll give it a shot and try things out. 
Just weary of installing interdependent things, but Member Shop sure looks cool and if they work together it would be great.
I'll buy it tomorrow.
Cheers. 

Great.  I bought one for now, I don't need the commerce stuff on this site, and no rush on the one that does. 

Looking forward to it.
JM

Yes.
I have a version that will work with packages, so you can set in the packages the settings for the submissions: pin and/or feature. It's under tests. I have only one user using it and I didn't receive enough feedback yet so I rather wait a little bit before release it. 🙂