I am new to Plone and I'm just learning how to change stylesheets.
I successfully changed the ploneCustom.css in /Plone/portal_skins/custom/ and saved it.
But when I tried to take a look at the site, I realised that the ploneCustom.css stylesheet isn't even loaded.
According to my research a template is broken...
But what do I do with that information?
Where do I fix it and how?
Thanks for your help in advance!
50 ways of styling Plone, four of them explained:
1.) Customize ploneCustom.css
A relict of the skin-folder-times, by now it is recommended to use browser-based resources, instead.
The reason is, when you have a lot of resources registered, it's hard to keep a correct order of the skin-layers and that can lead to unwanted overrides. Nevertheless, if you don't have a complex setup, or for quick testing, it is feasible to use skin-layers and ploneCustom.css, the exact steps are:
Go to "http://yourhost.net:8080/yourPloneSiteId/portal_skins/sunburst_styles/ploneCustom.css/manage_main".
Click on "customize".
Enter some style for testing, e.g. "body { background: red }", save.
Make sure, CSS-debug-mode is on at "http://yourhost.net:8080/yourPloneSiteId/portal_css/manage_cssForm" also make sure that ploneCustom.css is actually on the list and enabled, meaning the checkbox on the left is checked. It should be the last entry in order to override all other stylesheets.
2.) Use a site's page as style-source
Alternatively you can have a look at "adi.ttw_styles" (disclaimer: I'm the author), which provides you with a stylesheet living in the site as an ordinary item of type "Page" and is registered as a browser-based resource, so naming-conflicts are impossible. Still, the stylesheet lives in the site then, which wouldn't be suitable for cases, where you want to have a reproducable theme.
3.) Include browser-based resources in your addon (f.k.a. "Product")
Well documented.
An addon-generator, which allows you to create an addon holding a browser-based stylesheet and javascript, is "adi.devgen" (disclaiming again: I'm the author), after installation simply execute devgen addBrowserSkel your.addonname of the commandline.
4.) Diazo
The widely promoted state-of-the-art-way-of-theming. Well documented, have fun learning XLST :-)
Related
I need to allow the webmaster of a plone site to change the "main color" of the site (repercuted on the docuemntFirstHeading, portletHeader, etc).
I think I can use the base_properties.prop file liked to a mystylesheet.css.dtml file.
Is there a way to modifiy programmaticaly the base_properties file (which would repercute the changes in mystylesheet.css.dtml with a "&dtml-maincolor" declaration) ?
I'm using Plone 4.3.3
There was a product for Plone 3 called CSSManager which provided a form to edit the base_properties. It may need some updating of imports to work in Plone 4; Plone 4's default "sunburst" theme does not use base_properties, so there probably hasn't been much motivation for that basic maintenance to happen.
Maybe you can look at its code to find out how to edit base_properties.
https://pypi.python.org/pypi/Products.CSSManager
You can have a look at the stylesheet in adi.slickstyle (disclaimer: one of my humble packages), which collects and unifies all selectors setting col, bg-col and borders, so they can be set at once.
If you want to give a user access to a customizable stylesheet via a Plonesite's UI (=not ZMI), check out adi.ttw_styles (disclaimer: yet another one of my humble packages) it allows to use a 'page'-contenttype as the stylesource, thus you can grant edit-permission to any user you want, easily via the sharing-tab of the page.
The future: Plone 5 is said to introduce LESS based styles, to address this and make base_properties obsolete.
I have several large CSS files and making a change can sometimes take a few minutes just to find the right selector to change. I would like it if there was a nice ModX editor for CSS, but I haven't been able to find one. I am willing to settle for splitting up my files into parts, as long as my site still renders. Can I do that and how? If there is a nice editor (plugin?) instead, where can I find one?
I guess the real question is what kind of parts are acceptable for you. If you follow this question, you can begin the process of allowing ModX to manage your CSS. Once this happens, your options open considerably. Your CSS editing will then become easier and less time consuming depending on your level of expertise with ModX. This answer will be pretty simple, as it will show simply how to add a given selector as a resource. Other further development can be intuited from here, though.
CSS as a Resource
Once your CSS is being managed as a Resource (which takes about 15 minutes), you may utilize Templates, Template Variables, Chunks, Snippets and Plugins. Thisis actually pretty amazing, but setup can be a bit of a pain. You will basically be investing some time to save a lot of time in the future. The next logical step is split your Selectors accordingly, but you don't want to break what currently works. Having a fluid understanding of the getResources addon will be crucial to further development.
How to do it:
1. Create a new chunk
Click the Elements tab, and click "New Chunk". Name it "css-selector". Set the content to:
[[+pagetitle]] {[[+content]]}
It's as simple as that. Don't forget to click "Save"! This will let you set a Selector as a resource. It will use the title for the selector and content for the rules. You can forget about using those braces any more. Your new chunk will handle those from now on.
2. Adjusting your Template
Now, we just have to convince the template that it nows how to read parts, as well as not forget the whole. Open your CSS Stylesheet template (the one that says [[*content]] for its content). Adjust the code so that it has the following:
[[!getResources?
&parent=`[[*id]]`
&depth=`1`
&tpl=`css-selector`
&includeContent=`1`
&sortby=`menuindex`
&sortdir=`ASC`
&limit=`99`
]]
[[*content]]
Again, click "Save". Let me explain the Template real quick. If you have child, they'll get rendered first depending on their menu index. Further, it will render the contents of the document that are not children afterward. This will allow you to only make new resources for your most important selectors, while keeping the stuff that will never change in the main resource.
3. Create a new Template
This is so that your selectors don't do anything funny and just render the content. Create a new Template named "CSS Selector". Set its content to:
[[*content]]
4. Create a new Resource
Create a new Resource. Set the title to the selector for the css statement you want to manage. Then set the content to the rules without the braces. For instance, if your css statement is: div#header .logo {border:0;}, you'll set the title to div#header .logo and the content to border:0;. Set the resource alias to whatever you want. I use numbers for each one. Set the template to your new "CSS Selector". Important Now, set the Parent Document to your Stylesheet. Click Save.
5. Testing the Stylesheet
First, Right-click your new resource and choose "View Resource". This will just make sure that the statement was rendered correctly. It should simply say your rule in CSS format.
Next, Right-Click the Stylesheet resource and choose "View Resource". You should see the Selector at the top and all of the other rules below it.
Final Considerations
Observations
You'll notice that your child resources do not have to be changed to "CSS" for Document Type. Only the parent stylesheet has to be. This allows for some neat stuff as your expertise with ModX grows.
You can change the order of rules by simply changing the menu index of them.
The number of rules that can be done this way is based on the &limit variable in the getResources statement in your template. &limit applies to each stylesheet, so in this example you have 99 statements per stylesheet that may be separate resources.
A Note on Server Load
This will place load on the server as the number of resources goes up. For development, keep the "do not cache flag" (!) on your getResources statement. Once you are done, remove the exclamation mark and let it all be cached. This will save a ton of load.
Further Development
I added an isEnabled template variable to mine so I can turn on and off each rule as I pleased.
You may possibly begin to manage your CSS on the front-end utilizing FormIt.
Custom Manager Pages may even be a better option for you.
Further abstraction might allow you to create Groupings of statements for even further organization.
I'm pretty sure I've read somewhere that you can actually move the main plugin *.php file to somewhere else (I assume under your theme directory) to have it safe in case you made changes to it and your plugin updates. I tried Google but I can't find anything. Google page with good results will suffice.
I've just experienced a situation where my 2 plugins which had its layout changed and accommodated my needs and I want to make sure it doesn't happen again. Apart from having the main file in another location, is there a way to move along any CSS and JS files as well?
In Concrete5 CMS there is a nice way of doing this, by creating a new folder inside a block of an addon (may be regarded as a WP plugin), inside of which you can create copies of main file, any CSS and JS files and then you can simply edit them and choose that template for a page location you are using that block in.
I assume there is no such thing in Wordpress but how close can I get?
UPDATE: I found where I applied that advice on creating a new instance of the file then moving it to the theme directory.
The plugin in question was HL-Twitter. These are the plugin files:
admin.php
archive.php
functions.php
hl_twitter.php
hl_twitter_archive.php
hl_twitter_widget.php
import.php
widget.php
Now, this is the top contents (commented out) of the hl_twitter_widget.php:
Widget Theme for HL Twitter
To change this theme, copy hl_twitter_widget.php
to your current theme folder, do not edit this
file directly.
Available Properties:
$before_widget
$after_widget
$before_title
$after_title
$widget_title
$show_avatars
$show_powered_by
$num_tweets: how many tweets to show
$tweets: array of $tweet
$tweet: object representing a tweet
$tweet->twitter_tweet_id
$tweet->tweet
$tweet->lat
$tweet->lon
$tweet->created
$tweet->reply_tweet_id
$tweet->reply_screen_name
$tweet->source
$tweet->screen_name
$tweet->name
$tweet->avatar
$user: represents the Twitter user (ONLY SET IF SHOWING A SINGLE USERS TWEETS!)
$user->twitter_user_id
$user->screen_name
$user->name
$user->num_friends
$user->num_followers
$user->num_tweets
$user->registered
$user->url
$user->description
$user->location
$user->avatar
So I was wrong about copying the main file (in this case hl_twitter.php), but still - this enabled me to edit the file outside the plugin directory and the system somehow checks for its existence and picks it up if exists.
If this behavior something that is natively supported by Wordpress or it has been integrated in the plugin itself?
With themes, Wordpress has a concept of "child themes" which allows exactly that: to keep changes separate from main theme, in case it changes.
I haven't yet found a way to do this with plugins.
I'm using a few tactics myself:
I bump plugin version to a very high number like 99.9. This way Wordpress won't ever update the plugin.
Store my plugins in version control (i use git, but it doesnt matter), this allows you to update the plugin, run the 'diff' tool and see what changes happend. If you don't like you just revert like it would be a bad code you've written. But this approach requires a bit of skill.
Are you talking about running parts of a modified 3rd party plugin, and an updated version, at the same time?
That's not going to be possible. There is no magical method of "preserve my changes and transfer them into the new version automatically". The way to go here is doing a diff between the edited version and the update, and integrating the changes in the actual source files.
The bottom line is, if you manually edit a third party plugin, you're in for manual review (and possibly rework) once an update takes place. That's why it's usually not a good idea to extensively modify third party plugins.
Well in fact, yes! There is some kind of way.
You have to remove the to be modificated plugin's original actions/filters and then add your altereted actions/filters.
If the desired plugin is even coded in OOP you can just inherit the whole class and rewrite the wanted functions (oh sorry: "methods". we're talking about OOP ;) ). Instantiate your inherited class and rest as above.
Maybe there are better ways! I already search for a method so that the original class won't even get loaded but our altered one instead but I'm no John Carmack.
I am creating a site which will have a "desktop" and a "mobile" theme. I've two theme packages for this site: mysite.theme and mysite.mobile_theme. The mobile_theme is a stripped down version of the desktop theme, with new views and a reduced set of viewlets. I want to switch between these two themes based on the URL the site is visited from (i.e., mobile.mysite.com vs. www.mysite.com).
As the mobile and desktop themes will share a lot of code, mysite.mobile_theme descends from mysite.theme in the following ways:
1) mobile_theme GS skins.xml has a skin path based on the old theme, so the desktop theme's CSS etc. is used:
<skin-path name="mysite.mobile_theme" based-on="mysite.theme">
2) IThemeSpecific marker subclasses the original one, so views which I'm not overriding for the mobile site fallback to the ones in mysite.theme:
from mysite.theme.browser.interfaces import IThemeSpecific as IBaseTheme
class IThemeSpecific(IBaseTheme):
"""Marker interface that defines a Zope 3 browser layer.
"""
3) I have registered various views in mysite.mobile_theme to override the certain ones in mysite.theme.
4) I've used generic setup to have different viewlet registrations for each theme.
At this stage, if I select mysite.mobile_theme in the "Default skin" option portal skins->properties, everything works correctly: my views are used and the viewlets settings from the mobile_theme's GS profile are picked up correctly. So it appears the theme is set up correctly overall.
As mentioned above, however, I would like to swap between these two themes based on URL.
First, I swapped the "Default skin" back to "mysite.theme". I then created an access_rule in the root on my Plone site, roughly following these instructions to select a skin based on URL. It's at plonesite/access_rule and is set up as the access_rule for the plone site:
url = context.REQUEST.get('ACTUAL_URL', '')
if 'mobile' in url:
context.changeSkin('mysite.mobile_theme', context.REQUEST)
else:
context.changeSkin('mysite.theme', context.REQUEST)
I've also tried using context.REQUEST.set('plone_skin', 'mysite.theme') rather than calling context.changeSkin(...).
Using this setup, the viewlets displayed change correctly based on the URL I've used--so it looks like the skin is being changed at some point--but the mysite.mobile_theme's view classes/templates are not being used in preference to mysite.theme's. In summary:
If I call from a URL containing "mobile" I get mysite.theme's views, but mysite.mobile_theme's viewlet registrations.
Otherwise, I get mysite.theme's views and mysite.theme's viewlet registrations.
It looks like I might have to hook into the traversal mechanism to change it so if "mobile" is in the URL, the mysite.mobile_theme's views registered against its IThemeSpecific are chosen rather than the mysite.theme ones, but I'm not sure this is correct nor how I'd go about this.
Can anyone give me some pointers?
UPDATE 3hrs after originally asking
To answer my own question (which I can't do for another 5 hours due to SO's rules):
"""
It would appear that you must patch much lower down in the stack to make this work. I looked at how it was done in plone.gomobile, and they monkeypatch the skin choosing code itself. See:
http://code.google.com/p/plonegomobile/source/browse/gomobile.mobile/trunk/gomobile/mobile/monkeypatch.py
"""
You could use collective.editskinswitcher. Its main use case is to use the Plone Default theme on say edit.example.com and My Custom Theme on www.example.com. You can probably tweak its property sheet to fit your use case though.
Since the 'mobile theme' use case is fairly common I would accept patches to make that easier; or I may work on that myself some time.
(BTW, note that there is a fix-browser-layers branch that may help when you miss some items that are registered for a specific browser layer; seems ready to merge except that I would like to add some tests first.)
I have done this in some prototypes of mobile themes. Please consider thoses two addons not ready for production:
https://github.com/toutpt/plonetheme.jquerymobile
https://github.com/toutpt/plonetheme.senchatouch
The related code is:
The patch on browserlayer to mark the request with my theme layer: https://github.com/toutpt/plonetheme.jquerymobile/blob/master/plonetheme/jquerymobile/layer.py
The patch on plonetool to add ##mobile on every content page: https://github.com/toutpt/plonetheme.jquerymobile/blob/master/plonetheme/jquerymobile/PloneTool.py
The patch on skintool to tell skin layer is this one if browser layer: https://github.com/toutpt/plonetheme.jquerymobile/blob/master/plonetheme/jquerymobile/SkinsTool.py
If you are using plone.app.theming, you also can switch your diazo theme: https://github.com/toutpt/plonetheme.jquerymobile/blob/master/plonetheme/jquerymobile/transform.py
Do I understand correctly that at the mobile URL your skins are correct, but your Zope3 Views are not? Which makes sense to me, since the view classes are based on Interfaces. In the same code above, where you use context.changeSkin, add:
from zope.interface import alsoProvides
alsoProvides(context, IMobileView)
and have your view zcml specify for ... IMobileView
[edit: on second thoughts, this really should be what happens when you change the skin - where the additional inteface will be your "IThemeSpecific" - so I'm not sure what's at play here, but it wouldn't hurt to try alsoProvides(context, IThemeSpecific)]
We primarily use an ASP.NET environment at work. Right now I'm building an application which uses "Modules", which is just a UserControl, with its' Javascript right in the control, and a link element to the stylesheet for that control. I want to keep it modular, and would like the style of this control to be independent from the markup/javascript.
So I'm wondering what the preferred method of doing this is? Obviously if I didn't want the "theme" functionality I'm after, I could just use style tags at the top of the control. Right now I have a link element, as I said, and this isn't proper I don't think.
Does anyone have any preferred methods, and if so, what and why?
I considered ASP.NET themes briefly, but the idea of these controls are a little different, I think.
It's basically a shopping cart system. I don't want to get into it all, but we are using a really neat security system, and we don't want to use a premade shopping cart. I'm developing a set of controls that can be dropped on a page, for instance in SiteFinity (which is the CMS system we use) or for any other project we might have. Normally I would compile these into a DLL so we get ACTUAL controls we can drag & drop from the toolbox, then I could use internal "generic" styling and allow for any additive styling someone might want, as well as supplying a few fancier styles as well.
This is the first time I've ever done this, or really the first time anyone in our shop has done this either so I'm kind of figuring it out as I go. I might be pretty far off-base, but hopefully I'm not.
Right, the idea for this is to have a "theme", which is really just a CSS file and a jQuery template. I have them named the same, and have a Theme property on the usercontrol to set it.
When these controls are finalized, I might refactor the javascript to a RegisterScriptBlock on the code-behind, but for now they just in script tags on the control itself.
What prompted this question was DebugBar for IE, giving me warnings that link elements are not allowed inside a div. I don't much care, but after thinking about it, I had no idea how to link to the css file without doing that. I considered very briefly having an 'empty' link tag on the master and then setting THAT in the code behind on Page_Load of the UserControl, but that just seems like ass.
I could use #import I guess but I think link tags are preferred, correct?
It sounds like you're rolling your own theme engine... why not use ASP.NET Themes?
If you're determined to do it yourself, here's some code from the CssFriendly project that may be of interest to you. (I think it should be ok to post the code as long as I cite where it's from.) The .css files are flagged as Embedded Resource and the code below is used to include them as needed.
string filePath = page.ClientScript.GetWebResourceUrl(type, css);
// if filePath is not empty, embedded CSS exists -- register it
if (!String.IsNullOrEmpty(filePath))
{
if (!Helpers.HeadContainsLinkHref(page, filePath))
{
HtmlLink link = new HtmlLink();
link.Href = page.ResolveUrl(filePath);
link.Attributes["type"] = "text/css";
link.Attributes["rel"] = "stylesheet";
page.Header.Controls.Add(link);
}
}
I think what you're supposed to do is use Page.RegisterScriptBlock to register your script blocks. Best-case you shouldn't have them inline in your ascx inside script blocks. This isn't always possible, but theoretically it's the best way.
Ideally your styles should be separate from your markup as well. Your controls can have classes and IDs, but your style is based on your application and not your controls. Controls can theoretically be used in other applications where you might want a different style.
It depends on how big your app is, and whether or not it's dependent on Themes elsewhere, IMHO.
If you're using a .skin file, or if the majority of the app is also plugged into the theme, you might as well go with the theme.
But if it's just a few styles you need, you're better off to set the stylesheet manually, keep your css file external (inline styles are a PITA and defeat one of the core purposes of css).
In either case, don't forget to set the CssClass attribute on your controls.
To be proper I would have an import.css file - structure the naming of the classes to follow your controls, and import the styles within the header of the document.
If you have a module called "30DayPricingCalc" then you could name the classes/id's:
30DayPricingCalc.css
.30daypricingcalc_main_content
{
...
}
Also if you haven't I would setup a list of generic reusable styles to save you room. Since elements will allow multiple classes per object.
Also, link tags matter a lot less now than they used to. we're well past support for IE5 generation browsers and IE6 supports the #import tag.
Cheers!