Limit the editing to a custom directory path

Hi, thanks for this suggestion - I'm going to leave this up as a feature request and see if there is any more need for this first. Also the functionality in its current form is for a very specific use case, so would be good to get an idea of how else it can be used as well.

Also the .error issue has been fixed in the latest version.

My 2 cents :

Would be nice to have two permissions :

- Edit ANY css file (for admins)
- Edit choosen/specific css files (for less experimented users)

Then in the Live CSS settings page, have a list of found css files with a checkbox, like

Restrict the editable css to :
[x] /mysite/mytheme/style.css
[x] /mysite/mytheme/layout.css
[ ] /system/system.css

But I guess this is much more work.

Yes it would need to be based on entering the URL of allowed files to form a special "Restricted CSS" permission.

I will keep it here, and will look into it if I have the time.

If you have the need for this sooner, please do feel free to submit a patch. I am more than happy to help with answering any implementation questions.

Yes it would need to be based on entering the URL of allowed files to form a special "Restricted CSS" permission.

I will keep it here, and will look into it if I have the time.

If you have the need for this sooner, please do feel free to submit a patch. I am more than happy to help with answering any implementation questions.

The best solution I can come up for this is something along these lines -

1. A separate Live CSS permission offers 'Restricted CSS editing'
2. We then provide a custom text box on the admin page, where the administrator can enter a regular expression that filters the CSS file names for this restricted permission.
3. Based on this permission, users with the restricted css editing get that reduced access.

It still feels a rather unelegant.

If there is a lot of demand for this, I'd be happy to listen to further suggestions, but for now it just feels a little too obscure to add as a primary feature.

Closing unless there is more demand for a feature along these lines.

+1 for this feature

I just wanted to chime in that this is actually something that would be really useful to me too and that your proposed solution feels like it would cover pretty much most of the custom use cases I could think of - it may not be elegant but would work.

Dig this module and have since you first showed it to me when you first were working on it in the Design Indaba days :)

I have a useful little distro I am working on that it fits nicely with - will share more as it develops.

Thanks Greg! Did you manage to try out the patch here? We can certainly still see about moving towards getting this integrated. Reopening for now and happy to consider further patches.

At first I was actually against this idea but this might be a neat feature, especially for those without write access to the themes/ folder. I have a slightly different take on the idea though.

The main difference is that I want each theme file to be editable and instead of saving back to that file, to save to a new one in default/files/themecss (for instance). Then use drupal to unload the old/load the new CSS in its place. This is different in that it does not use just one custom.css file (although both features would be useful to include).

If anyone else thinks this is what they're looking for I might put it in the next D7/D8-dev (although a feature like this might warrant a whole new 3.x branch, especially if I add the other feature I've got planned).

Feedback welcome :)

The issue with this is that @imports will be quite complex to redirect as well if editing a file that was imported into another sheet. Moving one dependency in a dependency tree of CSS is a complex thing to do.

Would I be right in assuming the main reason for this would be because of the lack of "backups" with LiveCSS?

If so, providing a backup / versioning feature for files may be worth considering. Eg writing to "my/file.css.bak1" and then allowing a restore feature to load from various "save points".

But that is a very separate feature to this editing restriction, which pretty much should be regex based through an admin interface with permission groups it sounds.

Here's a patch that adds a textfield to the Live CSS admin form.
You can input a regex for the file paths to the CSS files you wish to display on the Live CSS tab.
It's a more generalized way to the previous patch posted.

I'd be interested to hear what @deryck.henson thinks. It seems sensible to me though.

Love the idea.

In fact I spent all night on the implementation and expanded on a couple other ideas I had been putting off for a little while but one of them in particular will take a bit more work (autosave option in between switching files). Seemingly simple task that needs to be implemented correctly or it fails.

But this patch has been incorporated and improved upon for usability and security in mind (although much more rigorous testing will be needed due to potential XSS or injection attacks). But as a working concept I'm updating the repo now so go get the latest copy from GIT if you want to take it for a spin.

New permissions include Full, Limited and Admin rights and are explained in the source as well as the settings page.

Time for bed now. Still a work in progress so everyone that finds a bug, send it our way so we can get it fixed ASAP.

Cheers!

PS - clone the 7.x-2.x branch or download the latest -dev release in a day or two for what I've included.

This sounds amazing! I will check it out when I can.

Do let me know when you think it is ready for code review as well.

Apologies - I'm going to be stupidly busy over the next couple of weeks. This is on my list as soon as I get a moment.

Perhaps we can try to get this as close to release ready, so that we can get a release out immediately after review?

If you want to move sooner, I may be able to source another reviewer.

Haha no worries. Since the time of that post, I've added probably 6 more commits and incorporated another patch from a different bug report too.

I'm down for the other reviewer if you want to do that. Check your e-mail for a couple minor questions I thought of that go kinda off-topic from the issue here.

This would be really great!

@groovedork - it's functional in the current -dev release. Go try it out and lemme know what problems you find (if any). :)

This is a feature I would like to see. I downloaded the patch but it had an error so I fixed it. The error is that you have Drupal.settings.live_css_alter.onlypathfile where it should be Drupal.settings.live_css.onlypathfile.

@dsoini the release we have coming soon incorporates the path isolation and even uses permissions to determine who is restricted and who isn't.

I have incorporated changes from the patch by @aznleng in my new dev release, along with a couple other goodies. Please head over and test it out so we can push a new release soon!

Thanks for the contribution here; it was a great idea :)

Another change to feature - "hidemodules" (only show theme CSS instead of every CSS file) will be overridden if the restriction path is set.

*It won't affect those not limited to the path to begin with.*

Also should be able to combine permissions (css admin with css limited = admin, all 3 = admin, etc). See comments in source for more info (really just internal workaround for Drupal's failure to accommodate multiple permissions that relate to each other). The other way around this is to use roles to distinguish each but this is an idiot-proof method.

Doesn't work for me using the dev release. My regex is:

sites\/all\/themes\/test

shows all .css files in the list.

Ticking Only show theme CSS does work.

Since, it's committed I think we can close the task.