Our facebook group facebook.com/groups/redaxscript is the right place for questions, remarks and suggestions.
Not on Facebook? Join our IRC channel #redaxscript on irc.freenode.net for instant support.
Hey Malcolm, the best way is to contribute code by yourself to get things done, because we have milestones according to topics like ORM, template engine and stuff. The facebook group is a good place to discuss an feature. Then open an issue on Github an we can talk about the technical details. I can provide consulting to learn more about the Redaxscript standards and quality assurance tools.
Nope, this is not a bug. It's a feature that makes it possible to style modules over your template.
Thanks Henry, but could you give me a real world example of why doing it the Redaxscript way might be useful? ...as I still see it differently: CSS is all about cascading styles from generic to explicit. So normally styles would be output to the HTML in this order: 1. Reset (global) 2. Generic stuff like grids & fonts (global / per site) 3. Template (aka skin) (per site / per page) 4. Module (per page / per module) By outputting Module CSS before the others, means that a module cannot modify styles set in a template. So on the demo site, styles in the template take precedence over styles in the editor module. This seems wrong. In my real world, say the template defines a site-wide background colour for .box_content of WHITE then a specific module requires .box_content to have a background colour of GREY just for the page the module is used on, currently Redaxscript doesn't allow this as the template CSS is output after the module CSS so the background colour is always WHITE and a module cannot change it. So I'm forced to put module specific CSS in the template. So how does the current Redaxscript way benefit us in the real world?
The idea was to override modules with your template. We have very low cascades in Redaxscript, so you will have no problem to handle your CSS. Anyway it is wrong to have 1. Modules und 2. Template that includes the 2.1 Reset and core stuff und 2.2 Template itself... I think we should change that in 2.3.0 while refactoring the loader and head introducing $this->template()->meta(), $this->template()->script() and $this->template()->style() helpers with prepend and append. $this->template()->style()->append('my.css'); $this->template()->style()->prepend('my_at_the_top.css'); // output all css echo $this->template()->style(); Finally, maby we should drop the .loader files and only use the described way...!?
Thanks Henry, that looks like a logical solution and would introduce some flexibility.
Good work Henry!
The parent has to be an ID. The documentation sucks! But we are re-factoring the navigation NOW and the new documentation is much better. :) Might even manage to add the ability to filter by category alias as an alternative to category ID...
We plan to improve our websites documentation for Release 2.3.0 - since it will introduce the new $template->tagStuff() and we update most of the template related functions it does not make sence to update it before that release. https://github.com/redaxmedia/redaxscript/issues/177 https://github.com/redaxmedia/redaxscript/issues/178 It would be helpful to get some ideas, great to get some concept, awesome if someone has the time to write it! :-) If you are asking why the documentation is so bad? Well, developers are lazy about documentation and sometimes you are missing the point of view that users have.
You found a bug, because ".../zz-article-1" should throw an error...
Thats the common practice for security reason, I totally agree. I guess you have an special hoster or even server? Most webspaces do not offer a public and application folder, so Redaxscript (like many other CMS) does not support this. Maby you can hack arround with .htaccess but I have no idea how...
Nothing special about my web host or server - its cpanel, probably the most common hosting environment around!
So you have an dedicated server? Shared hosting is the common hosting world wide and for that reason most CMS work the way they do...
Nope, cpanel on shared apache server - nothing special. Just wanted to keep all the redaxscripts files & folders in a /rs-2-1-0 sub-folder. Not a problem though - they'll just have to go in root. Just makes upgrades more painful with no quick roll-back.