Has anyone got an thoughts on how to handle theming a WSS site for a single user who is visually impaired ... she uses high contrast settings for Word, etc.
But still leave the usual theme for everyone else
That second link on choppen's answer is one of the craziest/most clever workarounds I've ever seen haha.
By all means if you don't have much programming knowledge, use that idea.
Onto coding, you have different ways to achieve that, but without going into features and overriding sharepoint's render engine / site definitions, HttpModules and MasterPages sound more reasonable for this, MasterPages are even easier.
Have your code hooked in the Page_Load of the MasterPage and check if the SPContext.Current.Web.CurrentUser.LoginName is your user and then append to the head object a secondary theme link: <link href="/highcontrast.css" etc />
Remember if you put .NET code in the MasterPage you need to allow it on the web.config with the PageParsePaths. With a HttpModule override the Page_PreInit event in the Application_PreRequestHandlerExecute and you should be good.
These posts may give you some ideas:
http://sharepointmakesmecry.blogspot.com/2009/01/sharepoint-audience-targeted-branding.html
http://sharepointmakesmecry.blogspot.com/2009/02/user-centric-themes-sharepoint-branding.html
If the layout is done through css create a custom stylesheet for her and configure her browser to use that sheet for the specific sharepoint site. The following link may help.
http://www.microsoft.com/enable/training/ie6/formatpage.aspx
Related
I look for a tutorial, help or an example that tells me what I have to do to write a grid element like 2-colums in basic typo3 (v9) with fluid but no other extension like gridelements, DCE, Templa Voila, etc. I want the same gridelements can do but I dont want to be depended to this extention and move it in my own site extention.
I tried the same with normal content elements (CE) like here:
https://docs.typo3.org/c/typo3/cms-fluid-styled-content/9.5/en-us/AddingYourOwnContentElements/Index.html
But how can I nest a CE in a CE? And how can I do this by drag&drop in the backend?
You can't. The page module doesn't support nesting
You can't nest CEs in a CE. On database level this would mean that you have to make a tt_content record a subrecord of a parent tt_content record. You run into several problems, basically the multilanguage support will be broken and the shortcut element does not function as you will expect it to. That is why the extensions "gridelements" and "mask" exist.
I integrated the gridelements configuration into my sitepackage. So I do not need to bother anymore with it.
Just for your info:
There is now an initiative that works on integrating this functionality into the core (Structured Content Initiative, https://typo3.org/article/a-structured-content-initiative/). Stay tuned to it.
There is nothing special about providing Gridelements via external files, since it's based on TSconfig, TypoScript and Fluid. That's why there is not that much about it in the documentation, since it's the same thing you would do with any other kind of sitepackage. The TSconfig and TypoScript parameters are already explained there, while the Fluid would be up to you anyway.
To have a kind of kickstarter just take any extensions providing Gridelements layouts as an example. A very popular one would be bootstrap_grids, which can be found in the TER or here: https://github.com/laxap/bootstrap_grids
You don't necessarily need the flexform controller of that extension, but the Configuration and Resources folders, show you how to configure stuff and you can see how that is included via ext_localconf.php
There are even comments i.e. in the TSconfig files to explain what is possible there and how to handle i.e. mixed environments with record and file based setups. Although it would be recommended to go for files.
You would at least have to add the necessary backend rendering methods to a draw item hook, that will modify the preview of the container element.
So basically you would have to rewrite everything that DCE, Flux, Gridelements or other similar extensions already do.
Which brings us to the question, why you want to avoid those extensions, since especially those three are well known, widely spread, well supported and available for currently supported TYPO3 versions.
I am kind of new to SharePoint. I am learning it on the go and learned about the concept of pagelayout and publishing features on the site. But I am not really 100% sure what is the difference between a WebPartPage, SitePage and PublishingPage. I kind of know what all these pages be used for, but what I not get is: why do they need to separate all these pages?
I think we can just get a publishing page and have all the feature there including webpart and everything else (with our choice of PageLayout). However I dont see a way to use a pagelayout on a particular SitePage.
Is there any particular reasons for using either one of them? Even though it seems like one of them can serve as all of them?
You should use page layout when ever you know the page structure. For example you are running an online news paper. You want to show the news to the users into three columns. First column is for menu, second column is for news content and third column is for advertisements. Now in your daily usage this layout is common. So you can use this page layout for entering the news. After creating the page layout you can make it as a default to your pages. Page layout is nothing but the structure of a page simply!!
A webpart page does not have a field for content directly on the page like a SitePage has. A Publishing Page is like a SitePage, but requires extra fields for dealing with the publishing extra features.
Using a single layout for all three risks being confused as to why one page does not work the same as another when it has the same layout (the difference would be the underlying features are different.).
I will make a comparison with cars. There are three type of cars, each is better suitable for a certain purpose: tractors for farming, buses for public transport, light cars for private transport. You could use a tractor for all the purposes above but it's not ideal.
"One of them can serve as all of them". This is not true in their current implementation. I'll give you one example: prefer Web part pages against Publishing pages to better control content added by contributors in an intranet. There are many other examples.
I'd like to have a hierarchical URL structure in my site. Something on these lines:
tutorials
javascript
jquery
There should be a page at each level (tutorials, tutorials/javascript and tutorials/javascript/jquery). Obviously, using Taxonomies would help me organize my content in this manner, but how do I get Autoroute URLs generated for this scenario?
Bertrand Le Roy made a comment on this SO answer about using taxonomy terms as pages but it still doesn't seem to create the right URL structure for me. Am I missing something? Is there something specific I need to configure or enable to make this happen?
Are there any other approaches I can look at?
I was thinking of specifying the default route as something like {Content.Fields.Page.TaxonomyName}. It appears that this isn't really possible right now according to this bug report.
Here's an approach that seems to work without having to use taxonomies:
I added a Content Picker field called ParentPage to the Page content type and updated the Page's Autoroute default to
{Content.Fields.Page.ParentPage.Content.Path}/{Content.Slug}
Now in each page I get to pick what the parent page is and the URL is constructed how I expect it. From what I remember of working with WordPress, I think this is pretty close to how it allows you to do this parent page thing, too.
You know, the publishing suite offers other content than forum. for example blogs and also some custom content
i know how to add articles/widgets to the page itself, but how do i add such a thing into a forum secion?
for example, on the left column i would have forums and on the right column i would have some news reader widget
could someone help?
Maybe it is enough for you to enable the "forum sidebar" in the admincp.
admincp->Settings->Options->Forum Sidebar and Block Options->Enable Forum Sidebar=YES.
Now you can add custom blocks with HTML and PHP.
For vBulletin 3.x, the solution is to edit the appropriate templates (FORUMDISPLAY, SHOWTHREAD, etc). I can't be much more specific than that, I'm afraid, since the exact details will vary depending on what kind of modifications you've already made to your templates and the exact details of the widgets you wish to insert.
When developing web parts in SharePoint can I inherit from the existing web parts and override their methods?
Or do I always need to start from scratch.
Many Thanks
If they are not sealed, you can inherit from them. In practise, It might work or not depending on how the web part you want to extend.
Most (all?) OTB parts are sealed.
A new toolbar with icon/no buttons sounds more like a design solution. Place the topnav placeholder in a invisible panel at the bottom (so page doesn't crash) and modify the rest visually (css+firebug) . Assuming I am not misunderstanding what you mean.
Its pretty easy to get started with webparts, http://blah.winsmarts.com//2006/05/14/writing-custom-webparts-for-sharepoint-2007.aspx should show you how. From there you should be able to write an RSS reader easily.