add the main menu module to position MENU .
add the search module to position SEARCH .
test it on mobile :
the search show just after click on the colaps menu button .
extract the search position from the navbar div
joomla 4 alpha 6
Priority | Critical | ⇒ | Medium |
According to https://docs.joomla.org/Bug_and_Issue_Tracker_Priority changed Priority from "Crticial" to "Medium".
According to https://docs.joomla.org/Bug_and_Issue_Tracker_Priority changed Priority from "Crticial" to "Medium".
Title |
|
I can't remember off hand if this was in @C-Lodder original template PR or something I changed after. I assume the reasoning was for a less cluttered small screen display. I'm easy about it so feel free to change if you deem this an issue.
Is this even going to be the J4 template? I'm hearing mixed reports.
Status | New | ⇒ | Discussion |
i see the issue on alpha 7 too .
Category | ⇒ | Templates (site) |
Labels |
Added:
J4 Issue
|
Why is this expected behaviour? Why hide the search bar in small-screen view, anyway?
I cannot believe that tapping what everyone would believe to be a tappable menu - i.e. the three lines that countless websites use to indicate the presence of a mobile-friendly menu - should display an otherwise hidden search bar.
If I viewed a website with this template I would be very surprised not to find a menu under the three lines.
The main menu in Cassiopeia's default position of sidebar-right disappears completely on a mobile phone if there's any content on the page:
The main menu is down below here somewhere in the sidebar that has dropped below the component area.
Why is this expected behaviour? Why hide the search bar in small-screen view, anyway?
This wasn't done with any serious consideration or reasoning. I don't think anyone would argue against changing it.
I propose the following change to Cassiopeia index.php and some extra CSS for the search div:
Index.php - remove lines 103 to 115 inclusive:
<?php if ($this->countModules('menu') || $this->countModules('search')) : ?>
<button class="navbar-toggler navbar-toggler-right" type="button" aria-hidden="true" data-toggle="collapse" data-target="#navbar" aria-controls="navbar" aria-expanded="false" aria-label="<?php echo Text::_('TPL_CASSIOPEIA_TOGGLE'); ?>">
<span class="fa fa-bars"></span>
</button>
<div class="collapse navbar-collapse" id="navbar">
<jdoc:include type="modules" name="menu" style="none" />
<?php if ($this->countModules('search')) : ?>
<div class="form-inline">
<jdoc:include type="modules" name="search" style="none" />
</div>
<?php endif; ?>
</div>
<?php endif; ?>
Replace with:
<?php if ($this->countModules('search')) : ?>
<div id="search" class="form-inline">
<jdoc:include type="modules" name="search" style="none"/>
</div>
<?php endif; ?>
Add the following css (somewhere):
#search { margin-top: 10px; }
@media (min-width: 992px) { #search { margin-top: 0; } }
I'm also not sure what would happen if someone wanted to put an actual menu behind the burger bar.
In all fairness here, my company has done a few websites where clicking a "hamburger icon" on mobile or tablet devices shows both the main menu and a search bar (usually this also involves an off screen menu coming into view from the side instead of the Bootstrap navbar behavior). So while it might not be the normal thing for many people, it is a practice that is used and can work well. All that to say I don't see an issue with the current behavior myself but we all know what they say about opinions.
In all fairness here, my company has done a few websites where clicking a "hamburger icon" on mobile or tablet devices shows both the main menu and a search bar.
At the moment, it only shows the search bar.
Then I’d say there’s a bit of a logic bug. Either the main menu should be in the header area (as most would expect) which doesn’t make things look “broken” with the hamburger menu only toggling search or there shouldn’t be a menu spot in the header and therefore no need for a hamburger.
At a minimum it sounds like the template needs conditional logic as to whether the hamburger should even render based on whether some module uses the menu position.
Then I’d say there’s a bit of a logic bug. Either the main menu should be in the header area (as most would expect) which doesn’t make things look “broken” with the hamburger menu only toggling search or there shouldn’t be a menu spot in the header and therefore no need for a hamburger.
I have to agree with you.
Status | Discussion | ⇒ | Information Required |
@hitaly Is this still an issue in the latest J4 build?
Priority | Medium | ⇒ | Low |
Status | Information Required | ⇒ | Confirmed |
Build | alpha 6 | ⇒ | 4.0-dev |
@hitaly Is this still an issue in the latest J4 build?
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/24129.
@jwaisner YES YES ...
i tryed it now on j4 beta1 and the issue still there .
@jwaisner
i dont know why you turned the Priority to low ?!
and why this bug still there in alpha 4 ?!
i mean why this bug still there in beta 4 ?!
That has been solved in Cassiopeia repository:
joomla/cassiopeia#89
That has been solved in Cassiopeia repository:
joomla/cassiopeia#89
Well, I never knew that repository was there. How is it different from the joomla-cms repository, which has Cassiopeia files in its code?
@Scrabble96 That repo is dedicated to Cassiopeia fixes and improvements. It will eventually be merged back into this repo.
If you are in glip, you can join the Cassiopeia public channel
Labels |
Added:
?
|
just now i download beta 4 and test it ... the bug still there and not fixed .
steps :
1- add the menu module to menu position .
2- add the search module to search position .
3- on pc click ctrl with + to zoom in the screen until see the colaps menu icon and the search will hide .
4- click the colaps menu icon , you will see the search under the menu .
@drmenzelit fantastic
very good news .
This should be closed now
Status | Confirmed | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-11-14 17:24:00 |
Closed_By | ⇒ | Quy |
Please add "[4.0]" at Start of Title.