Daniel K.

Hi @kittmedia,

Thank you for taking the time to write this – you are absolutely right, and we fully agree with your point.

HTML classes are effectively a public API, and changing or removing them is a breaking change. From a SemVer perspective, this should not happen as part of a regular feature update, and your frustration in this situation is completely understandable – especially when the widget is used across hundreds of websites.

In our case, the 6.9.4 update was influenced by some long-standing technical constraints in the plugin that date back to around 2016. Unfortunately, those legacy decisions made it impossible to fully preserve the original markup and class structure in its entirety while moving forward with the new design structure.

That said, we were very careful not to remove everything:

1. The core and main classes were kept intact.
2. Flex containers were added on top of existing structures, not replaced wholesale.
3. Only a small number of very old classes were removed — specifically:
   • the global hard reset class wpac, and
   • a few legacy layout helpers (wp-google-left / wp-google-right) that predated proper flexbox support and were effectively emulating it.

We also want to highlight that the visual changes you noticed are very likely related to the removal of the global hard CSS reset (wpac). This reset forced the widget to look identical on all sites, but over time it became a major source of conflicts and layout issues, which ultimately made its removal necessary.

None of this is meant as an excuse – you are still absolutely correct. We take full responsibility for the impact this had, and we completely agree that this kind of change should be handled with extreme caution.

Going forward, we will make a strong effort to avoid removing or changing public classes and to treat the markup much more strictly as a stable API, precisely to prevent situations like this in future releases.

Thank you again for the clear and constructive feedback – it’s genuinely appreciated!

Hi Robert,
We’re glad to hear that this is resolved now.

Just to clarify why the plugin currently uses both the legacy and the new Google Places API.

The reason is that only the legacy Places API supports a special sorting parameter that allows reviews to be fetched by newest. This makes it possible to display the latest reviews for a location, which is extremely important for users, because it creates a clear sense that reviews are actively updating.

The new Places API does not provide this option and returns only Google-selected most relevant reviews, with no way to request the newest ones.

Because of this limitation on Google’s side, the plugin still relies on the legacy Places API specifically for review sorting, while using the new API where possible.

Please let me know if you have any questions.

Thanks for your feedback and for bringing this up.

Hi @roberthemsing,

Thank you for your topic!

Please check that the option ‘Use old Places API‘ is disabled on the page Google Reviews / Settings / Google (in wp-admin) if you wish to use a new Places API.

Let us know how it goes.

Thanks!

Hi @ny85,

Thank you for your topic!

Did you try HIDE REVIEW button next to each review in wp-admin (in the widget builder)? The Overview page also has these buttons but removes review from all widgets.

Thanks!

Hi @newbie2004,

Thank you for your topic!

Please send to investigate:

1. Direct link to your website page where we can see and reproduce the issue;

2. Debug information from the page in wp-admin: Google Reviews / Settings / Advance tab. You need to click the ‘Copy Debug Information‘ button, paste copied to this reply and send it to us.

For the debug information please use ‘Pastebin‘ service.

Thanks!

Hi @uriahs-victor,

Thank you for the topic!

At the moment our plugin registers the main menu, Overview, and the Widgets page with the edit_posts capability. This means that any custom role that has edit_posts (for example, Editor-like roles) will be able to see and open the Builder area.

In contrast, Settings and Support are already restricted to manage_options, so only administrators (or roles explicitly granted manage_options) can access those.

Before we change this, could you please confirm which behavior you want?

1. Admin-only access (recommended): show the plugin menu and allow access to Overview + Widgets only for users with manage_options.
2. Allow specific custom roles: keep admin access, but additionally allow one or more selected custom roles to open the Widgets area.

If you confirm option #1, the change is straightforward. For example, we would update the capabilities in our menu registration from edit_posts to manage_options.

Please note that option #2 would require additional research to determine whether it can be implemented within the current plugin architecture and without causing permission or compatibility issues with custom role setups.

Please let us know.

Thanks!

Hi @wppraesenz,

Thank you for your answer.

Yes, you’re right – it’s hard to find this option, and we’re planning to move it to the common options in the next release.

Thanks!

Hi,

Please reopen if it’s still relevant.

Thanks!