I've fixed the first issue, thanks.
For the second, is this some javascript that's looking for specific HTML? I'd perhaps like to change the code that looks for those ids if so (I've tripped over a few of these issues). I'm guessing this is because we have block hiding and docking switched off, so I should probably install a new Moodle and get things working with whatever the defaults are.
It's certainly this kind of help that I'm looking for but I think I'll add a second post to explain myself better, as to why some things are broken like this and how people can help.
David Scotson
Αναρτήσεις που έγιναν από τον/την David Scotson
The zip is just the theme/bootstrap folder from the full repository. The best way to keep up with latest developments without installing git etc. is to download the full thing as a zip file then grab that folder and throw the rest away.
On this page:
https://github.com/ds125v/moodle-bootstrap/downloads
the big pale blue buttons near the top labelled "dowload as zip" gives you all the very latest code from which you can grab the theme folder. It'll save me having to manually update the zip, which I'll probably remove once the code moves on slightly.
On this page:
https://github.com/ds125v/moodle-bootstrap/downloads
the big pale blue buttons near the top labelled "dowload as zip" gives you all the very latest code from which you can grab the theme folder. It'll save me having to manually update the zip, which I'll probably remove once the code moves on slightly.
So, to better manage expectations:
THIS IS NOT A FINISHED THEME, DO NOT USE IT ON A PRODUCTION SITE.
So if it's not a finished theme, what is it? Well, currently it's basically a byproduct of the theme I built for my institution. The key result of this is that if you don't have your Moodle set up the same way as we do, then lots of things will be missing or broken.
For example, we've got our own, institution specific banner as a header. The one in this theme is just something I quickly nicked from one of the Bootstrap examples. I intended to wire up the custom menu (using some code from Stuart Lamour and Bas Brands) before re-announcing it, but I thought getting it out and building some buzz might be a better idea.
Other examples include, docking blocks (we don't use them), hiding blocks (again, we don't use it. I think this might actually be overriden in the renderer with code that does nothing currently), our login screen is only for existing users so if you have your Moodle set up to let people sign up it might look odd. And so on.
Basically if it's horribly broken, I probably already know about it. The reason I'm making it public anyway is I'm hoping that someone who uses those features (and therefore understands them and can test them) will fix them for their own use. I'll maybe set up the bug tracking in github so that people can track progress on these things and find other interested parties to fix the code or do some testing.
I need to focus on the stuff that our institution uses, but I'm hoping that what's there acts as enough of a proof of concept to get others on board to fill out the empty spaces, and that we can work together to advance faster than we could individually. I'm happy to help out with any aspect, but in particular if I don't use and/or understand part of Moodle, and therefore can't test any changes I make properly, then I'd be looking for some outside assistance to help tackle those areas.
THIS IS NOT A FINISHED THEME, DO NOT USE IT ON A PRODUCTION SITE.
So if it's not a finished theme, what is it? Well, currently it's basically a byproduct of the theme I built for my institution. The key result of this is that if you don't have your Moodle set up the same way as we do, then lots of things will be missing or broken.
For example, we've got our own, institution specific banner as a header. The one in this theme is just something I quickly nicked from one of the Bootstrap examples. I intended to wire up the custom menu (using some code from Stuart Lamour and Bas Brands) before re-announcing it, but I thought getting it out and building some buzz might be a better idea.
Other examples include, docking blocks (we don't use them), hiding blocks (again, we don't use it. I think this might actually be overriden in the renderer with code that does nothing currently), our login screen is only for existing users so if you have your Moodle set up to let people sign up it might look odd. And so on.
Basically if it's horribly broken, I probably already know about it. The reason I'm making it public anyway is I'm hoping that someone who uses those features (and therefore understands them and can test them) will fix them for their own use. I'll maybe set up the bug tracking in github so that people can track progress on these things and find other interested parties to fix the code or do some testing.
I need to focus on the stuff that our institution uses, but I'm hoping that what's there acts as enough of a proof of concept to get others on board to fill out the empty spaces, and that we can work together to advance faster than we could individually. I'm happy to help out with any aspect, but in particular if I don't use and/or understand part of Moodle, and therefore can't test any changes I make properly, then I'd be looking for some outside assistance to help tackle those areas.
It's both. In the short-term I'm keeping everything in the theme, but everytime I find something that's an outright bug, or could be done much easier if core Moodle was changed, I'm filing an issue on Moodle's Tracker and recording the bug number in the relevant section of the theme. This means that as those bugs get fixed, I can go back and remove the workarounds and make the theme simpler and cleaner.
The primary aim isn't to produce a nice theme, but to make theming Moodle easier (which in turn attracts developers, which in turn generates themes, which in turn produces lots of nice themes). To achieve that long term goal then there's going to have to be changes to core. I think of renderers.php as a staging area for wider testing of code. Some of it is just stylistic choices which belongs in a theme, but some of it is usability or front-end design choices that I'd quite like to see absorbed back into Moodle core, it's just easier to start a discusson to achieve that with working code and wide use via a theme.
The primary aim isn't to produce a nice theme, but to make theming Moodle easier (which in turn attracts developers, which in turn generates themes, which in turn produces lots of nice themes). To achieve that long term goal then there's going to have to be changes to core. I think of renderers.php as a staging area for wider testing of code. Some of it is just stylistic choices which belongs in a theme, but some of it is usability or front-end design choices that I'd quite like to see absorbed back into Moodle core, it's just easier to start a discusson to achieve that with working code and wide use via a theme.
My contribution to defining what is wanted is to suggest that the final HTML output should look as much like Twitter Bootstrap's form HTML as possible.
I see this is already possible with minor tweaking of QuickForm2
http://mansion.im/tests/quickform2-bootstrap.php?step=1 (before tweaks)
http://mansion.im/tests/quickform2-bootstrap.php?step=2 (after tweaks)
This appears to use a similar "renderer" system as Moodle itself now implements, which allows you to share core code with other projects that want slightly different outputs.
I see this is already possible with minor tweaking of QuickForm2
http://mansion.im/tests/quickform2-bootstrap.php?step=1 (before tweaks)
http://mansion.im/tests/quickform2-bootstrap.php?step=2 (after tweaks)
This appears to use a similar "renderer" system as Moodle itself now implements, which allows you to share core code with other projects that want slightly different outputs.