I have installed DXA 1.7 (.Net) on SDL Web 8.5. Now when requesting the homepage I get the following error:
2017-06-21 14:09:03,216 [28] WARN - HTML design is not published nor does file 'D:\Tridion\Sites\DXA\system\assets\version.json' exist on disk. Setting version to v0.0
2017-06-21 14:09:03,268 [28] ERROR - Item '/system/config/_all.json' not found for Localization '94'
Sdl.Web.Common.DxaItemNotFoundException: Item '/system/config/_all.json' not found for Localization '94'
I have checked the following:
Unpublished and republished 'Publication Settings'
JSON files are not present in BINARYVARIANTS Table
Publication Settings are published successfully to the Content Delivery Server (Deployer package contains JSON files)
In the Tridion GUI I can preview Publication Settings (JSON files are generated)
It looks like that after or during deploying the JSON files are disappearing and never ending up in the Broker database. Can it be that the deploying process (which is also using JSON in SDL Web 8.5) is interfering with deploying JSON files?
EDIT 22-06-17
I changed the Deployer to publish to the file system. Also here the files are disappearing. I also inspected the transport package. I noticed that the config folder is present in the zip file but not anymore in the transaction folder.
Applying the latest CD_8.5.0.3922 hotfix has resolved the issue.
Caused by an issue internally at SDL where the latest copy of the hotfix from development had not been moved to the FTP.
I traced the issue back to the installation of hotfix CD 8.5.0.3922 which is causing issues when deploying DXA specific content.
Related
I upgraded existing web forms app (c#) from Visual Studio 2017 Enterprise to 2019. While code is working fine, when I open default.aspx page - I get 123 errors (while code compiles fine). If I open it back in 2017 version - no errors
I had addressed couple of the errors but not sure what to do with the rest. Especially puzzling that code compiles with 0 errors. Errors show only if I open default.aspx
Most errors are CS0103 - the name 'name here' doesn't exist in the current context
Few errors CS0400 - the type or namespace 'project name' could not be found in the global namespace
Few CS1061 - 'default_aspx' doesn't contain definition for 'Context'...
I don't understand how it still compiles without errors and works? What changed with upgrade that those errors popped up? All those names and namespaces exist and there were no changes other than upgrade. New requirements? How to fix it?
Found a solution:
This is happening to projects that are using v1.0.0 of Microsoft.Net.Compilers. To work around this problem you need to update to the latest stable version which is 3.0.0.
All errors disappeared.
Looks like something broken with VS Intellisense since the compile and build sueeccded.
1.Before you open the web form project in VS2019, navigate to its Solution Directory and delete the hidden .vs folder there, after that open the project in VS2019 to check if it helps.
2.If the issue persists, try cleaning the VS component cache after close all VS instance:
Go C:\Users\xxx\AppData\Local\Microsoft\VisualStudio directory, you can find many 15.xx and 16.xx folders there, feel free to delete all ComponentModelCache folders in them and restart VS.
Using Visual Studio Express 2013 for Web
Set up bundling and caching as generally described here: http://www.asp.net/mvc/overview/performance/bundling-and-minification
In the VS Solution Explorer, individual file properties for .js and .css files are set to Build Action: Content. I don't know if this was specifically set or a default setting.
When deployed in Debug Mode, individual files are deployed to the destination server's directory structure as expected and the rendered code in the index.aspx head section has a long list of for each individual javascript and css file configured, again, as expected. When loaded, I can see that the files are being loaded individually. Everything works.
When deployed in Release Mode, however, individual files are still being deployed to the destination server's directory structure, non-bundled and non-minified. Index.aspx DOES reflect a rendered reference to each bundled "file" using . When loaded, I can see that things are being loaded via the bundle.
In Release Mode, the individual files deployed to the destination server's directory structure seem to be redundant, and certainly unwanted. However, if I remove them post-deploy I get reference errors. Similarly, if I change file properties for each file's Build Action: Content to Build Action: None, the aforementioned individual files aren't deployed in Release Mode OR Debug Mode and I get reference errors in both scenarios.
Question 1: Am I misunderstanding how bundling and minification works and these individual non-bundled, non-minified files are indeed required in Release Mode?
Question 2: If I understand correctly that these non-bundled, non-minified files are NOT necessary in Release Mode, how do I configure the deploy correctly such that they ARE deployed in Debug Mode and ARE NOT deployed in Release Mode AND I get no reference errors?
Answer 1: Bundling and minification are done at run-time, not at build, compile, or deploy time. The "bundle" that is downloaded is a virtual file, it doesn't actually exist anywhere on disk. Thus the original "source" files are needed.
Answer 2: Sorry but your understanding is not correct. The non-bundled/minified files are required in Release mode as they form the basis for creating the bundled/minified payload that is sent to the client.
I've gone through Jaime's deployer tutorial.
I've successfully created my deployer extension, which when integrating with SDL Tridion, the functionality works exactly as required.
But, what i can't get to work is the local debugging / running with the deployer inside eclipse (documented here)
The eclipse based deployer does run. If I drop my zip file into my test incoming folder the zip is picked up and processed. However, the customdeployer code I have written is never entered or executed.
I don't get any errors in the 'eclipse' deployer logs, but it always stops on the following line:
2012-04-13 20:24:51,642 DEBUG QueueLocationHandler - Removing exclusive lock on Deployment package: tcm:0-1026-66560 with type: CONTENT.
As we've three developers here also stuck on the same problem on all their machines I was wondering (hoping!) that this was a common problem and someone knew what we're doing wrong.
Thanks
Can you check which cd_deployer_conf.xml is it loaded by the Deployer? Just check the Deployer startup logs (in debug mode).
I suspect your Eclipse project at Debug/Run time doesn't load the the cd_*_config.xml files from the config folder in Eclipse. This will prevent your deployer module (which I supposed you configured in your cd_deployer_conf.xml) from being loaded and called.
What I normally do is to declare this config folder as an Eclipse Source Folder. Then at Debug/Run time, Eclipse will be included in the classpath automatically. This makes point #8 from http://www.sdltridionworld.com/articles/sdltridion2011/tutorials/Deployer_Extensions_With_Eclipse_3.aspx redundant.
I ran into exactly the same problem after following the same deployer extension tutorial.
I managed to solve it by changing the name of the package that my module was in to be com.tridion.deployer.extensions
Previously my module had been in a package I had named com.yourcompany.tridion.deployer.extensions and this appeared to have the affect of preventing the deployer from loading my extension module.
I had this issue, with a slight variation in that originally it worked, but then it stopped working.
Turns out the deployment package was somehow getting corrupted(locked?) in the process, as when i tried with a backup of the deployment package from the previous day it worked just fine.
I am attempting to get Solr to work with Tika so I can index Word and PDF documents in my Drupal web site.
I've looked at the Wiki page and this page and they indicate adding a requestHandler in solrconfig.xml.
I did that and now Solr throws an exception:
org.apache.solr.common.SolrException: Error loading class 'org.apache.solr.handler.extraction.ExtractingRequestHandler'
I have did some searches and see that others have had this problem but see no easy fix. I'm using Solr 3.4.0 on Windows Server 2003. Any ideas about how to resolve this?
As a side note I've got Drupal using Solr for searching and that is working. But what I cannot get working is to have Solr index PDF and Word documents. I'm sure this is a common need for most web sites but I have spent days on this and I cannot believe it is this poorly documented and this hard to figure out.
If you are running Solr from the example directory with the jetty setup, it should run as is without any changes.
However, for multicore setup you would need to copy the jars into the lib directory.
If you check the solrconfig in the example folders, it includes the jars for solr cell and extraction libraries.
solrconfig.xml -
Uncomment this line to include all the lib jars -
<lib dir="./lib" />
Copy the jars from these folders to your multicore lib folder.
These jars for used for extraction. (Apache pdfbox, poi, fontbox etc)
<lib dir="../../dist/" regex="apache-solr-cell-\d.*\.jar" />
<lib dir="../../contrib/extraction/lib" />
When you start Solr, you should see all the jars loaded.
Should get you working.
we have a application, which loads several plugins (audio/videocodec related). All plugins except one plugin are getting loaded correctly.
The message i get is The file "foobar.codec" is not a valid Qt plugin (and QPluginLoader::load () returns false)
The strange thing about this is, that the identical plugin works for every other developer in our team, and on non-development machines aswell - And i havent changed any source files or project settings of that codec (it is a fresh svn checkout).
On the Qt documentation page, ive read that setting the enviroment variable QT_DEBUG_PLUGINS to 1, will give me more debug output on the console, but that was not the case.
And deleting all entries in the plugin cache referring to the plugin in question hasnt changed anything aswell.
The setup:
Qt 4.3.3
Windows XP SP3
VS 2005 (crt-version: 8.0.50727.4053)
EDIT:
Just found this faq-entry. I will check tomorrow if the dependencies are alright...
One of the dependency dlls of the plugin dll was not in the correct path