jploch

While truly "mono-color" in the strictest sense (only one hue, with only black, white, and gray variations) can be rare for an entire complex web app, many apps employ a highly restricted, minimalist color palette that leans heavily into a single primary color, often with neutrals (like what we do with the new theme). In our theme we have one primary color, but also other colors for alerts/warnings, for code, notes, etc. We also establish hierarchy and contrast through color shades (from light to dark), inverting color (dark on light becomes light on dark), form (E.g. round vs. not round), icons, typography (different sizes, bold/regular), spacing (to group items) etc. Using too many different colors can also have the opposite effect and cause a sensory overload (E.g. in a super market, where everything screams for attention, some of the more subtle designs can stand out more then another red box among the others). There are many successful examples of good working mono color UI’s (not in the strict sense, but mostly neutrals + primary color), from very complex systems like operating systems (eg. MacOs/iOs, Windows, Android), most desktop apps and a lot of popular web apps (E.g. Youtube, Google Docs, Gmail, Netflix, etc). Thats a good and very important point. We where also discussing with Ryan how the CMS landscape changed and where we see PW fit in. It seems there is still a market for a CMS like PW. Take Kirby for example (they clearly took some inspiration from the PW API and they have a similar audience), it's thriving (at least here in Germany). I think that also shows how important marketing is, and that they are doing a good job with it.

Thanks for pointing that out! I think we should also apply the new theme to the frontend editing UI. Will put it on the list..

