make default layouts and CSS as part of normal update

[shoulders]

Issue
For me as an end user the layout/template system can be a bit tricky when you see in the downloads section that you have to manully update the default layouts and there are probably a lot of people who never do this.

What do i want?
What I would like is that all updates are done through the normal JDownloads update packages. This might also mean less work by the developers.

How can this be done
The following points would allow this to be done.

• All new layouts would start from ID of 101, this would effectively allow 1 - 100 to be reserverd for the system/default layouts
• All default layouts would become read only. all their fields (including 'use before layout, layout, use after layout, header, subheading area layout, footer etc...). You can still copy the whole layout and then edit that one.
• All existing JDownload installs would have their layout IDs all increased so they are above or start at 101 - This might cause some people to re-select the layouts to be used but it is a not a big problem
• Remove the ability to edit components\com_jdownloads\assets\css\jdownloads_fe.css and components\com_jdownloads\assets\css\jdownloads_buttons.css these should never be edited like this because of upgrades and also as it mentions on the CSS edit page in admin that the file jdownloads_custom.css can override any CSS in the files above anyway. I would also consider if this is needed and whether the CSS overriding should be handled in the users template. I would also then move the CSS from the layouts page to its own CSS page.

[ColinM]

Hi
Thanks for your observations.  I have a few comments.
Firstly however in any update it is only the default layouts that are possibly changed.  From memory I think that has only happended once in the last 3 or 4 years.  The 'user' added layouts are not changed in an update.

"What I would like is that all updates are done through the normal JDownloads update packages. This might also mean less work by the developers."

This is on the list of 'to do' things.  It actually means more work!

All new layouts would start from ID of 101, this would effectively allow 1 - 100 to be reserverd for the system/default layouts

This is not practical and would need extra code to implement so personally I would not rate this highly.  The default layouts are clearly marked as default and do have the lowest ID values. A regular user cannot 'undo' the default setting.

All default layouts would become read only. all their fields (including 'use before layout, layout, use after layout, header, subheading area layout, footer etc...). You can still copy the whole layout and then edit that one.

This is a good idea.

All existing JDownload installs would have their layout IDs all increased so they are above or start at 101 - This might cause some people to re-select the layouts to be used but it is a not a big problem

Same comment as for suggestion 1. Do not think this makes it easier but could be confusing.

Remove the ability to edit components\com_jdownloads\assets\css\jdownloads_fe.css and components\com_jdownloads\assets\css\jdownloads_buttons.css

Yes this migt be a 'nice to have'.  If done it would be as a 'not editable' in jD rather than a file system "thou shalt not be able to edit"! There is always the possibility of an urgent "fix" by a user.

A custom css file.  This is an essential requirement and is not part of a template overlay.  It is only loaded when jD is active in the front end.  One could put it in the template custom file but not all templates have custom css files.  Having a component specific custom css concentrates the jD element in a more cohesive manner in my view.

I would also then move the CSS from the layouts page to its own CSS page.

I sometimes wonder this too. There is however the point of view that css is a vital part of the layout.  In previous versions much of the styling was embedded in the layouts. So there are differeing views.

No doubt the layout scheme will be looked at in detail in the next major version.  One critical area for me is the sbu-cateories layouts  which really need their own 'section' rather than being in the 'categories' section.

Best wishes
Colin

[shoulders]

All new layouts would start from ID of 101, this would effectively allow 1 - 100 to be reserverd for the system/default layouts

this is easy enough. there is a update.sql that can be executed upon update. you could then use a mysql statement to add 100 to all of the layout ids in both the layout table and the tables that store the active layout. I would then re-installed the default layouts into their new home. This would cause effectively 2 copies of the default layouts on some peoples setups but they can just delete the set that is not required. done

This fix makes updating templates easy.

Remove the ability to edit components\com_jdownloads\assets\css\jdownloads_fe.css and components\com_jdownloads\assets\css\jdownloads_buttons.css

Keep the ability to edit the custom css but get rid of the ability to edit the other 2 files. then move the css edit to its own menu item called Custom CSS. It even says in the custom css edit textarea : "So you can use it to overwrite the standard css classes for your own customising."

Urgent fixes can be done in the custom CSS file and you should never get users to edit system files.

I would also then move the CSS from the layouts page to its own CSS page.

The css is nothing to do with layout really. The editing process in the layout files never requires you to edit the CSS for the layout but for styling only. I do appreciate you can alter layout with CSS but those people who would do that would know to do it in the CSS file.

I would also go one further is that people would do their styling in their template.

You could keep the other 2 files read only on that page so people can copy and paste. (not a big fan of that)

Still needs its own menu item.

thanks