Watch out for the black helicopters and tin foil (-;
--
_____________________________________________
SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
"Warning - Using the F1 Key will not break anything!" (-;
To find the best Newsgroup for FrontPage support see:
http://www.frontpagemvps.com/FrontPageNewsGroups/tabid/53/Default.aspx
_____________________________________________
| Thank you for your reply. Again, you are not reading my posts very carefully.
| Did you ask me to let you know if you were rather obtuse?
|
| What I was hoping for was a reply from you that went into serious
| consideration of exactly what can be accomplished, rather than vague
| reference to methods that are suspect at best.
| We need to know things like where has Microsoft clearly documented the way
| to safely manipulate tables on a shared server WSS account, beginning with a
| list of the styles and tables used and a picture showing the various page
| layers. For now, can you assist me with understanding more about SharePoint
| potentials in the shared server market. I am interested in the shared account
| environment becasue the vast majority of SharePoint accounts are on shared
| servers. Office, SharePoint and the whole kit and kaboodle are going that way.
|
| For example, how can we get around the V2 lazy server syndrome? It is with
| good reason that the WSS servers simply ignore any style sheets put up on
| shared accounts and use the portal servers ows.css. Remember that the WSS
| portal can be configured to "ignore any other styles" with a single click.
| This option used to appear on the step 3 page of the server setup. It is a
| lazy boy way to avoid configuring the server cache for WSS and is documented
| as such. I remember once Kirk kindly configured my server, but forgot to
| disable the switch, then remembered too late he had to configure this
| improvement for each account on my server, restore certain backups and so on.
| Oh gawd! SharePoint V2's ows.css is designed to allow "easy" style
| restriction. I think it would be useful if Microsoft totally disabled this
| easy switch where the server is deploying to a shared hosting environment. If
| anyone edits ows.css this is not a problem. The server should by default
| reset itself and its templates every half hour. The portal cache should
| isolate each shared account in a seperate directory so when the ows.css
| resets, then each shared account's styling is not screwed. Only problem is,
| servers DO NOT WANT to take 15 minutes to configure the cache properly for
| each account unless they are providing a dedicated service. Lazy server
| policy, Stephen, is going to make your referals to
| sharepointcustomization.com a trip into nonsense unitil that damn "ignore"
| switch is eliminated. Is there a real (cost attractive) solution? Each shared
| account needs its own "virtual style sheet interface" in an external
| environment. Well, wadda ya know! The upcoming version of SharePoint does
| just that. For now, any server host's shared WSS must also implement style
| restrictions. This is because the v2 portal server will damage ows.css unless
| the "ignore" switch is used with so many lazy boys out there. Okay? I
| understand where you are coming from Stephen. Now try and understand where I
| am coming from...
|
| PLEASE READ what I have to say below.
|
| As I noted previously, when I create my own themes locally and apply them to
| my WSS sites, the formatting I want remains. For a period of time, but is
| always corruped by the server even though the personal theme is not
| endangering ows.css, the lazy boy policy is in effect. Corruption usually
| begins after a few days with pages appearing quite messed up after several
| months. This corruption progresses with equal speed on sites being
| continually authored and on sites that are left to their own devices. Each
| site demonstrates the corruption in entirely unique ways. Don't ask me why.
|
| My WSS Host has provided the staus quo collection of Microsoft prepared
| theme alternatives and these can be applied without corruption. On my host
| (FWHN) certain packages built into FrontPage won't work because the techs
| have been more interested in enabling themes than packages. Note that some
| so-called templates downloaded from Microsoft (like the Legal Document Review
| Template) actually setup like packages on the server and will be corrupted
| until the techies unglue their asses. However, most of the templates from
| Microsoft work fine.
|
| Thus far the only practical way to respond to customer requests for changed
| site appearance is to style page elements individually (page by page) with a
| style longevity of a few weeks. These isolated style provisions are menacing
| to the portal as it expects no styling outside ows.css. Like the personal
| themes. they gradually decay.
|
| However, if a thicket is turned into a template and copied around the site
| with its "individual" style provisions the crap hits the fan. Curiously, what
| you get is not a revision to the ows.css settings. Nor do you get any
| immediate adjustment of the style provision (unless Kirk has been playing the
| predator, and manually restircts your sites use of a fFrontPage style
| component on the individually styled page, like, say, interactive button
| ms-jewel, etc, lol). What you get is an adhoc corruption of a global style
| class. For example, where i manually adjust default body font on a page to
| one size less than the ows.css setting, the entire site's default body font
| changes to Arial Black 14 pts bold. This change to site style is permanent.
| It even crawls through the Net axis into windows XP to pollute other
| unrealted sites on my local machines. Kirk reports that there has been
| absolutely no change to the ows.css and "no indication of anything amiss". No
| virus or worm here; a revision of the local Net framework. To repair, please
| reboot and reinstall disc, windows, and Office. Half an hour later, exactly
| the same symptom.
|
| As long as the WSS site retains the orginal tables (with style and class
| ID's in tact), the page can be adjusted by reshaping tables. That is as far
| as you can safely go on a shared lazy boy server. PLEASE! No more sharepoint
| customization.com nonsense. Get serious and help us out with maintaining the
| static, I mean really STATIC ows.css style provisions while satisfying
| customer requests for customization.
|
| There is far more going on than any WSS user like myself can comprehend.
| The way that Microsoft has cofigured WSS around ows.css generally disables
| any safe and attractive styling with FrontPage on a shared server account.
| However, customers will never stop requesting changes in page appearance. And
| most customers cannot afford a dedicated server.
|
| SharePoint in its current V2 incarnation is as useful in terms of design as
| an Interact receipt. Thankfully it borrows some design features based on
| tradtitional website design, like color (though it is unwise to change any
| colors supplied by templates. Why in God's name Microsoft introduced the
| "ignore" switch or enabled FrontPage access to any server hosting a shared
| ows.css is a mystery to me. But that is where we are!~
|
| Stephen, you should know that I am pushing the limits of the sharePoint
| design container because there is always something new to check out. Your
| referencing me to impossible solutions is indicative of experience
| contracting portal adaptation. My conclusions are based on numerous tests in
| a labile WSS shared server account. Where balanced user input is requested, I
| offer the following for any Studio 9 readers and contributors. In addition to
| the above consideration of a useful end to the lazy boy switch.
|
| While ShjarePoint version 3 offers to remove much of the obvious style
| stagnation included in version 2, the upcoming Expressions Web Designer is
| challenging Dream Weaver with a superior style manipulation interface. Some
| consideration should be given to enabling market centered style capabilities
| for the shared server package. This would help designers like me to step
| customers through cost relevant improvemnts in appearance that avoid jumps
| from a $15 shared account to a $150 dedicated setup. This would help to
| corner the numerically superior mass of low end users. This would also
| greatly satisfy captain Kirk!
|
| Conclusion
| Our primary host technician is "PREADATORY" by his own admission. Predation
| consists too often of incidental blocks of non-threatening page style such as
| interactive buttons. This interference is way out to lunch. Most of the
| boundaries I explore are not implementing any forced change to the ows.css
| "total environment" as it is called. WITHOUT EXCEPTION, unless something
| unexplored appears, and that is now not only unlikely but impossible, I am
| engaging labile frontpage styling of individual pages to satisfy customers.
|
| When I began my explorations, FWHN had not even implemented the second
| incarnation of the WSS resource kit, so Kirk may have been somewhat rocketed
| out of his seat. I felt justified jolting him, having ID'd him as a lazy boy.
| Sorry. I had to walk Kirk through server recovery using the 4-clicks method
| [lol]. I would go elsewhere if Kirk was not lazy. Kirk is diligently
| considering how style-ability (if you will) can be packaged in the host
| market. As noted, the vast majority of SharePoint users need coaxing to
| transcend cost-effective basics included with the shared server environment.
| It seems Microsoft is up to the challenge of extending the SharePoint
| product. Can you dig that?
|
| Why do you never go there, here in this place? And when will the shared
| server designers like me get their own dedicated forum from Microsoft, here
| in this "knowledge" place?
|
| "Stefan B Rusynko" bellowed:
|
|
| > You can not modify the server based version of Ows.css
| > - it affects all WSS users on the server
| > - your host is not predatory
| > (he is correctly protecting All users on the site)
| >
| > I have no idea what you mean by "I am [strategically] applying style to Windows SharePoint Services sites
| > using many methods detailed in Microsoft Press publications for WSS"
| >
| > The correct way for you to apply a customized equivalent of OWS.css styles just for your WSS site is for you to create a local
copy
| > of the style sheet in your site and just create a style sheet link to it for all your pages
| > - As explained in say
http://support.microsoft.com/default.aspx?scid=kb;en-us;825495
| > - and using the guide at
http://www.sharepointcustomization.com/resources/tipstricks/wss_cssguide.htm
| > --
| >
| > _____________________________________________
| > SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
| > "Warning - Using the F1 Key will not break anything!" (-;
| > To find the best Newsgroup for FrontPage support see:
| >
http://www.frontpagemvps.com/FrontPageNewsGroups/tabid/53/Default.aspx
| > _____________________________________________
| >
| >
| > | Stefan B Rusynko,
| > |
| > | You have not answered my question. Its not that the host has the roles set
| > | wrong. The host is deliberately tracking my styling efforts and resetting
| > | roles to block the methods I am using to style my sites using FrontPage 2003!
| > |
| > | My question is very simple. Is there a way to get past predatory host
| > | obstruction of basic FrontPage functionality?
| > |
| > | I am [strategically] applying style to Windows SharePoint Services sites
| > | using many methods detailed in Microsoft Press publications for WSS.
| > | Everytime I get something working, my host disables my code and the method I
| > | used to apply the style to the site. Kirk Duanes at Front Pages Web Hosting
| > | tells me he has to do this beacuse I am on a "virtual shared server" and I
| > | "could wreck everbody else's site". He refuses to explain this, telling me I
| > | am stupid.
| > |
| > | I am a web designer, not a secretary. When I set proper class and ID
| > | attributes something or someone is deleting or moving my attributes to other
| > | tables and objects and otherwise making a mess of my pages whike I am
| > | working. Every 5-10 minutes my coding is attacked. When i rewrite a style
| > | sheet and apply the changes, then an hour to several months later the text
| > | book method I used to write and save the style sheet is blocked and my site
| > | is messed up. I keep asking myself, why would a Microsoft recommended host be
| > | doing this?
| > |
| > | Is FWHN moving on to Expressions? So I check out Expressions Web Designer on
| > |
http://mountainclubs.ca and note that after one or two logins my login is
| > | permanently fried, even after I uninstall Expressions and return to FWHN's
| > | butchered FrontPage.
| > |
| > | My question is very simple. Is there a way to get past predatory host
| > | obstruction of basic FrontPage functionality? Perhaps some code that conceals
| > | the site from style perverts, so that the world I service can enjoy site
| > | design the way FrontPage is designed to deliver it.
| > |
| > | Regs, mark
| > |
| > | "Stefan B Rusynko" wrote:
| > |
| > | > If you are being blocked from using / changing themes on a WSS server
| > | > - the host does not have the roles set correctly
| > | > (or you do not have Web Designer or Administrator rights)
| > | > -
http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stsf01.mspx?mfr=true
| > | > Also see
| > | >
http://www.sharepointcustomization.com/resources/tipstricks/wss_cssguide.htm
| > | > --
| > | >
| > | > _____________________________________________
| > | > SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
| > | > "Warning - Using the F1 Key will not break anything!" (-;
| > | > To find the best Newsgroup for FrontPage support see:
| > | >
http://www.frontpagemvps.com/FrontPageNewsGroups/tabid/53/Default.aspx
| > | > _____________________________________________
| > | >
| > | >
| > | > |
http://sbrenjoy.bizland.com/frontpage/themes/newthemes.html#Granular
| > | > |
| > | > | The link above describes how vbs can manipulate styles, and makes me wonder
| > | > | if my virtual SharePoint host is manipulating my design by eliminating all
| > | > | FrontPage style capability. My host is Front Pages Web Hosting, and I thought
| > | > | by its name and Microsoft lables everywhere that it would support the
| > | > | FrontPage product on its SharePoint servers.
| > | > |
| > | > | One of my sites is
http://www.mountainclubs.bc.ca and services about 5,000
| > | > | registered users. Due to ongoing problems fitting design to organizational
| > | > | requests, the site is none too popular. The situation is that Front Pages Web
| > | > | Hosting has questioned me for months about using FrontPage Theme
| > | > | customization. Beginning last week, any attempt I make to customize a theme
| > | > | is completely ignored. In fact, not only are theme changes undone, but all
| > | > | new related web part page content is deleted along with the theme change!
| > | > |
| > | > | FWHN refers to my theme work as their "project". Here's how my theme
| > | > | "project" had to progress.
| > | > | 1. Initial success was had simply creating/editing a user defined style with
| > | > |
www.mountainclubs.bc.ca open in FrontPage. This is when techniical staff at
| > | > | FWHN advised me that I was going to be made a "project". This style technique
| > | > | was disabled by the server within two months.
| > | > | 2. Next, I created theme sites on my local disc and applied those to
| > | > |
www.mountainclubs.bc.ca with fair results. Initially, it was possible to
| > | > | effect change using User Defined styles, but eventually my "project" status
| > | > | reduced effective design to styling only HTML Tags styles. And then that was
| > | > | impossible.
| > | > | 3. In the final stage, I was making theme changes only when they were
| > | > | effected on my hard disc and saved as a unique theme name, and then the new
| > | > | theme was applied to my site pages. Although beginning last week, it seems
| > | > | that FWHN is disabling even this basic theme management. With the noted
| > | > | destruction of site tect and image content.
| > | > |
| > | > | Naturally, servicing 5,000 people my design response to legitimate requests
| > | > | was initially extensive. Now it appears that SharePoint is being made into a
| > | > | single style "template". Is my "project" status a universal woe?
| > | > |
| > | > | How much of the decay in FrontPage design functionality is related to
| > | > | whatever FWHN is attempting to accomplish with its "project", and how much is
| > | > | related to problems with FrontPage 2003? FWHN tells me they have to continue
| > | > | their "project" because "you are making life difficult for us".
| > | > |
| > | > | Is FrontPage really causing too many problems for servers? FrontPage 2003 is
| > | > | the only Office 2003 product without any significant (or specific) product
| > | > | updates since its release 3 years ago. Is a solution for virtual SharePoint
| > | > | accounts on the way. Incidentally, I left bCentral.com SharePoint hosting
| > | > | months ago to escape even worse theme problems.
| > | > |
| > | > | My hope is that we will all get back the ability to use FontPage to style
| > | > | our SharePoint sites. This is a corporate imperative. My hope is that servers
| > | > | will not be able to make any customer into a "project" to attack FrontPage
| > | > | functionality. My fear is that Microsoft will adopt the FWHN project
| > | > | directions and remove themes and styles from the FrontPage functionality for
| > | > | SharePoint design. As Javascript is already disabled on the Tools, Page
| > | > | Options, Authoring tab when SharePoint is selected, this would constitute a
| > | > | major deprecation of an essentially magnificent web design tool.
| > | > |
| > | > | Is there a safe and secure way to style sharePoint sites using FrontPage
| > | > | 2003 without server interference?
| > | > |
| > | > | ((this article is duplicated in the FrontPage Server Extensions forum))
| > | >
| > | >
| > | >
| >
| >
| >
