[Resolved] Toolset Blocks / Archive Design Page behaving weird.

[Author]

Posts

[Alok Sharma]

I am designing an archive page (Toolset > WordPress Archives) and facing a lot of problems:

1. Any changes I make when designing the archive page for e.g. typography, colours, font size etc does not reflect either in the back-end or the front-end even after clearing the cache.

2. There is no typography option for the pagination.

3. I am trying to centre align the pagination block, but it's not happening. In the back-end, it shows in the centre but on the front-end, it shows to the left. And sometimes, no matter whatever I do, nothing happens. This issue is very much related to problem #1.

4. After clicking the Update button and navigating away from the page, a dialogue box warns me that the changes I made might not be saved.

I can provide the WP admin login details if required.

[Christian Cox]

Hello, problems 1, 3, and 4 all sound related. It could be that there is an error somewhere on the archive editor page that is preventing you from saving updates. I will be glad to take a closer look if you provide login credentials in the private reply fields here. Please let me know which archive is experiencing the problem.

[Christian Cox]

I'm able to see some updates, for example, the font color, when I adjust the post title heading block. See the screenshot here, I adjusted the text color to be green and changed the font family. However, the custom font is not displayed. I would like to try temporarily deactivating other plugins and activating a default theme to see if there is a conflict with another component. Can I try this test in the live site, or should I create a clone to perform additional tests in my local environment?

[Alok Sharma]

I can see the changes, but don't know why it doesn't happen here at my end. The live preview works as if it is being cached.

I am using Cloudflare WARP and this morning I disabled it to see it is not caching the contents.

Since the site is still in the development stage, you can go ahead and make any changes you wish.

[Christian Cox]

Ok it seems there is a minor issue in the Toolset Heading block when selecting a custom font in the Typography panel if the text displayed in the Heading block is not a link. Custom fonts are not being loaded successfully in this case unless you also select the same custom font in the Link Typography panel. So if you select the custom font in the Link Typography panel, that should solve the problem where the custom font is not loaded on the front-end of the site. However, that does not explain why you are unable to see changes in the live preview.

Can you try editing the archive in another browser, like Chrome or Firefox instead? Are you seeing the same problem in this case? If not, perhaps there is a browser extension causing some conflict. Can you try disabling your browser extensions, clear your browser cache, and try again? Which browser are you seeing the problem in? I can try testing the site in the same browser to see if the problem occurs for me as well.

[Alok Sharma]

Hello,

I am using the latest version of Microsoft Edge. Prior to that, I tried in Firefox. I also tried clearing the browser cache.

So far, what I have figured out is that the problem seem to be related specifically to WordPress Archive screen only. It is not happening with Pages.

I have also noted that whenever I create any custom fields, they do not immediately appear in when adding/editing any posts until I have cleared the object cache, for which the menu item can be found in the toolbar.

Besides, every time I clear this notification, "You are using the "GeneratePress Child" theme and you can show or hide the theme's elements in the "Theme options (GeneratePress Child)" section." it comes back again after I revisit the WordPress Archive page. This issue is very much related to problem #4.

I believe you might have noticed, the pagination block is showing in the centre, but on the front-end, it is showing to the left.

If you want, you can try to edit the Sample Page and you will see that everything is working smooth over there.

So I think all these problems are related to WordPress Archive screen only.

[Christian Cox]

I am using the latest version of Microsoft Edge. Prior to that, I tried in Firefox.
Okay I have created a screen recording of my experience in Firefox:
https://drive.google.com/file/d/18_1Y9BvjMdf4WdHa6HC-C-8Vv41yVug-/view?usp=sharing

I would like to see your experience in Firefox when logged in as the same Toolset user. Please open a new private window in Firefox, and log in as the Toolset User. In the Firefox menu, go to Tools > Browser Tools and turn on the Web Developer tools. Create a screen recording or a series of screenshots so I can see the problems you have described in the WordPress Archive editor where live preview is not working as expected. You can upload a screen recording video to Drive or Dropbox and provide a download link here for me.

So far, what I have figured out is that the problem seem to be related specifically to WordPress Archive screen only. It is not happening with Pages.
If you create a new WordPress Archive, this one for a different post type, like Posts or Pages instead of , do you see similar problems in both WordPress Archive, or is the problem only in the Product archive?

I believe you might have noticed, the pagination block is showing in the centre, but on the front-end, it is showing to the left.
Yes, it seems there was a CSS conflict between the GeneratePress theme and Toolset Blocksthat is breaking the display:flex style applied by Toolset blocks. GeneratePress adds this style in main.min.css:

.aligncenter {
    clear: both;
    display: block;
    margin: 0 auto;
}

Toolset Blocks pagination requires a display:flex instead of display:block, so a specificity override will do the job. I have added the following CSS code in the WordPress Archive's Custom CSS panel:

.wpv-pagination-nav-links.aligncenter
{
display:flex;
}

Now the pagination appears centered as expected.

2. There is no typography option for the pagination.
You are correct, this is a limitation of the pagination block. If you'd like to see this block's configurations updated to include more flexibility, like Typography configurations, feel free to submit a feature request to our developers here:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/

[Alok Sharma]

Before answering your points, I figured out that this problem is specifically related to Toolset only.

