jploch

Thanks for sharing the video and the PM. I will have a look and get back to you soon. I am aware that sometimes the grid overlay is not updating immediately. I might fix this in the next update, but this is not related to your issue.

I don't see any problems with your code. Can you try to replicate the issue on a fresh install using only the premade blocks? If you can't replicate it, you can add one block at a time and see if/when it happens? Can you install and enable Tracy Debugger and check if you get any errors there? I can also take a look at your setup if you don't mind. E.g. You can send me a PM with a link to an installable site profile or create a user for me so I can login and try to replicate the issue on your install.

I don't think so but can you post the code you have in your custom block template.

When you edit a page with PAGEGRID, it's loading your frontend inside an iframe, thats why I am asking about your JS code. The JS notice you posted is not related. I also see that notice and it has no affect (it's not an error and happens sometmes when opening the style panel and some inputs don't accept the default placeholders).

Sorry again for the inconvenience, and thank you for your patience! If this is the case, it's not the browser then. Are you loading any custom javascript code, if so can you remove it and see if it changes something? Can you check if there are any javascript errors in the console? There is clearly something wrong here, because I build a lot of PAGEGRID websites with a lot more items then 20 and did not experience these performance issues. I think thats a good idea. You can also test with the premade blocks to make sure it's not your code that is causing it. I will also test a bit on my end, but so far I could not replicate the issue.

You have two options if you don't want your client to resize items: Don't give the permision "pagegrid-resize" and "pagegrid-style-panel" to your use role Force the item size with CSS like this: /* overwriting the default size of grid items */ .pg .pg-item { grid-column-end: span 3; }

Lets try to fix this. Which browser (Chrome version) does your client use? How is the performance when your client is not using screen sharing? Can you login with the user of your client and try to replicate the issue on your computer? About performance. Screen sharing is not a very reliable way to measure performance. A low FPS rate could be due to the network. Also keep in mind that screen sharing usually affects the performance of the client. So if your client is running on an older machine, this could also be an explanation for the low FPS.

Ok then it makes sense to use the default. It could also be a user error from your client side. Since I can't reproduce it, I am not considering this to be a bug in PAGEGRID for now. If you can provide a way to reproduce the error I will try to fix it. PAGEGRID has cache busting enabled by default, so you just need to call the function. I was talking about adding cache busting to your own custom CSS files. But since you loaded the styles inside the PAGEGRID settings it should just work. This also makes sure the order is correct und your custom code will be loaded after PAGEGRID's default styles automatically. I don't think the probelm is related to caching anyway. Then it should just work. The order is correct if you do it like this. You don't have to use important. Is there any other CSS code that could affect the blocks? No need to use important. PAGEGRID styles have low specificity. You can use 1 level classes. Just for overwriting the grid-row-start of the items you have to use two classes (like you did): .pg .pg-item{}

I don't think it's an issue with the cache, so the hard refresh should not be needed (I never had any cache issues for the sites I created with PAGEGRID). How are you loading your custom css? Make sure you load your custom CSS after you load the styles from pagegrid (e.g. after: $pagegrid->styles($page);) Also make sure you use the right class when setting the items to auto row, this will do it for all exiting/new items: .pg .pg-item { grid-row-start: auto; } If you are not using the grid and only want your client to sort vertically it might make sense to set the main wrapper to display block: .pg-main { display: block; } See this for more information.

Sorry for the trouble. This has not happened to any of my PG sites, so it would be good to find out what is going on. First I recomend to install the ProcessDatabaseBackups module and the CronjobDatabaseBackup module. These can be setup to trigger a backup when a user logges into the backend, so you always have a backup you can restore if your client changed something. Also consider giving you client only the permissions needed to maintain the site (eg. using the default pagegrid-editor role). With the information provided it's a bit hard to guess, so let's break down the potential causes and how we can address them. Possible Causes: Cache: ProcessWire's Cache should not be enabled when you are logged in, so I don't think thats the issue. Are you using any external caching features like template cache or ProCache? If so try to disable them temporarely and see if it changes things (also delete the site/cache folder). Another thing could be that the browser cache is holding onto an older version of your site's CSS file. You can load the css file with a cache busting parameter like appending a version (e.g. mycssfile.css?v=2) and see if that changes things. Perform a hard refresh of the browser (usually Ctrl + Shift + R or Cmd + Shift + R). CSS Specificity or Conflicts: Double-check the code for your 'vertical spacer' custom block. Ensure it doesn't contain any CSS or JavaScript that might inadvertently affect the positioning or order of other elements on the page. What is the CSS display value of the main wrapper (e.g. display: grid; display: block;)? If you are using vertical ordering it might make sense to use "block" instead of "grid" (.pg-main {display: block;}). User error: What kind of permissions does the client have (eg. can the client use the item list to reorder)? Could it be that the client reordered the blocks by accident? What was the last thing the client did before it happened? Two users working on the same page: If two users work on the same page it could cause some unexpected behavior, e.g. if both are reordering. Make sure that there is only one person working on the design of a page. Consider Creating a Minimal Test Case: If you can consistently reproduce the issue on a simpler page with just a few rich text blocks and vertical spacers, please provide me with the steps to reproduce it. This will greatly help me in identifying the root cause. Also can you please share the markup and CSS code for the vertical-spacer block and any CSS/JS that is loaded on that page.

You can put it in the CSS code field on the module settings like you did or load it inside a CSS file, both is fine. See this example and comments for clarification: /* this overwrites the default for all items */ .pg .pg-item { grid-row-start: auto; } /* this is only affecting new items, e.g. size can still be changed later by resizing items, if you want to set a default size it's better to use this class */ .pg .pg-item-added { grid-column-end: span 3; /* let new grid items span 3 columns */ grid-row-start: auto; /* you can also change the placement here */ }

You can force this globally by adding custom CSS. See the docs here.

Upgrades don't mess with data. The data model has not changed for two years and there have been no breaking changes since then. If this would change in the future it would be a major version change like 3.0. that indicates this. Still good to make a database backup just in case. The easiest way to update is going to the PAGEGRID module settings (Setup > PAGEGRID), open the module info und click on "Check for updates". Same can be done with the PageGridBlocks module. But you can also replace the files like you sad.

@joe_g I just pushed an update that should make the scrolling perform much better. Can you try the latest version and report back if it fixes the issue for you.

@elabx just to make sure. You are not talking about a PAGEGRID site here right?