Fixes #2330 - Responsive mode

[stefopl]

Improving the adaptation of the website to smaller screens.

How it's working: There is an icon next to the logo that allows you to switch between standard and responsive mode. In standard mode, the page looks as usual. After enabling the responsive mode, a cookie is created to remember the state for 24 hours and the class is added to the html tag. Attached to the page is a set of css styles that modify the page only when a special class is added to the html tag.

In responsive mode, the page will fit the browser window width (visible when the width is less than 970px). When the width is less than 769px, the navigation from the left goes to the top, is full width and is converted into an accordion, i.e. you have to click to see the sub-elements of the navigation.

There are probably still places where the page will not be adjusted to the width or where some elements will be moved. In such a situation, it is enough to turn off the responsive mode to use the website as before.

Here is an example of how it works. http://ocpl.stefo.pl/

If it is better to have one commit in PR, I can still do git squash

[deg-pl]

Awesome!

Great work! Thanks!

I have only one question - do we really need "responsive switch"? IMHO better option is make responsive site by default without switch. What do you think about it @kojoty @andrixnet @harrieklomp @Amberel ?

PS: It will be great if you'll use PHP CS-Fixer. Default config you can find in standard location - /.php-cs-fixer.dist.php

[stefopl]

I made a responsive switch because I haven't checked all the places yet. I don't know the entire site, administration pages, creating a new cache, etc. So there may be a problem somewhere and then the switch will be useful. I can change the default state to on.

I think that the switch should be removed only after correcting and testing all subpages. And the changes from style_responsive.css will be transferred to the main stylesheet.

At this stage, it needs a response from users where there is something to improve in order to continue working.

Okay, I'll see what PHP CS-Fixer is all about

[kojoty]

This is #2330 related - not just to create link in the issue

[kojoty]

My opinion:

switch is a good direction as I expect there will be an issues as I can't believe that all our views are ready for such change.

I don't have much time for OC this week but hope to come back to this next week and then review it deeper. @deg-pl if you would like to review and merge this work before that please feel free to do it

@stefopl Thanks for your effort - at the first sight it looks really nice

[andrixnet]

http://ocpl.stefo.pl/ looks neat, with the following mentions:

• index: the map appears broken in all cases and map pins seemed to be positioned outside the content area (desktop landscape), so I can't really check.
• cache page: no map, so I can't say anything about it
• not being able to log in I can't test further

The idea is great and hopefully can be implemented sitewide.

Furthermore, IMO, after this code becomes stable, while retaining the option for the user, the switching could be delegated to a detection JS: https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model/Managing_screen_orientation https://stackoverflow.com/questions/4917664/detect-viewport-orientation-if-orientation-is-portrait-display-alert-message-ad Also I'd look into how to make it work properly when user tells the mobile browser "request desktop site".

[stefopl]

@andrixnet Now the page in my domain is completely broken. But it's probably due to changes to my VPS server. Yesterday I also worked a lot on changes to my domain's DNS. Somehow in the coming days I will try to improve it. If you have an account on opencaching.pl, the account is probably also in my domain, but due to privacy reasons, it has a different email address and password. Send to user@ocpl.stefo.pl the login and email address you want to have for this account. I will make a change to the database and you will be able to use the password reset option for your profile. I will let you know when I improve my domain. Or, you can make changes to your development site or local virtual machine and test there.

[stefopl]

Fixed The map problem was caused by a server misconfiguration, not a code change. If you see any errors on my site, you can send the link and the error text to user@ocpl.stefo.pl. I am constantly working to keep everything working on my server, but I don't think all errors appear in the log. I also have a problem with the SQL query used to display a milestones, because on my server $ rms = XDb :: xFetchArray ($ rsms) seems to be empty, but when I use Xdebug3 step debugging it works fine. But this is completely not related to this PR.

[andrixnet]

THanks, email sent. I can confirm the map now works. Waiting to test the rest. :-) :+1:

[andrixnet]

Comments on how it looks on mobile: Using Samsung S9+ and Chrome for testing.

• top horizontal menu text kinda small
• the entire left menu would be nice to be collapsed by default
• on post log page (log.php), tested on mobile simulation with Firefox rearranges the toolbars a lot, making the actual text area is very small vertically.
• on post log page (log.php), tested on the Samsung S9, portrait, the toolbars don't mobile simulation with Firefox the toolbars don't rearrange, the entire editor block being larger then the screen width, but with no way to scroll horizontally. On this device I can only see towards the right up to the redo and superscript toolbar buttons. The actual text entry area is vertically ok however.
• on log.php, on the Samsung, the Type of log and date block also doesn't respond properly, while it does on the Firefox mobile simulator. Same for "post new log in reference ..." title section
• on log.php, some items could use more padding/margin on the left side.
• overall most text could be slightly larger (on mobile portrait), though there's a lot of information so it's both ways
• site has a good number of tables. Watch out for them. Tables with many columns don't fit well on mobile/portrait in general.
• recommended caches, openchecker, new caches, latest logs - table is too wide, no scroll possible.
• search results table looks ok, hide columns block too wide and not responsive
• cache page, this belongs to geopath - fit problem, cache note textarea too wide,
• geopath - some geopaths don't show title fitting properly.
• geopath log dialog shows horizontal scroll for each toolbar in the editor, though a better responsiveness would be best.
• popup map on cache page could use less margins, waste of valuable screen space

This is a short list of what I could quickly test tonight. This is however limited by my access level on ocpl site (i.e. I can't create cache listings)

[andrixnet]

BTW, couldn't test it right now, but you MUST also make responsive the account registration, account confirmation pages and the OKAPI generated authorization page for the likes of c:geo. Very important!.

[stefopl]

Okay, when I have time, I will introduce corrections. At first I didn't want to modify the size of the fonts, but I can see that it is necessary after all. Tables with many columns are the most problematic. They can't be adjusted very much. Perhaps the best solution would be to add a horizontal scroll bar to the container above the table.

I added the ocTeamMember role, if you need another, let me know.

@andrixnet Could you please add links and screenshots with marking to the points. It would make my work much easier, because I don't know the entire portal well yet. You can send to e-mail so as not to spam here. Especially where the OKAPI generated authorization page is.

[stefopl]

@andrixnet

3. 4. I don't see this problem. There are three rows of toolbars. Everyone has a horizontal scroll bar. Textarea seems to be the correct height. This is probably the standard tinyMCE behavior so I didn't want to change that. I don't know where the OKAPI generated authorization page is. Other points corrected.