I'm doing this now...it should get done today.
Glen
On 07/24/2014 11:27 AM, Glen Mazza wrote:
Hi Team, I figured out why WEBLOG.custom_stylesheet is presently
being used, but can be retired with some coding changes. These are
changes I think would be good to do anyway.
There are two types of custom stylesheets: shared theme w/custom
stylesheet and custom theme w/custom stylesheet, either of which store
one row in WEBLOG_CUSTOM_TEMPLATE. Roller needs to know the name of
the stylesheet in order to grab the stylesheet from the
WEBLOG_CUSTOM_TEMPLATE table (and from there,
CUSTOM_TEMPLATE_RENDITION) table. The name of the stylesheet is
matched against the "link" column in WCT to make that match. To get
the name:
1.) For the shared theme with custom stylesheet, Roller takes the name
of the stylesheet from the Shared Theme, information which comes from
the theme.xml file. It doesn't read WEBLOG.custom_stylesheet. This
generally works, but has a drawback that if we remove a shared theme
Roller will not know how to get to the custom stylesheet, and if the
user switches shared themes with a different name for its stylesheet,
the user's custom stylesheet will be inaccessible.
2.) For the custom theme with custom stylesheet, there is no shared
theme.xml file, so Roller needs to read WEBLOG.custom_stylesheet to
get the name.
The architectural problem is that WEBLOG_CUSTOM_TEMPLATE's action
column does not have a STYLESHEET value, requiring the above name
search in order to locate it. As our template parser currently allows
only one STYLESHEET (possibly with multiple renditions) per theme, if
we had this value it would be very easy for Roller to find the
stylesheet: SELECT <row> from WEBLOG_CUSTOM_TEMPLATE where weblogid =
XXXX and action = STYLESHEET. If we have this,
WEBLOG.custom_stylesheet would no longer be needed and the shared
theme w/stylesheet will work even if the shared theme is deleted.
The WEBLOG_CUSTOM_TEMPLATE "action" column, within our code, should be
switched from strings to enum's anyway -- as part of this process I
can add the STYLESHEET value and retire WEBLOG.custom_stylesheet
column. (In a perfect world we'd rename "action" to "component", but
that's less important for now.) As part of the migration process,
we'd have an update command (pseudocode) so current user's templates
can be identified properly:
update weblog_custom_template wct set action = STYLESHEET where action
= custom AND websiteid in (select id from weblog w where theme=custom
and w.link = wct.link);
WDYT? I can probably get this done in a day.
Regards,
Glen
On 07/23/2014 11:30 PM, Glen Mazza wrote:
Offhand, it looks like we can remove it, once I clean up the code a
bit. This column isn't getting populated when I do a custom
stylesheet alone; however, when I switch to a complete custom theme,
it then copies the name of the stylesheet into
weblog.customstylesheet. But it doesn't need to do that, that value
is already in weblog_custom_template, and I don't think it does
anything with that value anyway.
Anyway, all the other columns in the list were removed, if I can't
get to this remaining column it can wait until 5.1 is out.
Glen
On 07/23/2014 10:08 PM, Glen Mazza wrote:
No, in *that* case, we just get a single row in the
custom_template_rendition table for that CSS holding the stylesheet
text (instead of several rows holding also the theme templates.)
It's just that weblog's customstylesheet column is still being
written to and read from for some reason (still necessary? I don't
know...), which I'll investigate. Apparently it's being used as a
path value from the user's resources folder (custom stylesheet
path), but that shouldn't be necessary as the CSS text is in the CTR
table. Stay tuned...
Glen
On 07/23/2014 09:57 PM, Dave wrote:
On Wed, Jul 23, 2014 at 9:38 PM, Glen Mazza <[email protected]>
wrote:
Hmm...Weblog's customstylesheet column is perhaps still in use,
I'll look
more into it tomorrow.
As I remember, custom style sheet is a way to allow a blogger to
add CSS
for their blog while still using a shared theme, and not having to
edit
page templates. I think it is totally separate from the custom
templates.
- Dave
