All our content is gone, both on the frontend as the backend. Only the titels are there
If I check the database I still see the content in field_data_body. Rebuilding the nodes didn't work.
When I look this problem up, all are pointing to the organic group module. That I need to disable this. But I never installed this.
Anybody any idea to solve this (and what did I do the mess this up?).
This can be caused by deleting fields in your content type, or by disabling modules that provide the fields.
Also this can be caused by input filters being incorrect, check the enabled input formats, and lastly check user access control and make sure that all users can "access content".
Good luck!
Related
I installed dnn version 9. When I want to add a new page I go to the contents-> Pages-> Add page. an empty white page appears without any options to add a new page or event to cancel.
This is caused by a problem with your templates folder, either missing, or bad permissions. I'm guessing when you installed you chose the blank template?
I've got a blog post on things to try to resolve
http://www.chrishammond.com/Blog/itemId/2692/Canrsquot-add-ldquopagesrdquo-in-DNN9
"If you are having problems adding Pages in DNN 9, read this blog post.
I recently upgraded all of my sites to DNN 9, the most recent one being upgraded last night. This morning I wake up to an email from a client of mine reporting a problem with adding pages in one of their sites that they also upgraded to DNN recently. I read through their email, and decide that I’ll look into their issue a bit later, have an itch to scratch on one of my own websites, so I’ll get to them later (sorry client).
Working on this site that I upgrade last night, I decided I wanted to add another page to the site, low and behold, I was unable to do so.
To add a page in DNN9 you click on the “Content” option in the persona bar, and then the Pages option. There you will be presented with a view similar to this:
image
When I clicked on Add Page there, the screen went blank, like so:
image
That’s not very useful, actually that is as far from useful as possible. Once that happens, you can’t actually “do” anything from an Admin perspective. You have to “leave” this page, go somewhere else (click on manage/users for example, then you might need to click BACK in your browser a bunch of times) then you can click on Content/Pages again to get back into the Page listing for a site.
So why is the persona bar page blank? This error is the cause:
GET https://SOMEPORTALALIASHERE/API/PersonaBar/Pages/GetDefaultSettings? 500 (Internal Server Error)
If you dig into the DNN Error Log (Admin Logs) a bit you might find a more detailed error, something along the lines of
Message:Value cannot be null. Parameter name: source
StackTrace:
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable1 source, Func2 predicate) at Dnn.PersonaBar.Pages.Components.TemplateController.GetDefaultTemplateId(IEnumerable`1 templates) at Dnn.PersonaBar.Pages.Components.PagesControllerImpl.GetDefaultSettings() at Dnn.PersonaBar.Pages.Services.PagesController.GetDefaultSettings() at lambda_method(Closure , Object , Object[] ) at
So what does that message tell you? Well something is happening with your DNN Install trying to get a list of “page templates”. In digging further, on my site, I found the issue to be the File Permissions on the Templates folder in the portals/0/ directory. For some reason on the site that I upgraded last night, my permissions were set to ALL USERS DENY on the “Browse Files in Folder” and “Open Files in Folder” check boxes.
image
Unchecking those, clicking SAVE resolved my “pages” persona bar issues. How did those permissions get set? Who knows, this DNN site has been around since 2008 or earlier, and that never caused a problem.
There are definitely some “kinks” to be worked out of DNN9, but so far I am digging the new experience.
Regarding my “client”’s site, they had a similar, but different issue. In their case, the TEMPLATES folder didn’t exist in the Portal that they were trying to use. Simply creating a new Templates folder in their File Manager fixed that problem for their site."
I tried out many solutions but finally I figure it out by reinstalling and add Object Qualifier. because it is optional field I leave it without any value in my first installation
This error was fixed in DNN 9.0.1
I'm facing an issue here that happens when the final user edit the HTML in the browser and change the pages behavior. Lets say I have an input with disabled="true" and another attribute that makes the two way binding happen ng-model="MyModel".
Our pages were designed to support insert and edit in the same page (it was built on top of the ASP.NET MVC Framework), so we use the routes provided by it (and I can't change it).
So, deppending on the user role or any other condition, some fields may have the disabled attribute equals to true or false, and here is where the problems appears.
If the user edit the HTML and change the field that was previously disabled, he can now edit and change my model that he should not be able to change.
Sometimes, such fields cannot be handled(validated) in the backend because the backend knows that it may be changed by a user that has permission to do it.
Note: The user with roles to edit those fields is just an example, sometimes is just impossible to identify using validations in the backend when the field can or cannot be edited, in that case, we apply some view logic to decide when setting a field as disabled or enabled.
Iwas wondering, is there any good approach to handle with this situation? Does anyone faced the same problem? How did you solved the problem?
To resolve this problem on my own, I started out by installing Profile2 and Profile2 registration. At no point was I able to generate a page based on the user name (eg, {domain}/private/register). I figured it was not coming up b/c I checked off that anonymous users could not see published pages (which is a site requirement). However, I might have done something wrong but I went over the instructions several time and I don't think I made a mistake. Any suggestions would be helpful.
I think you may have to create a new content type, similar to the normal story or article types, and publish restricted content as the new page type. Apply the access restriction to this content type, and leave the default content types alone.
I am importing products using Commerce Feeds. The products appear just fine on the front end and via Store > Products in the admin. However no products appear under Content in the admin area. I have tried clearing out the database, re-importing, re-indexing, flushing caches - nothing works.
Also this is bizarre and seemingly un-related, however I noticed it around the same time I realized my products were not appearing in the admin - there is a strange whitespace above my admin menu bar - which only appears on the Content page (also coincidently the page giving me trouble.)
Using Commerce Kickstart (commerce_kickstart-7.x-2.0-rc1) (Would love to upgrade to the latest release but I am unsure how to do this without losing a great deal of work. I have not found a good upgrade document - please chime in if you know something I don't!)
I feel kind of stupid now. I edited the admin/content view and saw there was a filter criteria which caused it to not display nodes of type "product_display." Evidently this is intentional behavior. I am guessing you are only supposed to manage products from within the store tab. Still wish I could figure out the cause of the phantom whitespace at the top though.
The problem I am having is filtering out the users that come to our homepage just to login, since we have the client button on the homepage (and yes I've tried to get them to put it somewhere else).
I can't think of a way to do it because they don't look any different than potential clients, other than that they may visit more often and click on the button. Any ideas or software that might accomplish this?
one way, is to associate a cookie with those users and either a) don't load the tracking code when cookie is present, or b) in Analytics Settings -> Filter Manager, add an exclusion pattern matching the cookie name. a) would be more flexible.
now, there's no way to tell if the user is going to stay on the main site or hop to the client area... so it might undercount in some cases. but you might find that better than the overcount showing up now...
a slightly more intrusive option, would be a JavaScript overlay / splash screen that shows up when you detect a user returning that asks them, "Would you like to go directly to your client area? [YES] [NO, TAKE ME TO THE MAIN SITE]". in that case, the tracking code wouldn't be loaded unless, they say are going to the main site...
if using the filter manager method, you'll want to register the variable like so:
<body onLoad=”javascript:pageTracker._setVar('my_cookie_name_guid')”>