When I start the Websphere Portal console and go to Manage Pages, I see a whole bunch of Portal pages in Active Status. Basically these are IBM internal portlet pages. I do not use them. Is there any way to safely Deactivate at least some of these portlets? The goal is to save on startup time of the portal server.
There are a couple of options for this. The first link is for Portal light mode and the second one talks about developer mode. Both do similar things but developer mode loads fewer things on start up.
Also, having a page active or disabled shouldn't affect startup time. Preventing portlet applications from starting on startup will help though. You used both terms in your question so I want to make sure that was clear and you don't disable the pages expecting improvements.
http://www-10.lotus.com/ldd/portalwiki.nsf/xpDocViewer.xsp?lookupName=IBM+WebSphere+Portal+8+Product+Documentation#action=openDocument&res_title=Using_portal_light_mode_wp8&content=pdcontent
http://www-10.lotus.com/ldd/portalwiki.nsf/xpDocViewer.xsp?lookupName=IBM+WebSphere+Portal+8+Product+Documentation#action=openDocument&res_title=Changing_to_developer_mode_wp8&content=pdcontent
Related
HELP!
Google has recently depreciated their AppEngine Console (https://appengine.google.com), and the link to a page that allowed setting the version of an application now goes to a new page which does not. (https://console.cloud.google.com/appengine/versions?project=...).
Do we have to split traffic to change versions?
Do we use the Google Cloud Shell?
Is this temporary?
Is this documented someplace?
You click the migrate traffic button on this page you linked. This is the same workflow as what was in the old UI. If you want to brute force it, open up the advanced options section.
I've just released a simple Drupal based site on a hosting partner.
The development was done by, first running a install script provided by my hosting partner. The script installed a default Drupal site eith a database.
After this I just logged in to my site and used admin tools to configure my site.
If that was step one,, step two will be to extend my site with one or two extra functions and improve look and feel.
My question is,,, how do I do that without interfering with my site witch now is "live"?
Are there some established methods and tools for doing this??
/regards
/lg
That depends on what you want to do and how you have your site set up so far. If you have one page that is set as frontpage, then you can make another page and test your new functions on that one. Or you could install another site, set it up in a similar way and try it there first.
There's of course loads of ways to do everything. You can start searching for "drupal deployment workflow" and go from there.
I'd like to disable user access to my app so that I can perform a schema migration. I've looked into a few possibilities and found possible shortcomings:
Disable datastore writes - I'd rather just bring my whole application down so that people do not see any errors, etc. Also, I assume disabling writes will prevent me from performing the migration.
Disable the application - It's not clear to me that this would disable it only for my users, leaving me unable to perform the migration. I am also unsure of the disable/enable turnaround time.
Redirect my domain name to a temporary page - my app would still be accessible on appspot.com
Upload a new version of my app that doesn't respond to requests other than to direct to a "temporarily down" page.
Any suggestions?
Suggestion number 4 seems like probably the best way to do this. Some frameworks have a "maintenance mode" in which all incoming requests would be redirected to a page indicating the site is down due to maintenance. If your framework doesn't support such a mode, you can just upload a new version of your app (maybe call the version maintenance) and switch to that as your new default version. This version could be an empty app in which all incoming requests are turned to a "maintenance page" indicating the site is down for maintenance. Then manually go to the version of your app with the migration code and execute it (http://<version>.<appname>.appspot.com). Switch your apps default version to the new version with the new schema when you're done with the migration.
Explanation of your other ideas
Disabling writes would prevent even you from making writes on the application. I believe this was more meant for migrating from one app to another or other applications of "freezing" the datastore.
Disable the application would bring the app down entirely
Redirecting your domain would inflict a DNS lag on your migration, something that can take 48 hours to fully propagate each way (switching to the temporary page, then switching back to the new version)
As aforementioned, IMHO this would be the best way to do it.
Is it not possible to use both schema's, and use a new version of your app to migrate, which only uses the new schema. In this way you can always fall back to your old version.
By the way. Because the datastore is schema-less, It was always possible for me to change the "schema", without bringing the app down.
Go to GCP > App engine > Settings > Disable application.
You can sure enable your application ay any time.
If you disable this app, a few things will happen:
The app will stop serving
All data and state will be saved
Billing charges will still incur when applicable
Your task queues will continue to run. They can be paused in the Cloud Tasks UI
I am new to DotNetNuke, but I'm an experienced web admin and programmer.
I have an ASP .NET website / web application that I want to integrate into DNN 5 so I can easily add / modify content, etc. My existing site uses it's own login system to display user information. I have successfully placed (using iframes) all of my existing pages inside DNN pages.
The problem I am having is that I need to conditionally hide certain pages in the menu until a user is logged into my application. To be clear, my users are logging in using my existing authentication system, and will not actually login to DNN, so I can't simply grant permissions to those pages.
My question is this: is there some way (perhaps by modifying the DNN code) to conditionally hide menu items until certain requirements are met, such as authentication through my login system?
You can write your own DNN Authentication module that leverages your current system and code.
Our shop uses DNN, but hands off authentication to our university's centralized authentication system. I didn't write it, but I don't get the impression that it was too hard. Now when we create a portal, we install and enable our authentication module and then turn off DNN Authentication. Works like a charm.
We used DNN Garden menu for this (we do some thing sort of like that) the menu has a Node manipulator interface you can code against
http://www.dnngarden.com/
http://www.dnngarden.com/Menu-structure-manipulation.T104.aspx
we have had great success with this -
The other option which we have done as well is to write your own menu provider - not really that hard
I'd like to write a console or winforms application that will interact with the EPiServer database. Since I don't want to muck about in the deep inards of the database I'd like to use the EPiServer API.
However, all the examples are using the "CommunitySystem.CurrentContext" which is null when running outside the website.
Now, I'm going to transfer a large amount of data from a legacy system to EpiServer Community and I really don't want to do that from a web page but from an application I have a little more control of.
Is there any way I can use the API from outside the web context?
I'm not that familiar with the community model. But... I've had no problems at all running huge imports through a web form (or control). The key (besides having disabled execution and database timeouts) has been to run it through Internet Explorer on the site's server and have the site's domain name mapped to 127.0.0.1 in the HOSTS-file. It can run for hours and hours while logging progress to a table or text-file before sending the response.
My colleague Jarle figured out the last bits and blogged the whole process here So if you want to run the EPiServer API outside of IIS, that's the place to start. Works like a charm!