Sharepoint 2019 On-Premise Server Farm Broken (Blank White Screen) - sharepoint-2019

I have updated my Sharepoint 2019 Server Farms today (KB5001975), and after the update the documents and site content pages are shows only blank screen,
Home.aspx - working,
/_layouts/15/viewlsts.aspx - Not working (blank white screen)
/Shared%20Documents/Forms/AllItems.aspx - Not working (blank white screen)
/SitePages/Forms/ByAuthor.aspx - Not working (blank white screen)
/_layouts/15/RecycleBin.aspx - Not working (blank white screen)
$farm = Get-SPFarm
$farm.BuildVersion
Major - 16
Minor - 0
Build - 10376
Revision - 20001
i have restarted multiple times all the servers (Database server, application search server, central admin server, external facing server) still it shows blank white screen,
Also there is no error and warnings on the upgrade status (/_admin/UpgradeStatus.aspx), still i could not see any content on the site content pages
can i uninstall the updates which is installed recently?

This happened after install sharepoint 2019 updates. Installing patch KB5001974 worked for me

I fixed by installing the patch KB5001974 need to be installed along with the KB5001975

I saw the same - fresh ‘19 install with all Sharepoint updates available through WU - was getting the same blank screens on document lists and content lists.
KB5001974 which is a manual update solved this. The issue doesn’t appear in the list of included fixes for …974 or …975 but seems to have done the trick anyway.

Disabling modern view worked for me
https://techcommunity.microsoft.com/t5/microsoft-sharepoint-blog/how-to-disable-the-modern-experience-in-sharepoint-2019/ba-p/303649 as a work-around.
In my case I added an out of the box feature at Sitecollection level.
#Site Collection Level
Add-PSSnapin microsoft.sharepoint.powershell -ea 0
$site = Get-SPSite http://spwfe
#Disable modern Lists and libraries at the Site Collection Level
$featureguid = new-object System.Guid "E3540C7D-6BEA-403C-A224-1A12EAFEE4C4"
$site.Features.Add($featureguid, $true)
#Re-enable the modern experience at the site collection Level.
$featureguid = new-object System.Guid "E3540C7D-6BEA-403C-A224-1A12EAFEE4C4"
$site.Features.Remove($featureguid, $true)

Related

Blogdown: Individual publication content not displaying

I'm using this theme in RStudio Blogdown and Netlify on a MacOS. After updating blowdown to v.1.2, the site for individual publication content stopped displaying any information. The html for individual publications in public is blank.
I also noticed that duplicates of the featured.png for individual publications are created after running blogdown::serve_site(). Though I can't see how this could be related to the issue above, I tried deleting duplicate images and no changes.
I have not managed to find anyone reporting the same issue (sorry if I missed it). I checked the dates and potential errors in the index.md publication files, and execute hugo -v. I have not found any issue.
Any pointers to resolve these issues would be very appreciated.
For a reproducible example:
Site: https://www.franciscorowe.com
Site repo (served from here): GitHub - fcorowe/franciscorowe.github.io
Thanks!

How to fix, blank screen after deployment of war file

I work still view month on a project with RapidClipse 4.0
I deployed on the production server several versions of the project war files. Everything worked fine.
After the last deployment I got a blank screen after loading the application URL
For the server I use a docker container with following setting:
Apache Tomcat/8.5.43, JVM: 1.8.0_222-b10, 3.10.105, amd64
My first thought was: "ok you did something wrong in your code.. turn back and every thing is fine.... :-((
It wasn't !!
I used several versions which runs fine befor.
I stopped the application, redeployed it and deleted it.
Then I deployed an older version....and once again a version older..a.s.o
Non of the versions which worked fine befor did work again.
I got every time the same result: after loading the application a blank white screen.
So far so bad:
I tried to look into ../conf/server.xml if deployment parameter is set correctly:
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
looked fine!
I enhanced the cache by:
$CATALINA_BASE/conf/context.xml added following code:
<Resources cachingAllowed="true" cacheMaxSize="100000" />
also without success.
I tried to look in catalina.out: There is still nothing helpfull:
14-Aug-2019 20:29:21.087 INFO [http-nio-8080-exec-6] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/usr/local/tomcat/webapps/RC_07.war]
14-Aug-2019 20:29:31.190 INFO [http-nio-8080-exec-6] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/usr/local/tomcat/webapps/RC_07.war] has finished in [10,102] ms
after debug in browser I got following:
257ms Processing time was 134ms
257msReferenced paintables: 6
283msEstablishing push connection
300msCould not load theme from http://myIP:8888/RC_07/VAADIN/themes//styles.css?v=7.7.13
310msPush connection established using long-polling
I searched also in the history of the docker container an found that this problem (300ms....) still persists from beginning, over all versions I deployed before.
Out of this, I assume, that this could not be the reason, too.
Or am I wrong?
I searched around this VAADIN Problem and found a lot, but I was not able to solve it. The styles.css file are still in place on the server.
I am wondering on ..../VAADIN/themes//styles.css...
the double slash in error message.
But in my code I couldn't find similar.
Also the buildpath in eclipse includes the folder structure like expected.
Now I am at the end!
I am confused, how I should go ahead to figure out the reason for this behavior, or much better to fix it.
Any idea/ help would be welcome!!
Thank you in advance
rgds
OpaHeinz
After long research, togehter with RapidClipse support we found the solution.
I had two issues:
1) unknown how, we assume, that there was an error in the MainUI xml file.
After resetting with and high of view and layout, and turning back to setting before,
the page elements were visible again in design view.
2) there is a parameter for the theme under MainUI properties - misc -
This parameter was set, but without content. This results in a code line: this.setTheme("");
After resetting this, a deployment was possible like before.
Everything is fine now.
Thanks again to RapidClipse support.

