DNN Persona bar, error 500 on API/personaBar/localization/gettable?culture=en-US - dotnetnuke

After logging in DNN (v. 09.01.01 (129)) thru the /login interface,
The site makes space for the DNN bar, but the DNN bar does not actually appear.
After which in console we see this particular error
/API/personaBar/localization/gettable?culture=en-US:1 Failed to load resource: the server responded with a status of 500 (Internal Server Error)
We have tried all the suggestions in DNN's forums here,
But none seem to work (deleting the LocalResources.en-US file, checking Permissions..)
How ca nwe diagnose the actual issue, and how do we restore the persona Bar?

It's hard to say, but here's some options :
If you do a custom module, make sure it not overwrite Newtonsoft.json.dll and System.web.http.dll, try overwrite the library with your backup.
Make sure there's no virtual directory under your website.
Try upgrade it to latest DNN.

Two ways to try to get additional details about the error. First try recreating it then connect to your SQL server to run a query or two.
You can try to query the EventLog table to try to find the specific error. From that table row, you'll need to grab the ExceptionHash value and then query the Exceptions table to try to get details.
select top 5 * from eventlog
where exceptionhash is not null
order by logcreatedate desc
select * from exceptions where exceptionhash = '###'
(replace ### with the hash found in the first results)
From the exceptions table you'll want to look at the Message and StackTrace columns for any details that might point you in the direction of what the actual issue is.
You'll also likely find that upgrading to the most recent release may fix your problems.

Related

WordPress site without db table prefix. Best way to add a prefix?

I'm trying to migrate a WordPress site to some new hosting. The site is an older site, created probably 7+ years ago. I'm getting an error from wordpress upon bringing it to the new server that gave me a heads-up that the WP tables have no prefix. Sure enough, I login to Phpmyadmin, and there are no prefixes on the tables. I have since tried several methods to add prefixes and get the site migrated, but all are coming up short:
Direct DB dump from phpmyadmin on old server, import into new server. Triggers "tables have no prefix" error
Use updraft plus to get the backup from old server, restore to new server (triggers "tables have no prefix" fatal error)
Revised #1(above) approach - db dump/import/restore, manually add (via operations tab in each table) wp_ prefix to all tables. Site loads, but logging in as admin then yields no access to wp-admin dashboard (black bar at top after login, but no options for doing anything on the dashboard). I have tried the various tricks suggested, like adding a new temp admin user or trying to make necessary changes in usermeta table to my admin user, but that doesn't resolve it.
Tried using the All In One WP Security plugin to add new prefix. It recognizes the current no prefix, but won't successfully complete adding the prefixes to the DB. Tried another plugin and didn't even get that far.
Using Phpmyadmin, I've tried to use the built-in add prefix, and that seems to not work either.
I just looked at phpmyadmin again after trying unsuccessfully to use the built-in add prefix function, and am noticing that while all tables are InnoDB, the collation is a mix of utf8_general_ci and utf8mb4_unicode_ci . I understand that the second option is probably what I want all of them to be. I was able to add prefixes to the tables that are utf8mb4_unicode_ci, but the rest of them simply do not respond to that function in phpmyadmin.
The next thing I tried was to change all the collation to utf8mb4_unicode_ci using phpmyadmin. I used the "change all tables collations" and "change all tables columns collations". That seemed to work and then allowed me to add a prefix. However, after that, while the site was still working, I could again no longer get into the wp-admin dashboard. If I were to try the same conversion but only doing the "change all tables collations" and skipping the second option, I wonder if that might work. Just tried converting the tables without converting all the columns. The site seems to still work ok after doing that. But trying again to add prefix using the AIO WP security plugin still doesn't complete.
It would seem that adding the prefix is causing the issue. Is this something that a theme could be interfering with for some reason? What am I missing here?
Any tips for moving forward with this site? Thanks so much.
You can simply dump the database, open it with a text editor, replace all occurrences of "CREATE TABLE " with "CREATE TABLE yourprefix_" and restore the database.
It should be easy, depending on the size of the dump.

SSRS Deployed reports have disabled parameters in IE, and those without parameters just return a blank screen

I have a set of SSRS reports developed in Visual Studio Data Tools that are used for several clients.
For one particular site, each report will work perfectly in 'Preview' mode in Visual Studio, however when I deploy them and attempt to run them in IE all of the parameters are disabled/greyed out. I also tried to put in a set of default parameters to see what would happen and when I click 'Run Report' I do not even get the 'Loading' image and the report is just blank.
I have checked the IE security settings and have reset them, and also added the report web page location in to trusted sites which unfortunately hasn't made a difference. One thing I have also noticed is that when I try to view Developer Tools in IE, it also just shows a blank white screen.
I've searched online and found a couple of old posts on various websites with a similar issue but none that were ever resolved, and now I am not sure how to proceed.
More info that might be useful:
The client are using IE 11, it is a terminal server style setup with around 8 or 9 users logged on.
The report I am testing with has 2 date parameters first, and two multi-valued parameters (I have tried other reports but with the same issue)
The client recently moved servers and the reports worked fine before, although it was a fresh install of the report so I don't believe there would be any old settings that could be causing it?
Any help greatly appreciated :)
In SSRS, report parameters can be inactive when the report is generated from a snapshot. Removing this option is as follows:
Navigate to the report in SSRS
"Manage" the report from the drop down.
Select "Processing Options" from the left menu
Is "Render this report from a report snapshot" selected? If so, switch
to "Always run this report with the most recent data" option.
Run the report to determine if parameters are now active.
If this fixes your issue, you may need to switch from the snapshot option to the Scheduled Cache option available under the left menu link "Cache Refresh Options"
For one particular site, each report will work perfectly in 'Preview' mode in Visual Studio, however when I deploy them and attempt to run them in IE all of the parameters are disabled/greyed out.
If that is the case, and a previous version of the report was already on the SSRS report server, what you can do is delete the report, and upload it again. There is some kind of cache for the parameters, that causes that if you modify the order of them, some get disabled, and the only way I have found to get rid of it is to delete the old report from the server.
For me this worked:
Open IE
Go to Settings->Compatibility View Settings
Add the URL of your report server.
You could be experiencing an old bug which was reported a long time ago in a connect item:
SSRS Weird Parameters Order Bug (parameter grayed out)
The official Microsoft answer on this subject is:
Currently this behavior is per design. However we will consider this
behavior improvement in a future release of reporting services The
only workaround at this point is to change the order of the
parameters.
Are the parameters on the RDL file set to visible, like below:
Just going to add this as an answer, because it solved the issue for me;
Delete the report on the server & deploy again.
What happens is that you completely remove the report and thus also its parameters. When you deploy a report its parameters their default values do not get overwritten in case it didn't have a default the first time you deployed.

