Search Results for 'mobile'

Thank you Sir for Supporting me Now i meed To Make Size Inline icon with portiat style and mobile style news thicker trending icon also news mobile needs to look like desktop resise headline like desktop look these images both portiat and mobile style from tagdiv and https://www.maslaxcabletv.com/wp-content/uploads/2026/01/Screenshot_20260131_021658_Chrome.jpg
https://www.maslaxcabletv.com/wp-content/uploads/2026/01/Screenshot_20260131_021717_Chrome.jpg

• This reply was modified 6 months by degelcreatives.

No it is not working I just checked on multiple mobile phones and its working only on main page when you pushing post and then try to push main menu its not opening 🙁

How do I create a mobile design that’s independent of the desktop browser design without using the default mobile theme?
Next, in the WordPress settings – reading – static pages – homepage, I set it to “home.” For the post page, should I leave it blank or use a mobile template?
Or, what should I use as the homepage in WordPress: the original page or the mobile template?

How to create a Mobile Design that is Independent from the Desktop Browser Design, without using the default mobile theme.

From: Simion
Sorry for the delay.

From what I see, what happens is normal. The news ticker is in the desktop header, so it won’t be displayed on mobile. Then the titles of those 2 blocks aren’t the actual titles of the blocks, they are standalone title elements, both in their own inner row, so on mobile they are displayed one below the other. It’s just how the page was built.

It is however strange that the page looks different while logged in. Unless you are maybe using a mobile page. Then the explanation would be that while logged in you see the mobile page, which has the correct design, and while logged out we see the desktop page, which has problems. Normally if there is a mobile page set, it should be displayed for logged out users as well. But dedicated mobile content such as a mobile page is sensitive to the caching used on the website. It depends on what caching plugin is used on the website, or if cloudflare is used.

In my opinion it’s most likely the caching used on the website. For example, usually adding a simple parameter after the website URL bypasses the cache, so I see the correct version like this – https://prnt.sc/P5jcuAmOrCR2 So you are most likely using a mobile page. Could you let me know what caching you are using? I can;t log into the website, I tried with an old user and pass but they aren’t working anymore.

As a note, in case the caching you are using doesn;t support dedicated mobile content, then the only solution is to stop using a mobile page, and fix the desktop page so it looks good on mobile as well.

Let me know.

Regards, Simion C.

Ah, got it. Disabled and the pages are now showing.

Does that mean I cannot use the mobile theme, and have the pages working properly?

Hi,

Could you explain how I ‘select the tagDiv Mobile theme plugin’?

It is in my plugins, activated, but I cannot ‘select’ it.

I’ve deactivated and reactivated it, cleared full cache.

Thanks for the help.

I have created a mobile theme on my website, but not using a mobile theme plugin, can I use AMP?

Hi Calin,

Thanks for the suggestions — we tested exactly as requested (logged in, no cache, and only tagDiv/theme plugins active) and the issue still reproduces reliably on our side on both desktop and mobile.

From comparing the DOM between an installation where the search works and our installations where it fails, the key difference is where the theme’s Accessibility module ends up placing/targeting #maincontent. The module (via tdAccessibility.js) assigns/normalises the #maincontent container based on what it detects in the page structure (e.g., presence/absence of a proper <main> element and the surrounding wrappers). On our affected sites, #maincontent resolves to a wrapper that also contains the header/search trigger, so when the search is opened the script attempts to apply aria-hidden/inert to #maincontent while focus is still on the search trigger. Chromium then blocks aria-hidden in that state (“descendant retained focus”), and the page ends up in an inconsistent/blocked interaction state.

This would also explain why the same setting appears to work on a generic installation: if #maincontent resolves to the actual content area (excluding the header), the search trigger is not a descendant of #maincontent, so the focus/aria-hidden conflict never happens.

Thank you.