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!
Related
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.
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
Eisenberg already tried to help me with this issue, but admitted he really didn't know how to do it either: https://gitter.im/aurelia/Discuss?at=586dd660aa6be0472f0c608d
When running the aurelia-cli with au run it auto-bundles the app and during that process we tried to remove the html processing, however in the end, the closest we were to getting the bundle to look for the html pages on the server was an app-bundle.html page that obviously isn't created and shouldn't exist.
Any help on this issue would be greatly appreciated as my development is halted until I can get this sorted out.
I did an upgrade from Typo3 4.5 LTE to 6.2 LTE, following the instructions found here: stack overflow
Now during the process of using the Upgrade wizard the Excepiton #1314516809 occured.
Then I went to the db using my php-myadmin and corrected the CaseSensitive-Value as recommended here:wiki.typo3
but the error stays. Rereading the code i realized, that the files, which could not be found, had doubled file extensions like
File /_migrated/RTE/RTEimage.jpeg.jpeg does not exist.
How can I get rid of them?
Maybe this will help.
Migration of RTE images
You must modify the database table sys_file_storage and remove the image entries which cause problems. The images of the migration folder should not remain here.
I've performed an update from typo3 4.7.20 to 6.2.15. The process worked fine and there were no critical errors while running the install tool.
The frontend looks fine but the backend is broken:
I've removed all uncompatible extensions before I run the update. I've also checked all settings in the installationtool und deleted the temp/cache folder first.
I've got the feeling that the error is caused by the TemplaVoila! extension, I'm using v. 1.9.8. Firebug does not shows any error.
Does anyone had a similar problem and have already solved it?
Thank you very much!
I have come across this one multiple times. More often it is because there is a broken TBE_STYLES. I suggest you look around for $TBE_STYLES in your typo3conf folder and disable it for the time being. Most likely it will be in the extTables.php or some other file which is included dynamically.
seems BE is working, but you css does not got loaded.
check your 'web inspecter' to see if you get errors on loading CSS.
clear your cache (remove everything in typo3temp) and try again