When magento widgets are run for the first time do they alter the database?

I've been following this tutorial http://www.magentocommerce.com/knowledge-base/entry/tutorial-creating-a-magento-widget-part-1 to create a Magento widget as part of an extension I'm working on.
Whilst the widget was created successfully and worked as I wanted it, I changed the code and started getting the following error
Warning: Invalid argument supplied for foreach() in app/code/core/Mage/Widget/Model/Widget/Instance.php on line 502
When I changed the code back, the error was still present. However when I copied all my module to a fresh Magento install then the error wouldn't appear.
Although my widget does not explicitly use the database does anyone know if the act of installing and uninstalling a Magento widget makes changes to the core databases tables and if it does, which tables are altered.
Thanks
The core_resource table contains a list of all modules, so adding a new module will cause a new row to be created.
If you have anything in your module's sql folder, that code will be run depending on your module's version.
Without knowing exactly what code was run and changed, it's hard to know what your specific problem is.
http://www.magentocommerce.com/knowledge-base/entry/magento-for-dev-part-6-magento-setup-resources
So if you followed that tutorial you linked to I do not think it changed any database settings.
You can tell if a module will add tables or modify table columns by the following method.
Assume the module is called Foo_Bar and it is installed in the "community" code pool (as opposed to core or local).
Navigate to app/code/community/Foo/Bar. You will at minimum usually see etc and Block directories there.
If you see a sql directory then this module makes db changes. You also need to understand a module is versioned and may initially make a certain table and then modify it.
By way of example you can go to any core module and look for the same. For example I am running Enterprise 1.12 and went to:
app/code/core/Mage/Sendfriend/sql/sendfriend_setup
I see:
mysql4-upgrade-1.5.9.9-1.6.0.0.php
mysql4-upgrade-0.7.3-0.7.4.php
mysql4-upgrade-0.7.2-0.7.3.php
mysql4-upgrade-0.7.1-0.7.2.php
mysql4-install-0.7.0.php
install-1.6.0.0.php
Note the upgrade x-y nomenclature. That is what core_resource keeps track of.
If you are wondering where your new module's settings are saved, that is actually in core_config_data. try this:
SELECT * FROM core_config_data where path like '%foo%';
Assuming you have some setting in the admin you named "foo".
Now back to your problem. That is a common php error. You are running a foreach on something which can not be iterated. The code right before that is probably not returning an array or collection or whatever.
Ideally you should always wrap the foreach with a statement that checks that the item you are iterating over is not empty.
You can also turn off displaying errors or suppress that error using the # statement which is a bad practice...