Prestashop Productcomments Module Issue

I am experiencing a problem with the Productcomments module which I am using in a custom module and I cannot figure out how to fix it. The problem is with the star rating in the Productcomments form itself. This form works perfectly in a localhost environment - see images 1 and 2, but not on a live server - see images 3 and 4. On the live server it is showing no stars, just radio buttons, and no delete button for removing the stars.
Form as it looks on WAMP
Code from Chromes Inspect for WAMP
Form as it looks on Live Server
Code from Chromes Inspect for Live Server
Disabling the link to the following 2 js files recreates the problem on the local server which would suggest that the problem lies in the links to these two files on the live server, however I have checked all links to these files and they are correct, as are the permissions for these files.
jquery.rating.pack.js and productcomments.js
Occasionally when I clear cache under Advanced Parameters > Performance I get the following error message:
Fatal error: Uncaught --> Smarty: unable to write file /home/productm/public_html/cache/smarty/compile/10/e2/20/wrt5cbbb0747109d3_91450142
<-- thrown in /home/productm/public_html/tools/smarty/sysplugins/smarty_internal_write_file.php on line 46
This problem applies to all 1.6 versions of Prestashop tested.
Any suggestions on how to fix this problem would be appreciated.
Thanks
Kathleen
The error code you've got from clearing cache is linked to permission problems.
Here's probably a duplicate of your issue: How to fix erorr "Fatal error: Uncaught --> Smarty: unable to write file"?
Check that your prestashop files are set to 644 and folders 755 permission. (not just the js files you've mentioned).
Also if you manually moved the module to your live server(ftp), check the ownership of those files.
Edit:
I'll add this to the answer since the permissions didn't fix your problem.
looks like you have a prestashop bug going on with the JS (Synchronous loaded scripts)
here's a patch to fix that, maybe it fixes your original problem.
https://github.com/PrestaShop/PrestaShop/pull/6749/commits/73fd8dbed9f413a70f7d04fc4badd48f00ca501a

MigrationError during plone upgrading from 4.3.8 to 5.0.3

OS: debian 8.3
I upgraded partially from 4.3.8 to 5.0.3. I get stuck in migration error to Dexterity.
The process I did before upgrade in 4.3.8:
Disable all add-ons
Add a sitecustomize.py in site-package director:
import sys
sys.setdefaultencoding('utf8')
update and re-index all catalog in keti/portal_catalog/manage_main
delete 'checkout_workflow_policy' in keti/portal_properties/site_properties/manage_propertiesForm
delete all objects in /keti/reference_catalog/manage_catalogView
The process of upgrading:
1.Clean Install of Plone 5.0.3
2.Copy database from existing server (plone 4.3.8), along with blobstorage to the Plone 5.0.3 server.
3.Run upgrade
During this, all look good(report in http://pastie.org/10787693) except 2 invalid import handlers:
**Step collective.z3cform.datetimewidget has an invalid import handler
**Step languagetool has an invalid import handler
4. On the upgrade page Click “Upgrade your existing content to use Dexterity”(##pac_installer). Then I can visit the instance.
5. Click to Install dexterity. It works except a message on the topline of the page:
error while rendering plone.resourceregistries.scripts error while rendering plone.resourceregistries.styles
6. In Migration control panel page, BlobFile, Document and Folder were selected to migrate.
After a long waiting, errors pop up (http://pastie.org/10787685)
Event.log: http://pastie.org/10792956
Newest Progress:
Good news: I click on " Show country-specific language variants " in /##language-controlpanel, then select "simplified chinese" in the language list. So the problem of ConstraintNotSatisfied is resolved. Now I go back to the first problem: MigrationError: MigrationError for obj at /keti/switch/shbpsh/2010/2010ybps There is no content rules in the server and I disabled globally.)
Add-ons activated in 4.3.8: Diazo theme support, Dexterity Content Types, collective.z3cform.datetimewidget, Static resource storage
Any suggestion?
Best Regards.
Hugo
After deleted the folder cited in MigrationError, I finally upgrade the server to 5.0.4. Then I will perform a testing.

Flying Saucer not resolving Images or CSS on ubuntu tomcat6

I am running into an issue with the Grails Pdf plugin which uses Flying Saucer. Everything works as expected until I deploy onto an Ubuntu server running Tomcat6. Then references in my gsp's to css and images fail, though I still get the PDF to render.
I have tried two different approaches to building the PDF
ITextRenderer renderer = new ITextRenderer()
renderer.setDocument(url)
renderer.setDocumentFromString(content, baseUri)
Running a war with 'grails prod run-war' works, running and a dummy app with no security works locally, but fails when I deploy it on the server as well. (though none of the content I am trying to render is secured anyway), the URL's of the images are correct. (I have tried both absolute and relative URL's) neither gets rendered in the PDF, but if you request those resources from a browser they are there. References to images not hosted on the server do work.
All this leads me to believe that the tomcat6 that gets installed with ubuntu when you do sudo apt-get install tomcat6 is configured funny somehow. I know that it runs with user 'tocat6' instead of 'root' as many installations do. Could that be causing Flying Saucer to somehow not have the right access to get at the files being referenced?
Since everything except the images/css is working, I guess your baseURI is not correct?! I have this code on a production system and it is working. All the images are referenced absolut:
renderer.setDocument(doc, request.getScheme() + "://" + request.getServerName() + ":" + request.getServerPort());
What is your baseURI set to?