My DNN woes continue. The site alias was s-fr-dnn/MNTCDNN/accr2011 (I didn't set this up). It was suggested I remove the MNTCDNN portion of the alias (now it is s-fr-dnn/accr2011). I did so, and now I get "resource not found errors". So, I decided to change it back to s-fr-dnn/MNTCDNN/accr2011, but I keep getting a "This site alias is invalid" error. How can it be invalid? It was just labeled as such.
In ISS, there is the default website and under that is MNTCDNN (if this helps at all).
Any clue to what is wrong here?
Erik,
A few thoughts.
TO remove a virtual directory from the path, you will have to physically move the files on the server. This is why your first round attempt was an issue.
Regarding your change, since you made the change directly in the database, DNN heavily caches portal aliases. You will need to recycle the application pool for your changes to be available.
Related
I currently have a website i'm working on that I have taken over from another individual, I dumped his SQL file into my database and everything seems to be ok apart from one thing. Whenever I try to log in to the back end or if I try to go elsewhere, it will add an additional .co.uk to the address bar, making it like so:
From: www.domain.co.uk to www.domain.co.uk.co.uk
I've had a dig in the database but I really can't find anything and i've never faced this issue before, could anyone shed some light on this for me? Maybe just let me know where I could look within the database to identify the problem, many thanks.
Take a look at the .htaccess file in the root folder, which is hidden and may contain rewrite rules.
Also, I recommend you use this plugin for migrations:
http://wordpress.org/extend/plugins/wp-migrate-db/
I use it whenever I move from localhost to a live site and vice versa. It will also ensure your widgets are preserved, since doing a find replace will cause the object serialisation syntax WordPress uses to break.
After migrating, you need to visit Settings > Permalinks so the .htaccess file can be updated according to the new URL for rewrites.
i am trying to figure this out for a long time now, but so far no luck, maybe somebody can help me.
I have a 2.2.2 cakephp installed on my computer (localhost) and everything works perfectly. But now i want that same project to be online on remote server. I upload everything, set mysql path but i get a blank page when trying to access the site.
If i upload a fresh cakephp it works, but my project doesnt. The debug is set to default, think that should be 2? I also deleted files in cache/tmp, but still no errors or anything, just blank page.
Any info would be helpful, thank you.
I hate when that happens :). Usually it does if there is an error somewhere and you can't see it because the errors are turned off, so you should call phpinfo() and see if display_errors is on. Changing the debug mode doesn't work every time since display_errors is set from php.ini.
Unfortunately, if this is the problem and you don't have access to edit the php.ini file, you might need to ask the hosting provider to change it and restart the php service.
You can also try this: error_reporting(E_ALL)
I uploaded changes to my cakephp website and discovered that all actions for a particular controller returned a blank page. I discovered what the error was and was able to reproduce it with another controller.
The problem was that in the first line of my controller file I had a space before the opening php tag.
One space cost me hours.
Just uploading all files won't cut it. Make sure you work through this checklist:
First and foremost, check the error log file located under app/tmp/logs/error.log, this usually holds some very good pointers as to what is wrong.
Make sure you have uploaded the app/Config/database.php file with the proper details. Local installs usually have user root without password. Online servers (obviously) do not!
To that extent, also make sure you actually have a database with your hosting provider (either your host sent you the info or you need to create it yourself using their control panel).
Make sure you also uploaded all .htaccess files (the one under the root directory and /app and /app/webroot), some FTP programs don't show this "hidden" file by default.
If all else fails, contact your hosting provider for further support as they usually have access to more verbose server logs that can also hold clues.
The real problem was only the coding I used in notepad++. All my files were encoded with UTF-8, but they should have been UTF-8 without BOM. After I changed it to UTF-8 withot BOM, everything started to work perfectly.
We generally use two different hosting services. On one, everything works ticketyboo, as it does on my local dev servers. On the other server, however, I am having this problem:
I can't access the users controller like this:
http://www.example.com/users/login
But I can like this:
http://www.example.com/Users/login
** note the capitalised 'Users' **
If I displace the application to a sub-folder everything works fine (both upper- and lowercase).
The hosting company have looked at it and can't see a problem at their end and they assure me that users is not a reserved word.
You might say this isn't a problem, just use the version that works. Unfortunately it leads to problems downstream where Cake core starts generating urls itself.
Anybody else seen this problem or know the solution?
[This only occurs on the users controller - all others work as expected]
Without seeing all your code / diving in too deeply, I'm not sure what the cause of this problem is. Do you have some special stuff going on in the routes.php file? If you have a specific route defined for users, that could be it.
However, you could make a quick fix -- in UsersController (or AppController if you want to ensure this behavior doesn't pop up elsewhere) just add a line to the beforeFilter() method to capitalize / decapitalize (whichever is more appropriate) the controller parameter.
[edit] - sorry, didn't finish that first paragraph. It still could be the routes file, even though it works on one server and not the other, because it's possible that the working server uses a case-insensitive apache module that normalizes all urls. This is why it's so nice to have your staging and dev setups being EXACTLY the same as production.
While the hosting support denied that the word 'user' or 'users' or 'Users' was in any way reserved, it seems that it was:
"We have removed the users/ redirect"
Problem solved.
So the last couple of days my dev webpage for ssrs has been looking really weird, as if it's not getting styled by css at all. I'm not the only person that is seeing it like this. We just rebooted the server and it didn't have any effect. If you know what it causing this, please help.
another symptom is that i can't modify security settings now.
If I were you, I would view the page using FF (firebug), and take a look in the head to see whether the CSS is being imported.
If it is, make sure the path is correct.
A couple of general things come to mind...
Make sure your IIS application/virtual directory settings are correct especially if you are using SSRS2005. The default IIS applications are "Reports" and "ReportServer"
Make sure the NTFS rights are correct for Local path. For example the default location for ReportServer is "c:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer"
In my experience when strange things like this are happening there are user rights/access issues. Especially when you can't modify security settings.
HTH
Well it kinda seems to have fixed itself.
This may be a bit naive, but have you tried an offline version of the code?
Get the generated HTML via "view source" in your browser of choice, then get the stylesheet by accessing it directly from the same browser, using whatever the path is from the html (I recommend Google Chrome, as the view source provides clickable hyperlinks within the source). Put them both on your desktop, making sure the relative paths are preserved, and see what it looks like offline.
I'm sure that the server/Microsoft produce all of this code and so it's SUPPOSED to work, so a missing closing tag or misplaced semi-colon is probably not the answer, but I have found more than once that pulling my output off the server and onto my desktop has made the problem go from mysterious to "Oh! Duh! /styles/style.css, not /Styles/style.css" etc etc.
The problem can only be with your server if www doesn't have read/execute access to all of the right folders. I find this really unlikely, but it's easy to check by simply trying to view the source code of the CSS. If you can, the problem is post-server output.
I'm trying to fix a broken SSP on a MOSS 2007 site. The problem I am running into manifests itself as follows...
In the SSP "Search Settings" page I get this message:
The search service is currently offline. Visit the Services on Server page in SharePoint Central Administration to verify whether the service is enabled. This might also be because an indexer move is in progress.
In the SSP "User Profiles and Properties" page I get this in red at the top:
An error has occurred while accessing the SQL Server database or the Office SharePoint Server Search service. If this is the first time you have seen this message, try again later. If this problem persists, contact your administrator.
I have contacted my administrator, but that is currently me and it turns out I don't know any more than I do about the problem.
In the Event Log I get the following message:
The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID 8714973c-0514-4e1a-be01-e1fe8bc01a18) threw an exception. More information is included below.
Search application '{0}' is not ready.
The Event ID is 6398, which isn't as useful as I had hoped, but I don find the message interesting in that it looks like a String.format call where the substituted value is missing. Unfortunately no interesting in that it tells me how to fix the problem.
Sharepoint's own log offers this:
UserProfileConfigManager.GetImportStatus() failed to obtain crawl status: System.InvalidOperationException: Search application '{0}' is not ready.
at Microsoft.Office.Server.Search.Administration.SearchApi..ctor(WellKnownSearchCatalogs catalog, SearchSharedApplication application)
at Microsoft.Office.Server.Search.Administration.SearchSharedApplication.get_SearchApi()
at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.c__DisplayClass3.b__0()
at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)
I have tried stopping and starting the search service, removing and re-adding it from the administration panel, and pretty much every other thing I could find to do with Sharepoint's own administrative tools, which leads me to believe the problem here may be database or permissions related.
There was a second SSP set up on the same server, which I think may have been part of the original cause of the problem, but removing it has made no difference.
Maybe you can make sense of this - I'm new to sharepoint, so it makes little sense to me:
"Service Shared, after looking for the solution much encontre this forum where a person tapeworm the same problem. After reading a infinity of commentaries, which I made to solve the problem was to create a new shared service, later it assigns the other applications to him and later I put it like predetermined, it initiates the import of profiles, and later the hearings, clearly first I did it in a site of tests just in case something happened, later eliminates the First Shared Service and finally the error I am solved. The snapshot of the Registry of the configuration of the application in the data base has been stored correctly. Context: application `SharedServices2 ′"
You didn't mention anything about tapeworms, so maybe you're running a newer version.
Translation of:
http://tecnologiainformaticait.wordpress.com/2008/11/21/error-sharepoint-search-application-0-is-not-ready/
Personally, I'd try the msdn forums.
So it seems that the problem was a corrupted Shared Service Provider ( no idea how it came about, but there you go ) and the only working solution I could find was to delete it and start again.
I suspect there may have been a more elegant fix by changing something in the database somewhere, but I don't know the Sharepoint Database model well enough to find it in the time available.
As an additional warning to this, if you do delete your SSP you may find that it doesn't delete cleanly so that you get a bunch of SQL server tasks that still try to run on an empty database, which can cause problems if you have anything else running on the same database server.
Same problem. My DBA delete correctly the search database and it still doesn't work.
I'll post the solution on my blog when I found something.
For the moment, we open a MS call.
Created a new SSP
2- In central admin, click on shared Services Administration
3- Click on "Change Associations" and move all the web apps to the new SSP
Choose a new search_DB and select the good server that will index if you are in a farm
Problems created by this operation:
We notice that we lose statistics information for our sites.
if you tried this solution, give us your feed back too
Thanks.
http://dejacquelot.blogspot.com/