intellij idea data sources doesn't see existing table in the database

intellij idea data sources doesn't see existing table in my mysql database, while Netbeans see it.
i've created a table in the database. When i create connection in intellij idea data sources, it sees my scheme, i do select it in "schemas and tables" but then i don't see it in the list.
every schema, but mine's. When i try to connect to it with netbeans or mysql workbench, it's just ok. same story with several databases, with root access, too. any table, but mine's.
what could be wrong?
i see question like mine's here, related to visual studio, no answer.
please, give a good clue
I had the same problem in IntelliJ IDEA 15.
I fixed it by right clicking the data source -> Properties -> Schemas -> Use legacy introspector.
I found the reason of problem for HSQLDB: There is IDEA bug (i have 11.0 version).
Create db with relative path (relative of MODULE), like this:
jdbc:hsqldb:file:db_file/testDBInMemory;shutdown=true;hsqldb.write_delay=‌​false;
f:\TestModule\db_file\
When added it to Data Sources, IDEA recognizes this path as relative of $IDEA_HOME$/bin folder.
f:\Program Files\JetBrains\IntelliJ IDEA 11.0\bin\db_file\
So you have two different data bases. And when JPA updated first, Data Source doesn't see update in other.
WORKAROUND:
use absolute path in file db url.
For the latecomers still experiencing this, Intellij IDEA also has the following features which might help you as they have me:
'Force Refresh' (ctrl + shift + F5): "The Force Refresh action clears the data source information from cache and loads it again from scratch."
'Forget Cached Schema' which clears the schema cache. Does require you to set which schema you want shown again.
Right click your datasource -> Diagnostics -> 'Force Refresh' or 'Forget Cached Schema'
Source: https://www.jetbrains.com/help/idea/cannot-find-a-database-object-in-the-database-tree-view.html
The answer for me was buried in a comment, so I'm posting it here. The symptom for me was seeing an error like this:
Unable to resolve table 'thetablename'
And the table name was highlighted in red.
The following fixes are all ways to trigger IntelliJ to refresh data sources:
CTRL+ALT+Y to refresh the db stuff, or
CTRL+F5, or
Click the database vertical tab on the right, expand, right-click on each DB connection and select 'Refresh'
Kudos to #ice for answering this earlier in a comment. I'm basically just elaborating and making sure this shows up as an answer.

Moss 2007 SSP Error "Search application '{0}' is not ready."

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/

Resources