Hi Vaughan, We are building a child theme which we will then deployed to more than one website. For each website we will just change the default copy and colours. That is what we are trying to achieve. When you probably dialled-in to the staging site, it gave you the impression that we're editing a one because we are not using Lorem Ipsums. I'm aware that we have to change some links. So not sure and I got confused with your comment. In reference to Dave's support ticket, following the steps he did not mention whether he is missing the CSS code or if the settings for each element in responsive edit mode get saved. We don't have issues with the latter (yet!) but from the tests we done they seem to stick for as long as we click save before we click onto the next view port. The CSS entered for each viewport are the ones that disappear following Dave's steps. I can see that the last response for that ticket was 13 Dec. You haven't mentioned a timeline for the the fix. But are you able to tell us where the custom CSS code in responsive mode is saved (folder and filename pattern), and are you able to send a sample we can work on? We are able to wait for the fix re @media issue because we are able to edit settings.php. The responsive mode CSS is what is very important to us. Thanks and looking forward to your response.

Hi Rupok, Did you mean that when you change padding in desktop viewport and then go to tablet/mobile viewport without closing that padding popup, then the element shows the same padding you set in desktop mode instead of showing what padding was set for that element in tablet mode? Yes. Did you try it on different types machines, different browsers and different servers as we did? This is likely an issue with JS not being able to refresh states. This matter is not much of an important to us because we are aware now. It will benefit other developers or users if you will be able to replicate the problem and resolve it. Unfortunately though we cannot provide you with a screen recording due to confidentiality. Also I hope you will also acknowledge the one I quoted below. This entails moving from one viewport to another without clicking the save button in the responsive mode. If solved, new users will save time from dealing with this. This is a UI issue that was really frustrating to find out that your changes did not save and secondly to spend extra time to figure out what caused it. On a slightly related one, it would be good if builder will warn the user to save the element settings for a particular viewport before a user clicks another. Or probably disable the other responsive icons until the user clicks Save (making the save button more obvious). The present UI invites a users who is gung-ho to click and click without realising his data hasn't changed at all. Cheers J `

Hi Rupok, We just granted support access to one of our staging site and left a rather long note. We did not pursue anymore the solution on local region's css disappearing. What we did instead was to make the regions global. Changing the permissions did not help and we were forced to reinstall another instance of our project. We think that the system is rejecting css code (with correct syntax). You will find this on the note we left on the dashboard's support page. I am not 100% sure if the new issue we just raised is related to the region's CSS issue. From what I remember the system does save the code in the elements-style directory, but the system is just not loading them when we get back to them via upfront's builder. If builder can save and read most files - why can't it do the same for region CSS that aren't set as global? There must be a certain condition that your system is checking similar to the new issue we raised. At any rate, we hope you could help us. Thanks.