Set message if generated files are missing, document file generation [#1543990]

Let me start by thanking you for the amazing work you've done with AT3.x, it's phenomenal and makes doing responsive sites so easy / clean.

At my agency, we have a local / DEV / TST / PRD deployment workflow. When we commit to our VCS from our local boxes, it auto builds to our DEV environment for collaborative testing. During the build, we exclude any files under public:// to keep the build time down. Since AdaptiveTheme stores it's theme built css/info under public://adaptivetheme, those files never make it onto the DEV server. AdaptiveTheme doesn't do any check to make sure they exist, nor does it currently rebuild them on a site/theme registry cache clear.

It took a while for us to figure out why the site looked different on our DEV box vs our Themer's box and we traced it back to those files being missing. Of course going into the theme settings and re-saving them created the files and fixed the issue, but for others doing this type of dev, they'll likely run into the same confusion.

Since the files are being generated and cached under the public:// directory, it stands to reason that they could/should be rebuilt on a cache clear. When something doesn't look right on the site during development, it's pretty standard practice to just clear the cache to see if it fixes it... so it'd be a quick way to handle this that would be intuitive. If you disagree that's fine - I will defer to your judgement, but I figured I would bring this up and see what you think.

Thanks again!

Comments

Comment #1

Jeff Burnz CreditAttribution: Jeff Burnz commented 24 April 2012 at 00:09

Ha, the irony of this is the very first big site build I am doing with the new version this is the exact issue I am having. The files dir never hits GIT since its so volatile and migrating is a daily chore.

How I envisioned this would work is that users would develop on localhost until they were ready to migrate, so when all dev is done, or pretty close, you copy the info file backup to your theme (replace the themes actual info file). If you are using color module the theme auto-generates a file that includes your custom color scheme as well, with the same copy/paste required.

However, what I really hadn't accounted for is the kind of workflow you are using, and what I am doing right now - I do nightly commits and cannot push the files dir, so I have to a copy/paste the info file backup to the themes info file just before I commit (if I have changed a theme setting), which is OK and beats manual config on the development server (the idea was to reduce human error, i.e. reduce a complex task down to a copy/paste).

Now, I always new this would be the the way it worked, and I am OK with it since it beats manual configuration and potential human error, and I am loath to try to save the files anywhere but the files directory (others have asked to overwrite files in the actual sub-theme, I think that is dangerous and too risky, you might destroy your work without even realizing it).

I'm not sure about blowing away the files dir stuff on a clear cache all, that sounds really complicated and fraught with issues when I start thinking though the permutations.

That said, this is not the first time this idea has been raised, another user asked me the same thing a few months ago. The main issues I see is a UX issue, say you toggled some settings, but did not save them, then forget about that for a bit, then clear the theme registry for some other reason... ops, we have a problem if the theme just saved its settings - OK, it could grab stuff from the database and not the form, but this is what I mean about getting really complex when I think through this. For example the entire submit function and helpers are not looking at the database at all when they fire, only taking form values, so there's potentially some serious re-factoring required.

BTW right now no files get overwritten in public://adapivetheme and this is deliberate due to theme itself having been in development. I wanted to keep a history of files so I could remind myself of things during development. Now I have ask if this is the right thing to do, or to overwrite those files on each theme settings submit. The one thorn in the side of overwriting them is the color module stuff I mentioned earlier, but I could quite easily save that file elsewhere, the way that works you really don't want it overwritten (for various reasons).

So, upshot - clearly we need documentation on these features and how the theme actually works.

Two, think though more complex workflows and how to better support them, such as what you and I are doing with VCS.

I'll put some thought into the issues you have raised, all good points and worth consideration.

Comment #2

Jeff Burnz CreditAttribution: Jeff Burnz commented 24 April 2012 at 12:22

Title:	Rebuild public://adaptivetheme files on cache clear	» Set message if generated files are missing, document file generation
Component:	CSS/HTML	» User Experience

I just wanted to clarify one point made in the OP.

AdaptiveTheme doesn't do any check to make sure they exist...

Actually it does, AT is always checking if file_exists before trying to load any of these generated stylehsheets, otherwise your site could have a lot of 404's etc.

What it doesn't do is tell you they are not loading (silently fails), and that I think is the UX issue here, so what we could do is fire out a warning message/watchdog message if a file does not exist.

I think that would mostly satisfy the requirements of this issue - by at least warning the user what is wrong. I can write up some docs on the file generation system and link to them in the warning message.

Comment #3

jaymallison CreditAttribution: jaymallison commented 24 April 2012 at 16:19

Thanks for the feedback. I get the complexities. We currently use Features to push all of the theme settings across from DB to DB. So we aren't too concerned with the .info file. It's just those CSS files that cause concern.

Either way, to your second post, I agree. It would be adequate to just trigger a drupal_set_message/watchdog message of some sort to make you aware that the files are missing and that you need to re-save the theme settings to generate them.

Those of us that are doing this type of dev are already pushing stuff around with Strongarm/Features anyways so having to go and re-save the theme is nbd. I just don't want to have to do it every time I pull down a new rev from the VCS. I won't always know if I need to, so if the system can tell me that I do, that'd be very helpful.

Comment #4

Jeff Burnz CreditAttribution: Jeff Burnz commented 24 April 2012 at 16:46

Category:

feature

» task

OK, lets make that a go on the drupal_set_message(), I'm on it.

Comment #5

Jeff Burnz CreditAttribution: Jeff Burnz commented 24 April 2012 at 20:00

Category:	task	» bug
Status:	Active	» Fixed

I have pushed a fix to DEV, so available in GIT now for testing.

This works by adding a new function to load.inc - load_failure(), which is called if a file_exists call returns FALSE for any of the files loaded in load.inc, which is all the generated files and some of the actual theme files that are crucial to system operation.

You will get both a drupal_set_message warning, with link to online docs, and a watchdog error.

The online docs: http://adaptivethemes.com/documentation/file-generation-system

Comment #6

jaymallison CreditAttribution: jaymallison commented 24 April 2012 at 20:57

Awesome, thanks Jeff. You rock. I'll check this out and let you know how this works out for us.

Comment #7

Jeff Burnz CreditAttribution: Jeff Burnz commented 27 April 2012 at 12:46

Hows this working for you guys? Its nearing the end of the month and I am entering final reviews before I roll a release candidate, this is one feature I really want to keep (and will), so just wondering if its working for you or if you might suggest some tweaks?

Comment #8

fenstrat

he/him

English

Australia

CreditAttribution: fenstrat commented 27 April 2012 at 21:46

Late to the party here, but thought I'd share our usecase.

We're looking at the 3.x branch for a new project where we'll be using the local dev, copy .info file back into theme dir, commit, push to staging/live workflow outlined by Jeff in #1. This seems like it'll work ok and the drupal_set_message warning should cover the file generation issue.

One question though, what is the usecase for storing a new set of files on every setting save? From a dev point of view it's a lot of files to go digging through to find the .info file I'm interested in. Or am I missing something?

ps. Jeff you've done great work with 3.x. The responsive integration with Panels/DS is superb!

Comment #9

Jeff Burnz CreditAttribution: Jeff Burnz commented 27 April 2012 at 22:03

Well thats a question I'm asking myself right now, with regards to saving new files or simply overwriting existing ones. To find the one I need (the most recently generated one) I just sort on created time and grab the latest one. The rational is/was that I wanted a history of changes when I was actually building some of the core features of the theme, now that is 99.99% done I am thinking to change this and blow away the old files, I'm not sure I see a use case for keeping the older ones anymore, and as you point out just makes it less obvious which ones you are supposed to be looking at.