For, e.g., I added a View block in the Sample Page and I encountered problem #4. After saving the page and trying to navigate away, I started encountering problem #4, but as soon as I removed the View block, the problem also vanished away.

Do you feel it would be more feasible if you give you access to the sandbox installation, where you would be free to do whatever you like.? However, you are free to do whatever changes you want in the present installation also. Either way.

I would like to see your experience in Firefox when logged in as the same Toolset user. Please open a new private window in Firefox, and log in as the Toolset User. In the Firefox menu, go to Tools > Browser Tools and turn on the Web Developer tools. Create a screen recording or a series of screenshots so I can see the problems you have described in the WordPress Archive editor where live preview is not working as expected. You can upload a screen recording video to Drive or Dropbox and provide a download link here for me.
I will get this done by tomorrow.

If you create a new WordPress Archive, this one for a different post type, like Posts or Pages instead of , do you see similar problems in both WordPress Archive, or is the problem only in the Product archive?
Yes, I encountered this problem when creating a new archive.

Yes, it seems there was a CSS conflict between the GeneratePress theme and Toolset Blocksthat is breaking the display:flex style applied by Toolset blocks. GeneratePress adds this style in main.min.css:
Got it. Would there be a quick fix in the near future so that I don't have to add the request CSS code on each new site?

You are correct, this is a limitation of the pagination block. If you'd like to see this block's configurations updated to include more flexibility, like Typography configurations, feel free to submit a feature request to our developers here:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/
Actually, I wouldn't worry much about this. Just because of me or a few other users, the developers aren't going to be convinced that typography options are also needed for pagination. I am speaking from my personal experience, and hence I no longer take much interest in submitting feature requests unless otherwise deemed absolutely necessary. I would leave this part for the developers.

[Christian Cox]

Do you feel it would be more feasible if you give you access to the sandbox installation, where you would be free to do whatever you like.?
Sure, that would be helpful. I always prefer to work in a sandbox or staging site to prevent problems in the live site during testing. I have activated private reply fields here so you can share login credentials securely.

For, e.g., I added a View block in the Sample Page and I encountered problem #4. After saving the page and trying to navigate away, I started encountering problem #4, but as soon as I removed the View block, the problem also vanished away.
Okay thanks for this analysis. I will try reproducing this issue in the sandbox site, and if it is replicable, I can escalate to my 2nd tier support team for further investigation. Adding a View block should not cause the problem you have described.

I will get this done by tomorrow.
Standing by for your screen recording so I can see the additional problems you have experienced and noted here.

Would there be a quick fix in the near future so that I don't have to add the request CSS code on each new site?
Given our current workload and the fact that this is a theme-specific compatibility issue, I do not expect a quick fix. The CSS override is probably required for the near future on any site that uses the GeneratePress theme and centered pagination.

[Alok Sharma]

I had forgotten to import the Toolset data in the sandbox site. I have imported all the required data this morning.

[Christian Cox]

I have an update regarding issue #4. I was able to replicate this behavior in my own test site using a View block, so it does not seem to be specific to your site or the content in the View itself. I brought this to the attention of my team leader and he has discussed with our blocks developers. Because of the dynamic nature of the View block it is difficult to prevent WordPress from judging that changes have been made on the page. The confirmation dialog appears even though you have made no changes, and this is confusing. Our developers are now aware of the issue, and hopefully they may be able to do something to prevent such unnecessary confirmation/messages in a future release.

Were you able to create a screen recording so I can see the live update problem you mentioned in Firefox?

[Alok Sharma]

I am sorry for the late reply. I am in some unavoidable situation and unable to give more time to my main stream activity. This evening, I took sometime to check all the important emails and attend to them.

Thanks for the update on issue #4.

As for issue #1, I will try to record the screencast ASAP. However, I noticed that changing the font size (small, medium, large, etc) from the dropdown menu has no effect. And sometimes, when I specify the font size value, colour etc, the changes are not applied immediately. There is something very strange, and I believe it isn't happening with other users. I am using SpinupWP, and it does not cache any contents in admin login.

As I reported earlier (https://toolset.com/forums/topic/toolset-blocks-archive-design-page-behaving-weird/#post-2127501), whenever I create any custom fields, they are not immediately available in posts unless I clear the cache for which the option can be found in the WP toolbar. I think this problem could be related to issue #1.

[Alok Sharma]

I hope you have gone through the above reply.

I have recorded the video. Can you please enable the private message.

[Shane]

Hi Alok

Christian is currently on vacation on the moment so I will be doing the follow up here.

I've enabled the private fields for your next response to send the video.

Thanks,
Shane

[Shane]

Hi Alok,

I took a look based on your video and i'm not seeing the immediate issue.

When cycling through the font colors and typography settings i'm seeing that the items are indeed updating correctly.

What I did observer from the video is that you weren't waiting for the changes to be applied to the other items being displayed by the view before selecting another option.

The only issue i'm able to replicate is the one with the Font sizes not changing, however this is alleviated by the ability to specify the font size. Also if you specify a font size it will keep that font size even though you're cycling through the different header tags. If you reset the font size settings you will notice that the fonts of the headers change when you cycle through the header tags.

Thanks,
Shane