Moodle Community Sites
  1. Moodle Community Sites
  2. MDLSITE-1511

2.0 Moodle Docs styling and navigation improvements

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Component/s: docs.moodle.org
    • Labels:
      None
    • Rank:
      19785

      Description

      Moodle Docs currently has a lot of blocks for navigation - in the left column and on the right of many pages e.g. http://docs.moodle.org/20/en/Forum_settings - which is a problem for smaller screen sizes. It also has a navigation bar e.g. Home ► Moodle Docs ► English ► Forum settings which I doubt is used much.

      My suggested improvements are as follows:

      1. Do away with blocks in the left column and move links to the page footer, similar to what has been done in the Unified Republic of Stars MediaWiki skin http://www.unifiedrepublicofstars.com/wiki/index.php/The_Unified_Republic_of_Stars:Skin
      2. Do away with the MediaWiki search completely (it doesn't work well at all) and instead have a Google-powered 'Search Moodle Docs' at the top right of each page (replacing the 'Search moodle.org' feature)
      3. Do away with the current navigation bar and instead add styling to a navigation trail created by templates (see MDLSITE-1516)

      Note: These are rough suggestions which need further thought, such as where to include links to http://docs.moodle.org/overview/ and http://docs.moodle.org/20/en/Table_of_Contents. Also, the Moodle Docs skin should continue to work for all the other Moodle Docs wikis.

      1. 2011-09-20 18.35.bmml
        7 kB
        Helen Foster
      2. 2011-09-20 18.35.bmml
        7 kB
        Helen Foster
      3. 2011-09-20 18.35.bmml
        6 kB
        Helen Foster
      1. 2011-09-20 18.35.png
        86 kB
      2. moodledocstheme.newnavbar.png
        277 kB
      3. moodledocstheme.oldnavbar.png
        272 kB

        Issue Links

          Activity

          Hide
          Helen Foster added a comment -

          Added UI Mockup: <2011-09-20 18.35>

          Show
          Helen Foster added a comment - Added UI Mockup: <2011-09-20 18.35>
          Hide
          Chris Collman added a comment -

          FYI to everyone. I have also felt the right side has gotten crowded. I think is should be rare to have more than 2 templates on a page anyway. Today I noticed in the Quiz template "Other activities", which is a simple way to bounce back to the Activities page and it's template. There are a couple of more places where that concept can be used.

          Another opinion, I do not like it when the template extends beyond the introduction or general comments.
          But I do like that they are in a consistent place and easy to get to. Templates on the right maybe considered clutter by some but they are above the fold and easy to get to.

          I think I did suggest some footer templates way back when, so I am not against the idea.

          Show
          Chris Collman added a comment - FYI to everyone. I have also felt the right side has gotten crowded. I think is should be rare to have more than 2 templates on a page anyway. Today I noticed in the Quiz template "Other activities", which is a simple way to bounce back to the Activities page and it's template. There are a couple of more places where that concept can be used. Another opinion, I do not like it when the template extends beyond the introduction or general comments. But I do like that they are in a consistent place and easy to get to. Templates on the right maybe considered clutter by some but they are above the fold and easy to get to. I think I did suggest some footer templates way back when, so I am not against the idea.
          Hide
          Chris Collman added a comment -

          Did I move too fast?
          I am ready to back pedal if need be In my view at the moment, Nav bar is used goes up the hierarchy/outline and the templates drill down.

          Visually, an issue is created on the nav bar on a feature's homepage. The two options can be seen on the [[Chat module]] and [[Lesson modules]] pages. I do not like the bullet list on the Lesson module page. I do not like the double dead links shown in the nav bar on the Chat module's homepage, I very much like the nav bar in general.

          Having a bullet list of links that will be found on the template,I find distracting because it is inconsistent. Templates have been used to drill down in a context. Even if list was placed inside a box or in a colored block it violates the "natural" order.

          If the double dead links offend, We use 2 templates. We could have 2 templates. For example Chat and Chat0. Where Chat0 is the feature homepage template, and Chat used on any of the links off Chat0. Both would be the same except for the nav bar.

          I have the sneaking idea that there is MediaWiki code that would solve the visual problem of dual dead links, but I bet it will look visually complicted and not very user friendly.

          I do not want the viewer to have to scroll down to see the bullet list in order to drill down.

          Show
          Chris Collman added a comment - Did I move too fast? I am ready to back pedal if need be In my view at the moment, Nav bar is used goes up the hierarchy/outline and the templates drill down. Visually, an issue is created on the nav bar on a feature's homepage. The two options can be seen on the [ [Chat module] ] and [ [Lesson modules] ] pages. I do not like the bullet list on the Lesson module page. I do not like the double dead links shown in the nav bar on the Chat module's homepage, I very much like the nav bar in general. Having a bullet list of links that will be found on the template,I find distracting because it is inconsistent. Templates have been used to drill down in a context. Even if list was placed inside a box or in a colored block it violates the "natural" order. If the double dead links offend, We use 2 templates. We could have 2 templates. For example Chat and Chat0. Where Chat0 is the feature homepage template, and Chat used on any of the links off Chat0. Both would be the same except for the nav bar. I have the sneaking idea that there is MediaWiki code that would solve the visual problem of dual dead links, but I bet it will look visually complicted and not very user friendly. I do not want the viewer to have to scroll down to see the bullet list in order to drill down.
          Hide
          Helen Foster added a comment -

          Chris, sorry I somehow managed to add a reply to this comment in MDLSITE-1516 Please see also MDLSITE-1520.

          Show
          Helen Foster added a comment - Chris, sorry I somehow managed to add a reply to this comment in MDLSITE-1516 Please see also MDLSITE-1520 .
          Hide
          Helen Foster added a comment -

          Just noting that the blocks in the left column are currently controlled by http://docs.moodle.org/20/en/MediaWiki:Sidebar

          Show
          Helen Foster added a comment - Just noting that the blocks in the left column are currently controlled by http://docs.moodle.org/20/en/MediaWiki:Sidebar
          Hide
          Sam Hemelryk added a comment -

          Hi Helen,

          I'd love to try and catch you online at some point to discuss this issue.
          Martin has me working on this issue presently. I've been working on the mockup that you have produced and have tidied up several things including moving the left hand blocks down to the bottom of the screen.
          What I'd like to discuss with you is the following:

          1. You plans for the two navbars and what we can do there.
          2. Dealing with moving thumbnails to the left.

          And of course the idea in general to make sure I have the right thing in mind.
          What timezone are you in at the moment and what hours are you likely to be online?
          Hehe I think you are coming online an hour or so after I am heading off, I'll just sign on in the evening some time and catch you.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Helen, I'd love to try and catch you online at some point to discuss this issue. Martin has me working on this issue presently. I've been working on the mockup that you have produced and have tidied up several things including moving the left hand blocks down to the bottom of the screen. What I'd like to discuss with you is the following: You plans for the two navbars and what we can do there. Dealing with moving thumbnails to the left. And of course the idea in general to make sure I have the right thing in mind. What timezone are you in at the moment and what hours are you likely to be online? Hehe I think you are coming online an hour or so after I am heading off, I'll just sign on in the evening some time and catch you. Cheers Sam
          Hide
          Helen Foster added a comment -

          Hi Sam,

          Thanks a lot for working on this issue - can't wait to see your improvements! I'm going to try and catch you online in around 12 hours from now which I think is 9:00am in New Zealand.

          Show
          Helen Foster added a comment - Hi Sam, Thanks a lot for working on this issue - can't wait to see your improvements! I'm going to try and catch you online in around 12 hours from now which I think is 9:00am in New Zealand.
          Hide
          Helen Foster added a comment -

          Edited UI Mockup <2011-09-20 18.35>: repositioning screenshot

          Show
          Helen Foster added a comment - Edited UI Mockup <2011-09-20 18.35>: repositioning screenshot
          Hide
          Sam Hemelryk added a comment -

          Ok I've got purposed changes ready to test.... however one thing occurred to me just before.
          Helen you mentioned the other night that this was going to be used on just the 2x wiki to start with, I was just thinking I don't know whether the code base is shared across the wiki's. If it is then the purposed changes I've got which modify the existing theme will need to be separated into a new theme leaving the old theme as it is presently.
          I will talk to Martin/Jordan about this when one of them comes online today.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Ok I've got purposed changes ready to test.... however one thing occurred to me just before. Helen you mentioned the other night that this was going to be used on just the 2x wiki to start with, I was just thinking I don't know whether the code base is shared across the wiki's. If it is then the purposed changes I've got which modify the existing theme will need to be separated into a new theme leaving the old theme as it is presently. I will talk to Martin/Jordan about this when one of them comes online today. Cheers Sam
          Hide
          Sam Hemelryk added a comment -

          Screenshots posted of the two themes - old navbar theme and new navbar theme... check em out.

          Just need Eloy to review now and then we're set to test

          Show
          Sam Hemelryk added a comment - Screenshots posted of the two themes - old navbar theme and new navbar theme... check em out. Just need Eloy to review now and then we're set to test
          Hide
          Martin Dougiamas added a comment -

          They look great, thanks Sam! Let's get them on the docs server asap!

          Show
          Martin Dougiamas added a comment - They look great, thanks Sam! Let's get them on the docs server asap!
          Hide
          Helen Foster added a comment -

          Many thanks Sam, I agree with Martin that the new theme looks great!

          Just noting that templates controlling the navigation bar contents shouldn't include wiki markup such as double single quotes (italicizing the text).

          Will the 'In other languages' block (containing inter-wiki links) be positioned next to the toolbox at the bottom of the page?

          Show
          Helen Foster added a comment - Many thanks Sam, I agree with Martin that the new theme looks great! Just noting that templates controlling the navigation bar contents shouldn't include wiki markup such as double single quotes (italicizing the text). Will the 'In other languages' block (containing inter-wiki links) be positioned next to the toolbox at the bottom of the page?
          Hide
          Eloy Lafuente (stronk7) added a comment -

          +1 too from a coding pov. Changes are clever and will lead to better / easier upgrades, indeed. Great job, Sam et all!

          Some comments / random thoughts...

          1) While personally I don't buy completely the idea of sending the blocks to the footer, I agree they are not used very much, BUT with 2 big exceptions (at least in my real use):

          • Jumping between docs versions: going back and forth to 1.9, 2.0, dev... is used here from time to time. I can survive without it.
          • Jumping to other languages: this is the one I really use a lot, a lot. In both directions. Would be great to have that block transformed in sort of drop-down menu (like moodle.org does, positioned in a similar way and working like a jump menu).

          2) The moodle-cross-site menu. It continues being the old js smartmenu implementation. IMO we need, once and for all, to define the master place where that menu is designed (surely without smartmenus, it looks horrible with JS disabled. Other CSS solution with JS hints here and there, but not dependent of them must be created), and the use that place to populate the rest of sites in an automatic way. Till then we are going to need manual updates all over the time (recompiling jira, hacking mediawiki...). Not to talk about language support. This need to be addressed globally ASAP with any solution providing full automatism and lang support over all sites. Surely this should go to another issue. But reviewing the changes here revived it in my head.

          So, yay! Great job, my +1 for igniting testing phase across browsers!

          Offtopic: Will this change get rid of the idiot "19" in my beloved Spanish Moodle Docs URLs too? (punch) hahaha.

          Show
          Eloy Lafuente (stronk7) added a comment - +1 too from a coding pov. Changes are clever and will lead to better / easier upgrades, indeed. Great job, Sam et all! Some comments / random thoughts... 1) While personally I don't buy completely the idea of sending the blocks to the footer, I agree they are not used very much, BUT with 2 big exceptions (at least in my real use): Jumping between docs versions: going back and forth to 1.9, 2.0, dev... is used here from time to time. I can survive without it. Jumping to other languages: this is the one I really use a lot, a lot. In both directions. Would be great to have that block transformed in sort of drop-down menu (like moodle.org does, positioned in a similar way and working like a jump menu). 2) The moodle-cross-site menu. It continues being the old js smartmenu implementation. IMO we need, once and for all, to define the master place where that menu is designed (surely without smartmenus, it looks horrible with JS disabled. Other CSS solution with JS hints here and there, but not dependent of them must be created), and the use that place to populate the rest of sites in an automatic way. Till then we are going to need manual updates all over the time (recompiling jira, hacking mediawiki...). Not to talk about language support. This need to be addressed globally ASAP with any solution providing full automatism and lang support over all sites. Surely this should go to another issue. But reviewing the changes here revived it in my head. So, yay! Great job, my +1 for igniting testing phase across browsers! Offtopic: Will this change get rid of the idiot "19" in my beloved Spanish Moodle Docs URLs too? (punch) hahaha.
          Hide
          Martin Dougiamas added a comment - - edited

          So, Jordan, this is waiting on you now. I made a subtask MDLSITE-1552 for the installation

          Show
          Martin Dougiamas added a comment - - edited So, Jordan, this is waiting on you now. I made a subtask MDLSITE-1552 for the installation
          Hide
          Sam Hemelryk added a comment -

          Just nothing that presently this is waiting on me again, I need to merge in the changes made to the wiki to support the 2.1 and future 2.w wiki's.
          I am presently finishing up my review of the mymobile theme and will look to do this immediately after so that Jordan can get it onto the test server for us.

          Show
          Sam Hemelryk added a comment - Just nothing that presently this is waiting on me again, I need to merge in the changes made to the wiki to support the 2.1 and future 2.w wiki's. I am presently finishing up my review of the mymobile theme and will look to do this immediately after so that Jordan can get it onto the test server for us.
          Hide
          Sam Hemelryk added a comment -

          The images and customisation css have been added for 2.1, 2.2, and 2.3. At the same time I've merged Jordans changes to LocalSettings.php
          This should be all ready to test again.

          Show
          Sam Hemelryk added a comment - The images and customisation css have been added for 2.1, 2.2, and 2.3. At the same time I've merged Jordans changes to LocalSettings.php This should be all ready to test again.
          Hide
          Sam Hemelryk added a comment -

          Hi Jordan,

          I've backported the skins to REL1_16.
          When I went to do the backport for the settings I found that LocalSettings.php isn't in the REL1_16_private branch like I would have expected.
          Just means that you will need to make those changes yourself where ever that is kept. The changes will be identical to https://github.com/moodlehq/mediawiki-moodledocs/compare/REL1_17_private...MDLSITE-1511_private#diff-1
          On the upside I don't think you will need to worry about the overview.php page although we should test to see it still works at least.

          The skin changes can be found here: https://github.com/moodlehq/mediawiki-moodledocs/compare/REL1_16_skin...MDLSITE_1511_skin_16

          Let me know if you run into any more road blocks.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Jordan, I've backported the skins to REL1_16. When I went to do the backport for the settings I found that LocalSettings.php isn't in the REL1_16_private branch like I would have expected. Just means that you will need to make those changes yourself where ever that is kept. The changes will be identical to https://github.com/moodlehq/mediawiki-moodledocs/compare/REL1_17_private...MDLSITE-1511_private#diff-1 On the upside I don't think you will need to worry about the overview.php page although we should test to see it still works at least. The skin changes can be found here: https://github.com/moodlehq/mediawiki-moodledocs/compare/REL1_16_skin...MDLSITE_1511_skin_16 Let me know if you run into any more road blocks. Cheers Sam
          Hide
          Martin Dougiamas added a comment -

          Poke poke poke

          Show
          Martin Dougiamas added a comment - Poke poke poke
          Hide
          Eloy Lafuente (stronk7) added a comment -

          I've created the MDLSITE-1511_deploy branch by executing, simply:

          Show
          Eloy Lafuente (stronk7) added a comment - I've created the MDLSITE-1511 _deploy branch by executing, simply:
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          I've created the MDLSITE-1511_deploy branch by executing, simply:

          • cd my_local_repo_dir
          • git pull hq
          • git checkout REL1_17_custom
          • git checkout -b MDLSITE-1511_deploy
          • git merge REL1_17_skin
          • git merge REL1_17_private
          • git pull hq MDLSITE-1511_skin
          • git pull hq MDLSITE-1511_private

          In other words, get a new branch using REL1_17_custom as base and merge on it all the branches involved in the process (always the current skin and private ones for a given version, and later any specific ones).

          Later, when the changes are tested and approved, the developer will merge those specific changes into the current ones, so other future deploys will include them)

          That is, ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited I've created the MDLSITE-1511 _deploy branch by executing, simply: cd my_local_repo_dir git pull hq git checkout REL1_17_custom git checkout -b MDLSITE-1511 _deploy git merge REL1_17_skin git merge REL1_17_private git pull hq MDLSITE-1511 _skin git pull hq MDLSITE-1511 _private In other words, get a new branch using REL1_17_custom as base and merge on it all the branches involved in the process (always the current skin and private ones for a given version, and later any specific ones). Later, when the changes are tested and approved, the developer will merge those specific changes into the current ones, so other future deploys will include them) That is, ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          I've pushed it to github repo, but that is one thing that we shouldn't do. The deploy branch must (should) be created locally always IMO, with the repo exclusively having all the pieces needed to build it.

          This time, just for commodity and explain the process, I've pushed it there.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - I've pushed it to github repo, but that is one thing that we shouldn't do. The deploy branch must (should) be created locally always IMO, with the repo exclusively having all the pieces needed to build it. This time, just for commodity and explain the process, I've pushed it there. Ciao
          Hide
          Martin Dougiamas added a comment -

          Thanks Eloy!

          I missed most of the discussion about this - all this merging business seems rather complex. Is it really necessary for this case? Could you quickly explain the rationale/structure here? Just so it's documented.

          Show
          Martin Dougiamas added a comment - Thanks Eloy! I missed most of the discussion about this - all this merging business seems rather complex. Is it really necessary for this case? Could you quickly explain the rationale/structure here? Just so it's documented.
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          well, it was exposed and discussed, I think that both with Jordan and Sam.

          The basis for that is that there are 3 areas in which we are doing changes, together or separately:

          • RELX_Y_custom: the real user names hack, that affects all code base and which changes are public. It's maintained by me (in my public github repo, there are other sites using it).
          • RELX_Y_skin: the changes in skins, it affects stuff only under /skin. It's maintained by Sam in the private repo (this used to be public before 1.16 too, but not anymore)
          • RELX_Y_private: this includes all the changes done for our moodledocs wiki (the Localsettings file, the extensions installed, the changes in maintenance scripts to work under our multi-site structure). It is maintained by Sam/Jordan in the private repo.

          So, at any moment, to get one working version of the moodledocs, all you have to do is to "glue" (mix/merge) those 3 branches for a given version. It's a 20 secs task and you get one "deployable" phase3 dir.

          While one issue is ongoing, usually the involved developers create one sub-branch, hence, Sam created:

          • MDLSITE-1511_skin: to work on skin related changes
          • MDLSITE-1511_private: to work on private related changes
            (this issue did not require the creation of one MDLSITE-1511_custom branch)

          So, for testing, once again, all you have to do is to "glue" all them. It's a 25 secs taks (because there are 2 more branches to glue), but the results are the expected.

          Working this way we maintain independency and rely on git strengths "merging" to be able to build the "deploy" versions at any moment. Doing that by hand (copy/whatever) is really slower. The steps above are also 100% scriptable, so you can have one:

          ./deploy_for_me.sh REL1_17 MDL-1511
          

          And you will get, in < 1 minute one "glued" version ready to be deployed under testing, moving later to prod if everything goes ok.

          And the final step, once the issue has been fixed is, simply, to send all the accepted changes in the MDLSITE-1511_skin and MDLSITE-1511_private branches to the RELX_Y_skin and RELX_Y_private branches (1-line git operation) and then delete safely the MDLSITE-1511 branches, so next builds will include the fix for MDLSITE-1511.

          IMO, it is really, really simple. Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited well, it was exposed and discussed, I think that both with Jordan and Sam. The basis for that is that there are 3 areas in which we are doing changes, together or separately: RELX_Y_custom: the real user names hack, that affects all code base and which changes are public. It's maintained by me (in my public github repo, there are other sites using it). RELX_Y_skin: the changes in skins, it affects stuff only under /skin. It's maintained by Sam in the private repo (this used to be public before 1.16 too, but not anymore) RELX_Y_private: this includes all the changes done for our moodledocs wiki (the Localsettings file, the extensions installed, the changes in maintenance scripts to work under our multi-site structure). It is maintained by Sam/Jordan in the private repo. So, at any moment, to get one working version of the moodledocs, all you have to do is to "glue" (mix/merge) those 3 branches for a given version. It's a 20 secs task and you get one "deployable" phase3 dir. While one issue is ongoing, usually the involved developers create one sub-branch, hence, Sam created: MDLSITE-1511 _skin: to work on skin related changes MDLSITE-1511 _private: to work on private related changes (this issue did not require the creation of one MDLSITE-1511 _custom branch) So, for testing, once again, all you have to do is to "glue" all them. It's a 25 secs taks (because there are 2 more branches to glue), but the results are the expected. Working this way we maintain independency and rely on git strengths "merging" to be able to build the "deploy" versions at any moment. Doing that by hand (copy/whatever) is really slower. The steps above are also 100% scriptable, so you can have one: ./deploy_for_me.sh REL1_17 MDL-1511 And you will get, in < 1 minute one "glued" version ready to be deployed under testing, moving later to prod if everything goes ok. And the final step, once the issue has been fixed is, simply, to send all the accepted changes in the MDLSITE-1511 _skin and MDLSITE-1511 _private branches to the RELX_Y_skin and RELX_Y_private branches (1-line git operation) and then delete safely the MDLSITE-1511 branches, so next builds will include the fix for MDLSITE-1511 . IMO, it is really, really simple. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Also, separated, there is another point that makes this approach ideal, it's that, daily, our mediawiki git clone, is getting the changes from master mediawiki server, so the official branches (REL1_16, REL1_17... get new commits).

          From time to time, I do one merge from those (official) branches to our 3 branches (_custom, _skin, _private), it's, once again, 1-line git command, cleaning conflicts if needed. That way, the upgrade from 1.17.0 to 1.17.5 is 100% automatic, when it used to be a pain in the past.

          I think that was an important point missing in the comment above. Using that approach I was able to re-implement all the changes in 1.16 (when I started using git to track mediawiki and deploy moodledocs) in 1.7 in just a few hours (it used to be days when using SVN and all out customizations).

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Also, separated, there is another point that makes this approach ideal, it's that, daily, our mediawiki git clone, is getting the changes from master mediawiki server, so the official branches (REL1_16, REL1_17... get new commits). From time to time, I do one merge from those (official) branches to our 3 branches (_custom, _skin, _private), it's, once again, 1-line git command, cleaning conflicts if needed. That way, the upgrade from 1.17.0 to 1.17.5 is 100% automatic, when it used to be a pain in the past. I think that was an important point missing in the comment above. Using that approach I was able to re-implement all the changes in 1.16 (when I started using git to track mediawiki and deploy moodledocs) in 1.7 in just a few hours (it used to be days when using SVN and all out customizations). Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Offopic: Wow, just detected that one comment became duped, not sure how, really, I just clicked "edit" to continue afaik. Deleting...

          Show
          Eloy Lafuente (stronk7) added a comment - Offopic: Wow, just detected that one comment became duped, not sure how, really, I just clicked "edit" to continue afaik. Deleting...
          Hide
          Martin Dougiamas added a comment -

          Awesome - that sounds perfect. Thanks Eloy!

          Show
          Martin Dougiamas added a comment - Awesome - that sounds perfect. Thanks Eloy!
          Hide
          Jordan Tomkinson added a comment -

          Eloy, few things:

          After cloning the 'MDLSITE-1511_deploy' branch, i am left with the following files:

          -rw-r--r--   1 root root  264 Nov 18 12:04 error404.html
          drwxr-xr-x 497 root root  20K Nov 18 11:06 extensions
          -rw-r--r--   1 root root  894 Nov 18 11:06 favicon.ico
          -rw-r--r--   1 root root  19K Nov 18 11:06 invaders.swf
          -rw-r--r--   1 root root 5.3K Nov 18 11:06 moodle.gif
          drwxr-xr-x   2 root root 4.0K Nov 18 11:06 overview
          drwxr-xr-x  16 root root 4.0K Nov 18 11:06 phase3
          -rw-r--r--   1 root root  125 Nov 18 11:06 robots.txt
          -rw-r--r--   1 root root  999 Nov 18 11:06 upgradeinprogress.php
          

          What is the extensions/ directory? why is in the root?

          Why has 'prodwiki' folder been renamed to 'phase3' ? all our htaccess rules and apache configs are set to 'prodwiki' - if i move it manually it will break future git pulls.

          Show
          Jordan Tomkinson added a comment - Eloy, few things: After cloning the ' MDLSITE-1511 _deploy' branch, i am left with the following files: -rw-r--r-- 1 root root 264 Nov 18 12:04 error404.html drwxr-xr-x 497 root root 20K Nov 18 11:06 extensions -rw-r--r-- 1 root root 894 Nov 18 11:06 favicon.ico -rw-r--r-- 1 root root 19K Nov 18 11:06 invaders.swf -rw-r--r-- 1 root root 5.3K Nov 18 11:06 moodle.gif drwxr-xr-x 2 root root 4.0K Nov 18 11:06 overview drwxr-xr-x 16 root root 4.0K Nov 18 11:06 phase3 -rw-r--r-- 1 root root 125 Nov 18 11:06 robots.txt -rw-r--r-- 1 root root 999 Nov 18 11:06 upgradeinprogress.php What is the extensions/ directory? why is in the root? Why has 'prodwiki' folder been renamed to 'phase3' ? all our htaccess rules and apache configs are set to 'prodwiki' - if i move it manually it will break future git pulls.
          Hide
          Jordan Tomkinson added a comment -

          Sam,

          Found the following issues with the new skin:

          1) special nav bar isnt working (from martin)
          2) a couple 404's:

          http://docstest/21/en/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared&only=styles&skin=moodledocs&*
          http://docstest/21/en/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=moodledocs&*
          

          3) some images are being loaded from moodle.org - this should not happen and breaks future SSL compatibility

          http://moodle.org/theme/moodle2/sm/h_arrow_over.gif
          http://moodle.org/theme/moodle2/sm/h_arrow.gif
          http://moodle.org/theme/moodle2/sm/v_arrow.gif
          http://moodle.org/theme/moodle2/sm/v_arrow_over.gif
          
          Show
          Jordan Tomkinson added a comment - Sam, Found the following issues with the new skin: 1) special nav bar isnt working (from martin) 2) a couple 404's: http://docstest/21/en/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared&only=styles&skin=moodledocs&* http://docstest/21/en/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=moodledocs&* 3) some images are being loaded from moodle.org - this should not happen and breaks future SSL compatibility http://moodle.org/theme/moodle2/sm/h_arrow_over.gif http://moodle.org/theme/moodle2/sm/h_arrow.gif http://moodle.org/theme/moodle2/sm/v_arrow.gif http://moodle.org/theme/moodle2/sm/v_arrow_over.gif
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Jordan, you have to take, exclusively the results of the "phase3" folder. It is one full-cloned mediawiki repository and they have that structure. Only the "phase3" folder is the one containing the application. The "extensions", for example are ALL the existing extensions (much like our old "contrib")... but you don't need that at all.

          There is no (easy) way to checkout only one directory in git, sorry (there are the sparse checkouts, but I'm sure you won't want to go down that hell, or perhaps yes, I never have used it, one reference: http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Jordan, you have to take, exclusively the results of the "phase3" folder. It is one full-cloned mediawiki repository and they have that structure. Only the "phase3" folder is the one containing the application. The "extensions", for example are ALL the existing extensions (much like our old "contrib")... but you don't need that at all. There is no (easy) way to checkout only one directory in git, sorry (there are the sparse checkouts, but I'm sure you won't want to go down that hell, or perhaps yes, I never have used it, one reference: http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7 Ciao
          Hide
          Sam Hemelryk added a comment -

          Hi guys,

          Jordan I've just been having a look at the three things you mentioned now.

          1. The navbar from what I can see is working, however it is reliant on templates (or code embedded into pages). Perhaps Martin was looking at a page / pages that don't have templates assigned to them yet.

          2. The 404's coming from load.php are an interesting one. I don't really know enough about how the regex's and stuff are working however load.php exists within the phase3 directory and those requests need to end up there. This is new to 1.17 and is likely just not accounted for yet.

          3. The images that you've noted are indeed coming from moodle.org, I see that they are as well on docs.moodle.org. I'll add a commit to each skin branch and cherry-pick it to the deploy branch so that you can test. I'll ping you when that has been done.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi guys, Jordan I've just been having a look at the three things you mentioned now. 1. The navbar from what I can see is working, however it is reliant on templates (or code embedded into pages). Perhaps Martin was looking at a page / pages that don't have templates assigned to them yet. 2. The 404's coming from load.php are an interesting one. I don't really know enough about how the regex's and stuff are working however load.php exists within the phase3 directory and those requests need to end up there. This is new to 1.17 and is likely just not accounted for yet. 3. The images that you've noted are indeed coming from moodle.org, I see that they are as well on docs.moodle.org. I'll add a commit to each skin branch and cherry-pick it to the deploy branch so that you can test. I'll ping you when that has been done. Cheers Sam
          Hide
          Sam Hemelryk added a comment -

          Ok I've just pushed a new commit to both the skin branches and to the deployment branch that address the issue of the images coming from moodle.org.
          Unfortunately I'm not really able to test my solution, they rely on the docs LocalSettings.php file so I will need you to test them Jordan, or update the test site so I can test them.

          The images were being loaded through JS and require a full path to the images. To get around the multi-wiki setup I've exposed $wgStylePath's value through inline JS which the menu now reads to get the image path for its config.
          It hopefully won't require any more regex's or anything special.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Ok I've just pushed a new commit to both the skin branches and to the deployment branch that address the issue of the images coming from moodle.org. Unfortunately I'm not really able to test my solution, they rely on the docs LocalSettings.php file so I will need you to test them Jordan, or update the test site so I can test them. The images were being loaded through JS and require a full path to the images. To get around the multi-wiki setup I've exposed $wgStylePath's value through inline JS which the menu now reads to get the image path for its config. It hopefully won't require any more regex's or anything special. Cheers Sam
          Hide
          Jordan Tomkinson added a comment -

          Commit 3d7d198491984762cf24de9a66226a6f0bb3cf53 fixes the load.php issue from htaccess
          pulled image fixes to docstest.

          can anyone elaborate more on these templates?

          Show
          Jordan Tomkinson added a comment - Commit 3d7d198491984762cf24de9a66226a6f0bb3cf53 fixes the load.php issue from htaccess pulled image fixes to docstest. can anyone elaborate more on these templates?
          Hide
          Jordan Tomkinson added a comment -

          Sam,

          errors from new theme..

          When viewing a 21 english doc:

          [Thu Nov 24 13:10:22 2011] [error] [client 192.168.100.11] PHP Notice:  Undefined variable: wgResourceLoaderValidateStaticJS in /var/www/vhosts/docstest.moodle.local/REL1_17/phase3/includes/resourceloader/ResourceLoaderFileModule.php on line 451, referer: http://docstest/21/en/About_Moodle
          

          When viewing a 20 english doc:
          NOTE: the nav bar doesn't appear even on pages with the code at the top

          [Thu Nov 24 13:10:28 2011] [error] [client 192.168.100.11] PHP Warning:  Invalid argument supplied for foreach() in /var/www/vhosts/docstest.moodle.local/REL1_17/phase3/includes/resourceloader/ResourceLoader.php on line 72, referer: http://docstest/20/en/About_Moodle
          [Thu Nov 24 13:10:28 2011] [error] [client 192.168.100.11] PHP Warning:  Invalid argument supplied for foreach() in /var/www/vhosts/docstest.moodle.local/REL1_17/phase3/includes/resourceloader/ResourceLoader.php on line 98, referer: http://docstest/20/en/About_Moodle
          [Thu Nov 24 13:10:28 2011] [error] [client 192.168.100.11] PHP Notice:  Undefined variable: wgResourceLoaderValidateStaticJS in /var/www/vhosts/docstest.moodle.local/REL1_17/phase3/includes/resourceloader/ResourceLoaderFileModule.php on line 451, referer: http://docstest/20/en
          /About_Moodle
          [Thu Nov 24 13:10:28 2011] [error] [client 192.168.100.11] PHP Warning:  Invalid argument supplied for foreach() in /var/www/vhosts/docstest.moodle.local/REL1_17/phase3/includes/MessageBlobStore.php on line 335, referer: http://docstest/20/en/About_Moodle
          

          This is blocking the install on production.

          Show
          Jordan Tomkinson added a comment - Sam, errors from new theme.. When viewing a 21 english doc: [Thu Nov 24 13:10:22 2011] [error] [client 192.168.100.11] PHP Notice: Undefined variable: wgResourceLoaderValidateStaticJS in /var/www/vhosts/docstest.moodle.local/REL1_17/phase3/includes/resourceloader/ResourceLoaderFileModule.php on line 451, referer: http://docstest/21/en/About_Moodle When viewing a 20 english doc: NOTE: the nav bar doesn't appear even on pages with the code at the top [Thu Nov 24 13:10:28 2011] [error] [client 192.168.100.11] PHP Warning: Invalid argument supplied for foreach() in /var/www/vhosts/docstest.moodle.local/REL1_17/phase3/includes/resourceloader/ResourceLoader.php on line 72, referer: http://docstest/20/en/About_Moodle [Thu Nov 24 13:10:28 2011] [error] [client 192.168.100.11] PHP Warning: Invalid argument supplied for foreach() in /var/www/vhosts/docstest.moodle.local/REL1_17/phase3/includes/resourceloader/ResourceLoader.php on line 98, referer: http://docstest/20/en/About_Moodle [Thu Nov 24 13:10:28 2011] [error] [client 192.168.100.11] PHP Notice: Undefined variable: wgResourceLoaderValidateStaticJS in /var/www/vhosts/docstest.moodle.local/REL1_17/phase3/includes/resourceloader/ResourceLoaderFileModule.php on line 451, referer: http://docstest/20/en /About_Moodle [Thu Nov 24 13:10:28 2011] [error] [client 192.168.100.11] PHP Warning: Invalid argument supplied for foreach() in /var/www/vhosts/docstest.moodle.local/REL1_17/phase3/includes/MessageBlobStore.php on line 335, referer: http://docstest/20/en/About_Moodle This is blocking the install on production.
          Hide
          Sam Hemelryk added a comment -

          Hi Jordan, I will try to get to this today. No promises unfortunately as my priority is with the upcoming release at the moment.
          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Jordan, I will try to get to this today. No promises unfortunately as my priority is with the upcoming release at the moment. Cheers Sam
          Hide
          Sam Hemelryk added a comment -

          Okay, started looking into a things now.

          First up $wgResourceLoaderValidateStaticJS... is crazy... by the looks of it that variable wasn't meant to have been introduced until 1.18.0 (http://www.mediawiki.org/wiki/Manual:$wgResourceLoaderValidateStaticJS) so I have no clue why that is there.
          However I have also found https://www.mediawiki.org/wiki/Special:Code/MediaWiki/104195 which seems to highlight that it is also missing a global declaration.
          A quick grep of the code shows that the only use of $wgResourceLoaderValidateStaticJS is in that one location.
          So the solution... I found http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91914 which outlines how this code originated and really portays the best solution for us:

          1. Add "global $wgResourceLoaderValidateStaticJS" to the readScriptFiles method.
          2. Define "$wgResourceLoaderValidateStaticJS = false;" in our LocalSettings.php with a note to review it when we upgrade to 1.18.
            Jordan are you able to test this, or should I just assume it is going to work and add a commit to fix it?

          As for the "Invalid argument supplied foreach()" notices I can certainly verify that indeed in all three cases the mediawiki code does not check the response from getFromDB. Other than that I have absolutely no idea why it is failing.
          Jordan it may pay to check the following things within the 20 database on docstest:

          • Table msg_resource exists and has columns mr_blob, mr_resource, mr_timestamp, mr_lang.
          • Table module_deps exists and has columns md_module, md_deps, md_skin.

          In regards to the new navbar not working in 20 wiki, that is because in 20 wiki on docstest the pages have not been updated to use the new template system of generating navbars. I've had a quick check on docs.moodle.org and see that Helen has updated it there now. docstest just needs to be updated again at some point.
          Just saw you were asking about the templates above. Helen has set up templates that contain the navbar structure, each branch in the new docs pages tree is essential template that defines the navbar. For instance http://docs.moodle.org/20/en/Template:Forum is the template for forum activity pages.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Okay, started looking into a things now. First up $wgResourceLoaderValidateStaticJS ... is crazy... by the looks of it that variable wasn't meant to have been introduced until 1.18.0 ( http://www.mediawiki.org/wiki/Manual:$wgResourceLoaderValidateStaticJS ) so I have no clue why that is there. However I have also found https://www.mediawiki.org/wiki/Special:Code/MediaWiki/104195 which seems to highlight that it is also missing a global declaration. A quick grep of the code shows that the only use of $wgResourceLoaderValidateStaticJS is in that one location. So the solution... I found http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91914 which outlines how this code originated and really portays the best solution for us: Add " global $wgResourceLoaderValidateStaticJS " to the readScriptFiles method. Define " $wgResourceLoaderValidateStaticJS = false; " in our LocalSettings.php with a note to review it when we upgrade to 1.18. Jordan are you able to test this, or should I just assume it is going to work and add a commit to fix it? As for the " Invalid argument supplied foreach() " notices I can certainly verify that indeed in all three cases the mediawiki code does not check the response from getFromDB. Other than that I have absolutely no idea why it is failing. Jordan it may pay to check the following things within the 20 database on docstest: Table msg_resource exists and has columns mr_blob, mr_resource, mr_timestamp, mr_lang. Table module_deps exists and has columns md_module, md_deps, md_skin. In regards to the new navbar not working in 20 wiki, that is because in 20 wiki on docstest the pages have not been updated to use the new template system of generating navbars. I've had a quick check on docs.moodle.org and see that Helen has updated it there now. docstest just needs to be updated again at some point. Just saw you were asking about the templates above. Helen has set up templates that contain the navbar structure, each branch in the new docs pages tree is essential template that defines the navbar. For instance http://docs.moodle.org/20/en/Template:Forum is the template for forum activity pages. Cheers Sam
          Hide
          Jordan Tomkinson added a comment -

          $wgResourceLoaderValidateStaticJS has been declared as false in LocalSettings.php

          tables msg_resource and module_deps do not exist in 20 english database but do exist in 21 and 22

          Show
          Jordan Tomkinson added a comment - $wgResourceLoaderValidateStaticJS has been declared as false in LocalSettings.php tables msg_resource and module_deps do not exist in 20 english database but do exist in 21 and 22
          Hide
          Jordan Tomkinson added a comment -

          I just ran maintenance/update.php against the 20 english database and we now have the two tables from above.
          I guess the script should be run against all databases

          Show
          Jordan Tomkinson added a comment - I just ran maintenance/update.php against the 20 english database and we now have the two tables from above. I guess the script should be run against all databases
          Hide
          Martin Dougiamas added a comment -

          You need to run it on all databases - it's a standard wiki upgrade script.

          So we're good to go Jordan?

          Show
          Martin Dougiamas added a comment - You need to run it on all databases - it's a standard wiki upgrade script. So we're good to go Jordan?
          Hide
          Helen Foster added a comment -

          The new Moodle Docs theme looks really great! Many thanks to Sam and everyone else who made it possible

          Show
          Helen Foster added a comment - The new Moodle Docs theme looks really great! Many thanks to Sam and everyone else who made it possible
          Hide
          Jordan Tomkinson added a comment -

          can this issue be resolved now?

          Show
          Jordan Tomkinson added a comment - can this issue be resolved now?
          Hide
          Sam Hemelryk added a comment -

          +1 from me to resolve although I think Helen it's your call ultimately

          Show
          Sam Hemelryk added a comment - +1 from me to resolve although I think Helen it's your call ultimately
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Just to note that I'm now in the process of getting all the commits that have been added to the MDLSITE-1511_deploy branch, moving them to the corresponding REL1_17_xxxx branches to keep them present on future updates.

          They are: git log -p a4faa69fe4..c00b39e515

          Some of them, like the wgResourceLoaderValidateStaticJS seems that have been already fixed upstream (v1.17.1 released few days ago).

          Once I've moved everything, I'll create one new MDLSITE-xxxxx referencing the new deploy codebase, just in case you want to test/upgrade (it includes some security fixes).

          Ciao

          PS: Sam, if you read this, plz pong me tomorrow (NZ). It's about the MDLSITE_1511_skin_16 branch... ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Just to note that I'm now in the process of getting all the commits that have been added to the MDLSITE-1511 _deploy branch, moving them to the corresponding REL1_17_xxxx branches to keep them present on future updates. They are: git log -p a4faa69fe4..c00b39e515 Some of them, like the wgResourceLoaderValidateStaticJS seems that have been already fixed upstream (v1.17.1 released few days ago). Once I've moved everything, I'll create one new MDLSITE-xxxxx referencing the new deploy codebase, just in case you want to test/upgrade (it includes some security fixes). Ciao PS: Sam, if you read this, plz pong me tomorrow (NZ). It's about the MDLSITE_1511_skin_16 branch... ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Done, now all the branches:

          REL1_17_custom
          REL1_17_skin
          REL1_17_private

          Include:

          • All the changes happened in mediawiki codebase (now version 1.17.1)
          • All the changes we did in all the: MDL-1511_xxxx branches

          Unique exception:

          • This commit has not been integrated: 8f57844ce9824a7f70ebc3e19bfdf2211eeafe0e (it's the weird char one in opensearch). I decided not to apply it because those vars are not present in the method at all, so I guess we are missing something and opensearch is not working properly in our 1.17

          So now:

          • I'm going to create a new issue for the 1.17.1 update
          • I'm going to create one issue for the opensearch problem, to detect and add the missing code.
          • I'm going to create a new MDLSITE-xxxx_deploy17 branch with the current glue of everything.
          • I think we can safely delete all the MDLSITE-1511 branches

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Done, now all the branches: REL1_17_custom REL1_17_skin REL1_17_private Include: All the changes happened in mediawiki codebase (now version 1.17.1) All the changes we did in all the: MDL-1511 _xxxx branches Unique exception: This commit has not been integrated: 8f57844ce9824a7f70ebc3e19bfdf2211eeafe0e (it's the weird char one in opensearch). I decided not to apply it because those vars are not present in the method at all, so I guess we are missing something and opensearch is not working properly in our 1.17 So now: I'm going to create a new issue for the 1.17.1 update I'm going to create one issue for the opensearch problem, to detect and add the missing code. I'm going to create a new MDLSITE-xxxx_deploy17 branch with the current glue of everything. I think we can safely delete all the MDLSITE-1511 branches Ciao
          Hide
          Helen Foster added a comment -

          Although the new theme looks really great, every page is taking longer to display. People have commented about it in the dev chat, it's that bad. According to Eloy:

          re: the theme really something is wrong there, not sure if some missing file/image or unclosed html tag is causing that but it shouldn't suffer that delay at all.

          Any chance the problem can be fixed, then we can close this issue (otherwise let me know if I should create a new issue for the problem).

          Show
          Helen Foster added a comment - Although the new theme looks really great, every page is taking longer to display. People have commented about it in the dev chat, it's that bad. According to Eloy: re: the theme really something is wrong there, not sure if some missing file/image or unclosed html tag is causing that but it shouldn't suffer that delay at all. Any chance the problem can be fixed, then we can close this issue (otherwise let me know if I should create a new issue for the problem).
          Hide
          Mary Cooch added a comment -

          yes - I have to agree with this. I have loaded 2.2 docs on several different computers today and I timed it once - it took five seconds before it actually took me to the page.

          Show
          Mary Cooch added a comment - yes - I have to agree with this. I have loaded 2.2 docs on several different computers today and I timed it once - it took five seconds before it actually took me to the page.
          Hide
          Sam Hemelryk added a comment -

          Hmm crazy... I've just been trying now but load time for me was exceptionally fast.
          Perhaps it's something to do with server load (NZ time not many people are online).
          Eloy - I'll try to catch you in chat to see if you have any ideas.

          Show
          Sam Hemelryk added a comment - Hmm crazy... I've just been trying now but load time for me was exceptionally fast. Perhaps it's something to do with server load (NZ time not many people are online). Eloy - I'll try to catch you in chat to see if you have any ideas.
          Hide
          Jordan Tomkinson added a comment -

          I'm looking into ways i can improve performance on the backend, but the frontend (code) should also be looked at and optimized

          Show
          Jordan Tomkinson added a comment - I'm looking into ways i can improve performance on the backend, but the frontend (code) should also be looked at and optimized
          Hide
          Martin Dougiamas added a comment -

          1. Where did we end up with on Google Search? I actually think this might not be a good idea after all, because we have to create tens of custom search engines and maintain them. We should restore the normal Wiki search for all wikis.

          2. Can we add prefixes to the page titles? I'm talking about the title that gets used in search results and in bookmarks. Something like "2.0: Forum Settings" "2.2: Forum Settings" etc. That will make generic Google searches better.

          Show
          Martin Dougiamas added a comment - 1. Where did we end up with on Google Search? I actually think this might not be a good idea after all, because we have to create tens of custom search engines and maintain them. We should restore the normal Wiki search for all wikis. 2. Can we add prefixes to the page titles? I'm talking about the title that gets used in search results and in bookmarks. Something like "2.0: Forum Settings" "2.2: Forum Settings" etc. That will make generic Google searches better.
          Hide
          Helen Foster added a comment -

          Regarding the wiki search, as a temporary workaround I added a link to the search page in the navigation block. It's not as good as the wiki search block with input text field, but better than nothing, as I was (surprisingly!) missing the wiki search.

          Show
          Helen Foster added a comment - Regarding the wiki search, as a temporary workaround I added a link to the search page in the navigation block. It's not as good as the wiki search block with input text field, but better than nothing, as I was (surprisingly!) missing the wiki search.
          Hide
          Jordan Tomkinson added a comment -

          performance improvements for docs made today:

          • small theme change to improve image load times
          • installed the Varnish web cache and enabled the internel mediawiki integration
          • enabled gzip compression on all text objects

          From HQ, I saw page loads on http://docs.moodle.org/22/en/About_Moodle go from 7 seconds to 3 seconds
          Please let me know if anyone notices any issues after today's changes

          Show
          Jordan Tomkinson added a comment - performance improvements for docs made today: small theme change to improve image load times installed the Varnish web cache and enabled the internel mediawiki integration enabled gzip compression on all text objects From HQ, I saw page loads on http://docs.moodle.org/22/en/About_Moodle go from 7 seconds to 3 seconds Please let me know if anyone notices any issues after today's changes
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Why the double requests caused by empty $wgRightsIcon has not been fixed yet? It continues causing the problems on each skin having that image. Solution is not skin-based but configuration-based IMO. And it is 2X automatically!

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Why the double requests caused by empty $wgRightsIcon has not been fixed yet? It continues causing the problems on each skin having that image. Solution is not skin-based but configuration-based IMO. And it is 2X automatically! Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Note: Jordan has just unset that variable in settings and now everything seems to be working ok here on all themes (no doubled requests anymore). Moodledocs ones have an extra check (better) but the upstream ones (monobook, vector...) have stopped causing the problem too.

          Thanks, ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Note: Jordan has just unset that variable in settings and now everything seems to be working ok here on all themes (no doubled requests anymore). Moodledocs ones have an extra check (better) but the upstream ones (monobook, vector...) have stopped causing the problem too. Thanks, ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Comment: just guessing if the cause for the menu slowdown is that with Mediawiki, 1.17.1 we are using they new API to include JS/CSS and it seems it causes the smartmenu js to be included at the end of the body.

          And, in the other side, the smartmenus docs (version 6.x) says:

          Make sure you have linked the SmartMenus config (c_config.js) and script core (c_smartmenus.js) files in the head section of your page (preferably just before the closing </head> tag). Only in case you are using the "onload" attribute of the BODY element, you need to put the links to "c_config.js" and "c_smartmenus.js" after the opening <body> tag in the source.

          That seems to recommend to add the js as soon as possible. FYI, ciao

          PS: Now that we have prevented the double requests and have the Vanish cache working, everything seems to go quick, but the menu-issue continue happening (shorter, but happening).

          Show
          Eloy Lafuente (stronk7) added a comment - Comment: just guessing if the cause for the menu slowdown is that with Mediawiki, 1.17.1 we are using they new API to include JS/CSS and it seems it causes the smartmenu js to be included at the end of the body. And, in the other side, the smartmenus docs (version 6.x) says: Make sure you have linked the SmartMenus config (c_config.js) and script core (c_smartmenus.js) files in the head section of your page (preferably just before the closing </head> tag). Only in case you are using the "onload" attribute of the BODY element, you need to put the links to "c_config.js" and "c_smartmenus.js" after the opening <body> tag in the source. That seems to recommend to add the js as soon as possible. FYI, ciao PS: Now that we have prevented the double requests and have the Vanish cache working, everything seems to go quick, but the menu-issue continue happening (shorter, but happening).
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Note:

          • I've backported the last commits in the MDLSITE-1511_deploy branch to their correct branches (REL1_17_skin and REL1_17_private).
          • I've deleted the interim MDLSITE_1511_skin_16 branch because all the wikis are 1.17 based.

          Question:

          • I've plans to delete the MDLSITE-1511_skin and MDLSITE-1511_private branches, while keeping the MDLSITE-1511_deploy branch some more days, until we can consider this close. Any objection about to delete those branches ? (note that all their commits are also in the "correct" REL1_17_skin and REL1_17_private branches.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Note: I've backported the last commits in the MDLSITE-1511 _deploy branch to their correct branches (REL1_17_skin and REL1_17_private). I've deleted the interim MDLSITE_1511_skin_16 branch because all the wikis are 1.17 based. Question: I've plans to delete the MDLSITE-1511 _skin and MDLSITE-1511 _private branches, while keeping the MDLSITE-1511 _deploy branch some more days, until we can consider this close. Any objection about to delete those branches ? (note that all their commits are also in the "correct" REL1_17_skin and REL1_17_private branches. Ciao
          Hide
          Jordan Tomkinson added a comment -

          Please do not delete the deploy branch until you have shown me how to correctly push/pull different code to different repos/branches, otherwise i will not be able to push updates to the production site

          Show
          Jordan Tomkinson added a comment - Please do not delete the deploy branch until you have shown me how to correctly push/pull different code to different repos/branches, otherwise i will not be able to push updates to the production site
          Hide
          Eloy Lafuente (stronk7) added a comment -

          NP, the MDLSITE-1511 branch will be still there for some time, until all we get the way to work with the REL_17_xxxx branches.

          I guess all you need is to commit into REL1_17_private (99% of the times) and then just have some utility that, once executed, brings you a fresh-new deploy dir/branch (that can be pushed/copied to any of your test/prod servers).

          But the key here is that each one should be committing into the corresponding branch (you to private, same to skin and me to custom). Committing to the deploy branch is a waste of time because later I've to look to all commits there, manually backporting them to the "correct" branches.

          But don't worry, for now:

          • Continue committing to the _deploy branch.
          • Let's create one issue to know your workflow and possible solutions.
          • I'll continue backporting manually to the "correct" branches (note that Sam is already committing into _skin, and I'm already committing to _custom, so backport is easier because your commits go to _private 99% of the time).
          • Once this issue (and current wikis) are stable, and we have solved the "workflow" issue, we'll be able to safely delete the current "_deploy" branch (not before).

          In the other side, I'll be deleting the MDLSITE-1511_skin and MDLSITE-1511_private branches, one time I get +1 from you and Sam. Nobody is using them anymore.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - NP, the MDLSITE-1511 branch will be still there for some time, until all we get the way to work with the REL_17_xxxx branches. I guess all you need is to commit into REL1_17_private (99% of the times) and then just have some utility that, once executed, brings you a fresh-new deploy dir/branch (that can be pushed/copied to any of your test/prod servers). But the key here is that each one should be committing into the corresponding branch (you to private, same to skin and me to custom). Committing to the deploy branch is a waste of time because later I've to look to all commits there, manually backporting them to the "correct" branches. But don't worry, for now: Continue committing to the _deploy branch. Let's create one issue to know your workflow and possible solutions. I'll continue backporting manually to the "correct" branches (note that Sam is already committing into _skin, and I'm already committing to _custom, so backport is easier because your commits go to _private 99% of the time). Once this issue (and current wikis) are stable, and we have solved the "workflow" issue, we'll be able to safely delete the current "_deploy" branch (not before). In the other side, I'll be deleting the MDLSITE-1511 _skin and MDLSITE-1511 _private branches, one time I get +1 from you and Sam. Nobody is using them anymore. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Update your local clones from the hq repo, please.

          All branches (but 1511_deploy, haven't modified it because it continues in use) have been updated with latest changes from mediawiki (v1.17.1+, including one security fix).

          All the last commits performed my Jordan in the 1511_deploy branch has been picked to REL1_17_private.

          And that is, IMO if this is stable... we should proceed by clarifying how Jordan has to begin using REL1_17_private and building his "deploy" versions (only for deploy, not for commit).

          And then, finally, close this and delete the 1511_deploy branch.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Update your local clones from the hq repo, please. All branches (but 1511_deploy, haven't modified it because it continues in use) have been updated with latest changes from mediawiki (v1.17.1+, including one security fix). All the last commits performed my Jordan in the 1511_deploy branch has been picked to REL1_17_private. And that is, IMO if this is stable... we should proceed by clarifying how Jordan has to begin using REL1_17_private and building his "deploy" versions (only for deploy, not for commit). And then, finally, close this and delete the 1511_deploy branch. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Note: One new deploy branch has been created @ MDLSITE-1659, and all the commits present in MDLSITE-1511_deploy have been incorporated to their correct branches, upto:

          a7569023c582e4920b36520914afc1c3f17a5808 : Remove unknown char causing php error.

          So we must close this issue and abandon this deploy branch right now. Please, DO NOT commit anything to it.

          Just switch to the new MDLSITE-1659_deploy branch and continue testing there.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Note: One new deploy branch has been created @ MDLSITE-1659, and all the commits present in MDLSITE-1511 _deploy have been incorporated to their correct branches, upto: a7569023c582e4920b36520914afc1c3f17a5808 : Remove unknown char causing php error. So we must close this issue and abandon this deploy branch right now. Please, DO NOT commit anything to it. Just switch to the new MDLSITE-1659_deploy branch and continue testing there. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          With MDLSITE-1659 already resolved and wikis updated to 1.17.2, I'm closing this as fixed and also deleting the old MDLSITE-1511_deploy branch, because it isn't anymore in use.

          Thanks all, ciao

          Show
          Eloy Lafuente (stronk7) added a comment - With MDLSITE-1659 already resolved and wikis updated to 1.17.2, I'm closing this as fixed and also deleting the old MDLSITE-1511 _deploy branch, because it isn't anymore in use. Thanks all, ciao

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development