After a little research it turns out that themable custom css in sharepoint should be placed either in the styles library or in the layouts folder but always in a language dependant folder structure like /<LCID>/Styles/Themable
I would like to replace the target folder of the css files in the package with the primary language of the server where the solution is deployed.
For Example, I want to change
<TemplateFile Location="Layouts\1031\Styles\mygrid.css" /> to
<TemplateFile Location="Layouts\1033\Styles\mygrid.css" /> when the solution is deployed.
A solution to this problem would also help for other files which have to be put in the Layouts\LCID directory such as theme xmls themselves.
Thanks for your help!
I understand you have only one version of css file (language independent) and you need to put it into the right folder during deployment.
The solution can be to get rid of the language specific folder schema and put your css file into Layouts\YourProject folder and then register the css file via CssRegistration control on your master page, web part or control.
See also my related question.
Related
I want to edit the style of multiple applications inside my workspace with the less amout of effort. What I mean by "edit the style" is font size, background color, position, etc.
My idea was creating a CSS file at "Static Workspace Files" with the classes I want and applying them to the apex items needed. Applying this in a region for instance:
*.font16{
font-size: 16px;
}
The problem is: modal pages can't find the file, which is not a problem in nomral pages. I'm using the path '#WORKSPACE_IMAGES#styles.css' in the page "CSS > File URLs" setting.
I'm not sure if this is the right approach, maybe I should edit Themes or Templates, but since I'm pretty new to Apex I chose CSS for familiarity.
Application Express v20.1
That's what Static Workspace Files are meant for, files that can be used by multiple applications in the same workspace.
The easiest approach for this is to create a CSS, like what you've done.
You don't need to inlcude the file in every single page, which would become a maintenance nightmare eventually.
You can simply include the file at the application level:
In Share Components, go in the User Interface Attributes and include the file under Cascading Style Sheets.
I usually have one global.css file (as a static workspace file) for anything common to all my apps and one app.css per application (as a static application file) for things specific to the current application.
Note that application exports will contain the static application files, but they will not contain the static workspace files. You will need to export/import them yourself.
Did you try Theme Roller? Run the page, it is down in developer's toolbar.
I'm trying to upgrade a Plone 3.3.5 server to 4.3.6. However, when I update the site, I find that the CSS for the site is not carried over. If I go to my CSS Registry, I find that almost all of my CSS is producing the (resource not found or not accessible) error.
My confusion seems to be in how Plone locates and links/imports stylesheets in general as Plone seems to be loading virtually none of my CSS and pretty much giving me raw HTML in the browser. I'm assuming the CSS registry is loading CSS from the buildout-cache. With this assumption, an example stylesheet that I'm targeting is located under:
Plone/buildout-cache/eggs/Products.NuPlone-1.0b3-py2.7.egg/Products/NuPlone/skins/nuplone_styles/base.css
When the CSS Registry failed to load this, I noticed that some CSS was being loaded in via handles like this:
++resource++tinymce.stylesheets/tinymce.css
But this format doesn't work with base.css and others.
So my question is, given I've got a new product installed with some CSS included in it, how do I get Plone to target said CSS?
For resources inside "skins" FS folders, the way to register on portal_css tool is to simply provide the filename, so simply put there base.css.
If this is not working probably the nuplone_styles skin folder is not registered properly in the portal_skins tool.
So go to ZMI --> portal_skins --> click on "Properties" and check the following:
what theme is used? You must probably switch back to NuPlone (but I'm not sure if it works on Plone 4)
is the nuplone_styles folder in the list of CMF layers of the used theme?
Please note also that adding the nuplone_styles layer to another theme is not a good idea. Please think about copying CSS you need in the custom directory.
This is not an answer, but some additional explanation, not fitting in a comment:
The "old" way to include style-sheets via skin-folders, requires to specify only the file-name, not a full path, and will be found by traversal, meaning the first found file with the according name, will be taken. In case of several files with the same name, the order of skins matters.
The other way is to register style-sheets via a browser-package, to have an unambiguous path to a certain file, they must start with +++resource++.
I am doing a small audit of a fairly robust ASP app and CMS for a client (does a good bit more than a regular CMS) and started looking into the code. (edit: This is for a quick overview prior to engaging a full fledge ASP shop.)
I am coming from a background mainly in PHP, Node.js, and Ruby but when I look at the layout of the directories and files it looks horrible. It reminds me of old PHP 4 apps with files all over the place.
My question is, is this still good coding practice in ASP? I expected to find a much cleaner/easier to understand structure with a more custom app like this. Much like the Rails/Zend/etc of the other languages. Here is a screenshot of a few of the files from the webroot.
A side question would be, are there better ways to organize files in ASP? I have not coded with ASP in 6-8 years, and it was still not very much I used it for.
This isn't ASP, it's ASP.NET; I also note it's WebForms, not MVC, which has very different layout.
Anyway, the directory structure is a mess, it's horrible. Here's what's wrong with it:
Unholy mishmash between static HTML files and ASP.NET webforms files
Code files (e.g. contact.aspx.cs) are present on the server when the application looks to be compiled (because it has a bin directory), so they shouldn't be there at all.
There is no consistency in folder and filename casing. Some are all lowercase, others are TitleCase.
You appear to have duplicate folders, what is the difference between "Images" and "img"?
What on earth is "missing" and "layouts" for?
Duplicate, disorganised files index.html, index1.html, etc.
Then there are a few other concerns, but those are down to developer preference:
Generally, projects only have one or two MasterPage files, so it doesn't make sense for them to be outside of the root folder. I put my *.master files directly in the root of the application.
Images related to a stylesheet should be placed in the same directory as the stylesheet rather than in a sibling folder (I'm assuming the images referenced by the stylesheet in the "css" folder are actually located in "img"). This is bad because it complicates the CSS file (as it has relative paths inside it) and makes your application more brittle.
Fonts seems to contain font files, again, referenced by your stylesheets. They should all go under a single "styles" folder.
Any image "content" (i.e. <img src="" /> elements), not images used in stylesheets, should be kept separate from stylesheet images, I'm assuming this why you have the confusing "img" vs "Images" folders.
As for the correct way to do it, ASP.NET WebForms does not lead itself to tidy, well-organised applications. Because each (non-rewritten) URI corresponds directly to an *.aspx file it means the filesystem layout has to match the website layout. I'm afraid there isn't much you can do about it unless you implement ASP.NET Routing.
I also suggest eliminating all of your HTML files and converting them into ASPX files that make full use of UserControls and MasterPages as appropriate.
We have a ASP.NET solution using images, css and .skin files with in the App_Theme/{selected theme}. The themes today contains many, many files and images and for a customer theme we add a new folder to the App_Themes and copy all files to the new folder and make the 10-200 changes on images, skin and css's.
The issue here is that the default theme, the one we normally have when we develop, evolve's and grows making theme customer theme out of date. So when an upgrade comes we have to go through all files looking for changes and hopefully finding them all. Sometimes we miss things that are really important.
The perfect solution would be to have a base theme that contains the base css, skin and images. And when we add a new customer theme we only tell the system what has been changed, what css-selectors to override and what images to use instead of the images from the base theme. In my understanding, if using the normal ASP.NET theme functionality in App_Themes folder, you can only have ONE theme and not a BASE theme and then say a DeliveryCustomer-theme that has a different background and some other images that the solution shall use instead of the ones in the BASE-theme.
Does anyone have some guidelines to solve this in a maintainable way for the future. I seen that people override the App_Theme path to make it work with custom skins.
thanks!
Use the concept of a base theme like you described. Pull out all common CSS rules into another file, let's call it base.css.
Take base.css and all the images that are common, and put them in a folder outside of App_Themes, and just include the CSS file like you normally would any other on your master page.
<link rel="stylesheet" type="text/css" href="/styles/base.css" /> <!-- Note this isn't in app_themes -->
Then, make sure your CSS files in various themes only specify the delta for your styles.
Ok, so here is how I'v done it know.
I have created a Default theme that is the original theme with all the css-files, skin-files and images that is needed, and that is alot. This theme is in the App_Themes folder. Them I'v created a new folder called ThemeSkins next to the App_Themes folder. In this folder I have all the new skins in different folders. The folders name is the name of the new theme that one want's to have. In each of the skin folders there are css-files that contains only the selectors that I want to overload. There is also images that I want to replace.
I have created a ThemeCreator tool that does three things:
Remove all themes except the Default theme in the App_Themes folder. This is to only have one main theme to work on for the developers. There will still be work that needs to be done in the ThemeSkins, but the overall work load will be minimal.
Next the tool looks at the folders that is in ThemeSkins and creates a folder under App_Themes for each skin with its name. Then it copies the Default theme into all the new skin folders that it just created.
The last thing is that it will merge the skin specific files into the newly created skin under App_Themes and let the user know what files were added just for information. The tool adds a prefix, "z_", on all css-files so that these are loaded last of all css-files and there for will overload the default selectors.
The thing that remains is to update the skin-files, so far, no customer has needed changes in these files. But when they do, I guess I just add a skin files and have to update the default in a automatic way since the skin-markers can't be overloaded as css-selectors can.
This works really smooth and gives us a nice and lean way to work with skins on our themes.
Any one got a better idea how to get the same result? the major issue using ASP.NET themes are that you can't use a default theme and then just apply skins to it without using the shape and color attribute in the skin-files. This is not recommended as the skin files will copy out all attribute to all the places that they are needed in the markup and not just reference them as css-classes do.
My work has recently deployed Sharepoint and I'm currently trying to get to grips with it.
I'd like to be able to completely customise the way my blog looks but I have no idea where to start. I had a look through Microsoft's developer site and it does look like they have a lot of stuff there but it all seems to be pitched at a much higher level than I'm at.
I'd consider myself pretty experienced with CSS and web development, does any of this translate into sharepoint? Can I make a new CSS file and upload a bunch of images into a store and change the look of my 'site' that way, or is it a lot more complicated?
I realise this is a little vague, but I'd really appreciate some pointers to a "getting started with making sharepoint not look sucky" guide or an example of the sort of thing I can actually hope to achieve. Hopefully my question isn't too high-level.
Thanks
Use SharePoint Themes, their installation is tricky at first but once you get a good development environment you'll be able to test modifications in the traditional "save css file, press F5".
Themes have these pros:
Do not need sharepoint designer
Do not need to change masterpages and deal with (un)ghosting (the sum of all fears)
Can be applied to one subsite and have other subsites with different themes (see gl-applytheme in google for mass application of themes thru many subsites)
and these cons:
You have no access to HTML changes, for that you need masterpage love (I dont think thats a con, its a limitation that usually exists in different scenarios and also makes you improve your css skills so much in the css-zen-garden way)
Themes once applied, go to the server memory -- meaning that if you change your theme folder you need to recycle the application pool, apply a different theme and apply your theme back to see that one pixel border you forgot to put in the footer. But for that specific problem I have a solution below:
After you do your "theme setup" you'll be able to only work with CSS and images and be free to overwrite any class in SharePoint using your favorite Developer Toolbar/Firebug addon to find what you want to change.
In the folder c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\THEMES create a folder named THEMEDEV
Inside the new folder, create a file called theme.css and another called THEMEDEV.INF
Inside the .INF file, paste this:
[info]
title=THEMEDEV
codepage=65001
version=3.00
format=3.00
readonly=true
refcount=0
[titles]
1033=THEMEDEV
now open the c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1033 folder (1033 is your language code, thats the default for english installations)
edit the SPTHEMES.XML file
below <SPThemes ...> insert:
<Templates>
<TemplateID>THEMEDEV</TemplateID>
<DisplayName>Development Theme</DisplayName>
<Description>Development Theme.</Description>
<Thumbnail>images/thnone.gif</Thumbnail>
<Preview>images/thnone.gif</Preview>
</Templates>
now edit your theme.css file, add an import to your favorite CSS development folder:
#import url('file:///C:/SharepointThemes/Theme1/theme.css');
Save everything, open your sharepoint: Site Actions => Site Settings => Look and Feel => Site theme => choose your Development Theme and hit Apply
If everything worked, you can now edit your C:\SharepointThemes\Theme1\theme.css in your favorite editor, save it with something like
* { color: red !important }
and see the changes on your site.
Something also important when developing themes: do not create folders to store, say, your images, use everything in the same folder and in the code itself use a relative fashion, like background: url('image.png')
ps1: Only you can see changes you are making to your sharepoint site due to the file://c:/ folder, if you need more people to see the changes during development, setup a network path that they all have access, the rest is the same.
ps2: Keep in mind this is a development environment, to make your theme a live theme you need to create another one to store all the content used to change your site's visuals.
The process is similar to the one creating the THEMEDEV one, just put a pretty and consistent name across all configurations (Folder name, .INF name, .INF contents, SPThemes.xml node contents), paste all your images in the Theme's folder and replace the theme.css file with your content.
Edit1: Reading your comment above, now you have a "editing + uploading to FTP" type of setup :) this works for MOSS and WSS by the way (even if you don't know the difference). For more info on customizing sharepoint, I made a post yesterday about more options:
Sharepoint: How to remove default core.css reference?
I like to always use this post as a starting point for SP branding: http://erikswenson.blogspot.com/2008/10/functional-sharepoint-branding-style.html
It depends on whether you're talking about a WSS 3.0 site or a MOSS site. WSS 3.0 sites can be customized using themes. Customizing MOSS sites is a little trickier, although you can add a SINGLE custom CSS style sheet via Central Admin - in this case, your custom files, images, etc., would be deployed as a Feature.
The best explanation of how this works that I have come across is the six part series on the cleverworkarounds.com site.