What are some the items you change in your test environments to make them standout from production, and how do you go about make these changes? I know you can change the PS LOGO, but what else do you change in your test environments? Colors, fonts, etc.
Changing the colour schemes isn't too difficult. If you want to go down that route and need a helping hand I'll be happy to assist.
Other clients just put the environment name in the PIA Greeting. That's easy too:
http://peoplesofttipster.com/2007/06/13/using-the-pia-welcome-message/
I've not heard of anyone changing fonts though.
kind regards
Duncan
When you refresh a db, make sure you change tools tables that have dbname, web urls, and so on. The test db name will appear in the portal menu.
Changing the fonts would require changing all the style sheet definitions, a major headache. I guess you could go in and edit some basic style sheet attributes in app designer, PS_TEXT, et.al. and change those in a test environment. Maybe just changing a few would be enough.
Most test envs also open up security to some degree, simply because testers and developers likely need access to everything. So people's menus are going to be much larger than in production.
This is the relatively small change we made, to replace the "Home" link in the toolbar with the name of the environment eveywhere but prod. It was also incorporated in the refresh scripts to pull in the DBNAME dyanmically.
update psmsgcatdefn set message_text = 'DBNAME', descrlong = 'Environment name home replacement' where message_set_nbr = '95' and message_nbr = '401';
items to watch for:
file paths - if you open files for reading, and especially writing, to communicate with external systems, then you need to make sure you are not stepping on Production toes.
I would assume web services would also need the same re-routing so you don't "hit" live external production web services.
emails. workflow or other subsystems are liable to fire off emails to users or external parties. you need to make sure those emails are tester emails instead, not real addressees.
Related
Here's the rundown:
- We have a web site built with a commercial CMS (Sitefinity)
- The web site is .NET
- We have a test server and the live server set up for development (HTML, CSS, JavaScript).
I'm not a .NET programmer, but I work on a lot of frontend work. My question is this:
When I make CSS changes on the test server, is it normal practice for the entire web site to be "pushed" over to the live server? In other words, can I not just move over the CSS file from development to the live server? (It does not work when I do this.)
I ask this because every time CSS changes are made, the entire web site has to shutdown for 10-20 minutes to "push" the entire development to the live server. This seems like an unusual practice for something so small as making a few CSS changes, and it heavily slows down my work. Shutting down an entire web site to publish one basic CSS file just seems unreasonable of a service.
Can someone please educate me about your processes for .NET and CSS changes? What are the best practices in the industry? I would like to better my understanding of this.
Thank you. Your insight is appreciated.
We use Sitefinty as well and you can just copy or FTP the CSS file or files instead of redeploying the entire site. I like to use Beyond Compare.
We have some ways to push the changes on our development server to live server using sitefinity:
We can choose synchronization option in sitefinty, using that we can push content and all from one server to other server.
http://www.sitefinity.com/documentation/gettingstarted/getting-started-synchronizing-data-between-two-servers
You are doing updation on css files only then need not to push all code every time, might be after doing changes you are not able to see reflection, in that case please publish the page once and you can see reflection.
Please let me know if you want to know more.
It's possible there is some sort of caching going on. perhaps you can check the settings for static content with your host or in IIS to see when static files like css expire.
In addition you can restart Sitefinity by going to Administration Settings > Basic > Languages and clicking Save (or installing the Falafel Dashboard which has a handy restart button you can put on the home page)
Restarting the site should clear the cache and show you the changes. I hope this is helpful!
I've recently started using uglify-js to compress my JavaScript. Source maps are a nice feature for debugging but, for us, part of the benefit of compressing our JavaScript is the obfuscation.
Would putting the source map in a password protected directory prevent a passive observer from using it to re-beautify our JavaScript? Would his have any undesirable side-effects?
I'm not familiar with how and when browsers request this file. I don't want it to trigger password prompts and inconvenience users but I also don't want it to be publicly viewable.
Well, using Grunt you can set up different routines for dev to production; i.e. you may find Sass comments useful in dev but when you go to production you want all the comments stripped out. Same with sourcemaps. What I like to do is test with minified scripts to make sure everything works before the site goes live, so that my development environment is as close to the production environment as possible.
Ideally, you should have a local clone of your production site in which you can bugfix, enhance etc, rather than debugging a live site.
Yes it's possible someone can still take your JavaScript and beautify it again, but I think they would need the (uncompressed) source files, which you wouldn't store on your website in the first place; all they'd then be left with is beautified JS that had 1 character variable and function names, practically useless to anyone :-)
my application will have a subdomain per customer to show their logo and some other stuff:
company1.service.com
company2.service.com
I'm trying to see what's the best way to work during development:
configure the development machine HOST file to do some mapping, so I can access company1.localhost etc.
Use some kind of secret config flag which the app will check to determine what is the overriden domain
Do not use subdomains at all (even on production) and prefer query string
I think #1 should be ok for me just trying to see if anyone has bad experience with it or good with the other options.
I would use the first option because it is simple to setup and will reflect your target architecture. The third option is also simple to setup but it will differ from your actual scenario so you might need to make last minute changes before shipping which is never a good thing.
Is there a way to programmatically set the name of a file to be uploaded from a web page? I suspect that browser security restrictions make this impossible, but I'm hoping someone will prove me wrong.
I have a web application that needs to let the administrator upload HTML. The admin selects the HTML file, then the app uploads that file, plus figures out all the supporting files (images, stylesheet, etc) and uploads them too. There doesn't seem to be a way to programmatically upload the supporting files from a web page, since the user has to specify each file explicitly.
Currently I have a separate Windows app to do this, but it would be ideal to have this functionality integrated with the rest of the app. My back end is ASP.NET with C#.
There is no way to programatically grab files from a user's computer via the browser. This would be a security violation if a website could just grab things.
Yes you can (in modern browsers)...
You can get and set the value of HTMLInputElement.files.
See this answer.
No, you cannot do this without a client-side application or special plug-in.
Browser security doesn't allow the server to obtain information about the hard drive contents of the client.
You may be able to do this using some form of browser plug-in. This is more work for you (and there are potential security implications for this beyond those found when you just have users run your app). However, it may prevent a more integrated experience for your users. I'd hesitate to eliminate the application completely, though. Browser compatibility issues are common.
Back in the days before Visual Studio Web Server we would host our local dev inside IIS. If you have a workstation version of IIS that means only 1 website. What if you are working on several websites. Easy: create them in VDIRs, e.g. http://localhost/ProjectA, http://localhost/ProjectB.
Living in a VDIR doesn't sound so hard. Make sure all your images/CSS/links are relative paths, use the "~" a lot. Sounds like a good practise. Hardcoding images etc so they only work when the application is served from "/" sounds like a bad practise.
There are some nuances anywhere you have to build a link (mostly not common scenarios):
eg; PROD: http://prodserver.com/images/up.jpg -> DEV: http://localhost/ProjectA/images/up.jpg
links / images in emails
flash/javascript/silverlight requests data from the server which contains links to images
The full link to the a PayPal IPN (the page paypal POSTs their response too)
So.. Are you doing this? Advantages / disadvantages? Any other gotchas I've missed?
I always avoid hardcoded paths, URLs, etc. unless there's a specific reason to do otherwise. Things inevitably change, and there's always the jump from your dev site to production.
The part that is usually the biggest nuisance would be in reusable client behaviors that need to reference other paths, and themselves can be reused in pages across the application's directory structure.
I like the idea handler that responds to "globalvars.ashx" (or something like that; there are many ways to handle this) which dynamically emits (and allows caching) properties regarding the global application properties.
Say the handler responsible for globalvars.ashx writes the result of something like this:
String.Format("var ApplicationProperties = {{ RootPath:{0} }};", Request.ApplicationPath);
Your JS behaviors could theoretically reference that property object at any point via ApplicationProperties.RootPath.
In short, yes. The disadvantages of not doing so outweigh the benefits. I actually think your first two points can also be mostly mitigated from using app-relative paths ("~"), but nevertheless, some scenarios such as "integration-level" ones (like PayPal) may indeed prove tricky.
But at the end of the day, if you need to host your app in a virtual directory you are virtually guaranteed problems if you haven't coded your app to be vdir-friendly from the get go. I know I have.
Some background/context: My current production environment at work is almost always a virtual directory anyway, so I do this by necessity. And I've never had a problem when an application was created as a root-level website. This certainly wouldn't be the case if it was the other way around.