Since design is subjective you might not agree that the new theme is actually an improvement over the old one. So let me add some reasons for our design decisions (sorry this will be a longer post): The original theme had too much branding: The original theme added a lot of PW specific branding to the backend. The 3 main colors of the original theme add a lot of character and it wasn’t very subtle with it. Since the CMS is used to create websites/apps for clients wich have their own branding, there was a clash. I think this is also one of the reason why people went to such an extend to customize the look of the backend. Of cause you can argue that the look of the original theme was more unique, and I would agree with that. But as described above it’s not the primary functionality for the CMS to promote the PW brand (E.g. Exel is also not promoting Microsoft but rather keeps it look tied to the operation system). I also don’t think the backend needs to promote the client brand either (It won't be used by potential customers, so why push the client marketing here?). Rather it should be a neutral frame that works for any client/project out of the box without the need to customize it a lot (we still want to support customization as much as possible, as everyone uses PW differently, but the defaults should work out of the box). More in line with the new website/brand relaunch: Once we designed the new homepage, we felt that the original theme doesn’t fit with the promises and brand values we communicate on the new website. (E.g. PW stands out of the way, doesn’t force a look on your frontend/backend, simplicity for editors, modern UI, etc.) Improving contrast and accessibility: The original theme had some problems with accessibility. And while we are not solving all of it in the new theme (it would have been to much work for us), we at least improve some of it: Improved color contrasts: Higher contrast between font and background color (better in line WCAG guidelines) Improved text readability: The old theme used a font stack that relies on system fonts. E.g. users on windows saw a different font (Arial for the most part) than users on mac (Apple System Font). Depending on what fonts you installed you might also saw others. The new theme uses the Inter font for all users. Inter was designed specifically for screens and user interfaces. It has high contrast letter forms and a tall x-height to aid in readability of mixed-case and lower-case text. this might seem like a subtle change, but it actually makes a difference especially for smaller text and text in bold. (This is less about if you like the font and more a decision based on functionality). Improved keyboard accessibility: The new theme improves how the tab key can be used to navigate the backend. You can compare the original theme to ours to see this for yourself (eg. you can now navigate the tree with your keyboard). It’s still far from perfect and I think we can make an effort to improve in this area (there would need to be some changes in the markup, especially how the tab-navigation works). We also added a shortcut to open the search, which gives access to a lot of PW’s features, and we think it would be nice to transform the search into a command palette to access other shortcut actions for the CMS like creating fields/templates/pages in the future (think of it like Macs spotlight or Raycast). A more modern look and feel: I know this one is very subjective. We looked at other CMS options out there that seem to be somewhat similar to PW (e.g. Kirby, Craft, Statamic, Sulu, Datocms and others). And we could see a certain UI trend in their backends: They all use a mono color theme with subtle colors + a main color (a trend you find in a lot of UI’s now a days). To me that makes a lot of sense: It is easier to direct a user through an interface and apply hierarchy when not too many elements scream for attention. To me the way the colors where used on the original theme lacked a clear functional direction and instead where more of a decorative distraction for editors. This also seem to align with feedback we got from our clients (at Konkat we used the AdminThemeCanvas for most project since most clients seem to prefer it over the original theme). Fixed and more integrated nav-bar: I think most people here agreed that the fixed nav-bar is an improvement. Some said they prefer that the navigation is more separated from the rest of the design. We thought because the nav is now fixed it actually is already functionally separated from the rest of the UI (once you scrol), so there is less need for separation. Also users are expecting a navigation to be at the top of the page. If we put the nav in an unusual place (which would not be a good idea anyway), then it would make sense to make it more visible, but like it is now we don’t see the need for it. It would also break the concept of the mono color theme. Support for Dark mode: I already said it, I really don’t care much about a dark mode, but other people do and I think it’s a good feature to attract new users. One benefit of the mono color theme is that it’s easier to support a dark mode. But if dark mode creates too many problems for module developers I would consider removing that feature, but that needs to be discussed with Ryan and Diogo. @bernhard I will also discuss your other technical concerns regarding the CSS overwrites, as I think you made some good points. I will check with Diogo and Ryan and get back to you, I am confident that we can find a solution. If we (Konkat) had more time we would have liked to completely redesign the PW backend from the ground up (E.g. we had early concept with a sidebar instead of the top nav-bar, fixed save buttons and other things). But that would also have been a massive change for everyone, so we were going for a more subtle enhancement with the new theme instead. I hope this helps to get some insight on our decisions for the design of the new theme. We hope to improve it further over time so please keep up the feedback and bug reports.

@Mikel I agree with you. The website and the theme/CMS backend have indeed very different functions. To use an analogy: It’s like an advertisement for a car versus the actual dashboard inside the car. Both are designed for very different purposes. Here is how I would describe the differences in our specific case: The website is mainly a marketing and documentation tool. It’s the face of the brand online. It's what our audience sees, interacts with, and ultimately uses to form an opinion about the business/product (in this case the CMS is the product). The design should reflect the values of the brand and is primarily about attracting, informing, and persuading potential users. The design of the theme/CMS backend (the product) is mostly about usability, functionality, and creating a delightful and efficient experience inside the product. The product also needs to be convincing and coherent with the brand values und promises made on the website. While their primary functions differ, the marketing-focused design and the app interface design are not isolated: Marketing sets expectations for the app's interface: If your marketing promises a "sleek and intuitive" app, the app's actual interface must deliver on that promise. Discrepancy leads to disappointment and uninstalls. A great app interface becomes a marketing tool: If people enjoy working with PW it might lead to positive reviews, word-of-mouth recommendations, and higher retention – all good for marketing. Brand consistency is key across both: This doesn’t mean they need to look the same. But they should both reflect the brand values.

@ryangorley Thats a really nice website! I also like the 3D assets. I am not sure if/how 3D will fit with our current design approach. But I will keep it in mind and discuss with the others.

Hey folks, sorry for not responding earlier; I was swamped with work and then got sick afterward. Thanks for all the feedback so far! And thanks again, @ryan, for asking and trusting us to help with the redesign. The discussion seems a bit heated, but that only shows how passionate the community is about PW. I will leave it to @diogo (he is on vacation for a week) and @ryan to answer some of the technical concerns, as they are the ones doing the implementation. Just know that we are reading and discussing them and take them seriously. I want to add a bit of context to our general design approach and goals with the redesign of the theme and PW website. You might not agree with everything I am saying here, and that's fine. I don't claim to be right in all of it; this is just our current approach. We started out by asking questions to Ryan, reading the forum, and identifying problems with PW's current marketing and brand strategy. As well as doing research and comparing other CMS offerings to PW. here is what we found out: PW user numbers seem to be stagnating (not a lot of new users on the forum). PW's marketing mostly seems to speak to developers (= making clients, agencies, content creators, marketers, editors, and designers look for other options). Lately, more and more of our own clients had been choosing other CMS options over PW because they said it looks too "technical" or "dated" (they looked at the PW website). The design of the PW homepage is too "crowded" to identify the most compelling features of PW (= clients couldn't understand at a glance how PW can solve their problems). The PW website lacks recognition (basic UIKIT look) and doesn't look very approachable/friendly for newcomers. The way the admin backend is shown on the website is not very attractive, and the theme itself looks dated compared to other CMS solutions. The look of the website doesn't reflect most of PW's brand values (Flexible, Powerful, Simple, Easy, Friendly, Open, Secure, Stable, Free). And here are some of our goals with the new website and theme design: Attract new users to PW (developers are still the main target audience, but we want to target a more diverse group of users, see above). Make PW more approachable for new users. Keep existing users happy. Make the PW brand more recognizable. Better highlight PW's strengths and key features. Communicate PW's brand values through the design. Improve the docs. Make it easier to find modules. We realized that it would not be enough to just redesign the website, as the admin theme is the "main product." If people check out the new website and we can make them interested in PW, the second thing they do is install the CMS. So it's important to have good-looking defaults for the new theme that are coherent with the new website, as new users won't do a lot of customization. The reason we decided to include a dark mode in the admin theme is also mainly to appeal to new users. I personally don't care much about a dark mode, but for some it's a selling point. This trend can also be seen in other CMSs that now support it. I hope once the website is launched, it will be a bit more clear where we are going with this. Also be aware that we are not getting paid to do this, we did it because Ryan asked us and we love PW. But our time is limited and we have to make the most out of it. We will probably not achive all of these goals immediately, but we hope to set a good direction for things to come.

@joe_g Glad to hear it! I would like to feature the website on the showcase. If you are ok with it send me the URL as DM or post it here and I will add the site. THX!

This issue is solved with the latest update (>= 2.2.70).

The group block has a link option now, which wraps it's content inside an <a> element. (Marked as Solved)

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?

Hi @joe_g you can send me PM with your link and I will have a look. Please make sure that you are running the latest version, because I made some performance improvements a while ago. I have sites that have more than 150 items and they run fine. But it's true that the performance can take a hit (in the backend) when you have lot's of items on a page. It also depends on the kind of items, e.g. having lots of autoplaying videos or sliders is not good for performance. I also found out that the chrome browser has the best performance and of cause it depends on the computer you are using. Good performance is very important to me and I will continue to improve PAGEGRID as much as possible, so it's always helpful to see how it works in different contexts..