Sitecore.Ship
Sitecore.Ship copied to clipboard
kevinobee
Have new instance of Sitecore trying to run Sitecore Ship, runtime error
Hi,
We have a new instance of Sitecore and had pushed our website code which also included the SitecoreShip DLLs and ship.config. We additionally pushed code for a separate commerce piece. Trying to get to the http://url/scshipservices (like we always do) is yielding a runtime error. We do have the latest version of json (i.e. 8.0) -- could this be the problem? Are there any other configs I need to look for?
Thanks. Melissa Mussitsch
You guys must have built your own version to enable /scshipservices, correct? Can you please post the stack trace details?
Hi Pavel, We did build our own. That was one of my other posts because our web team wanted to use the /services path. Please tell me how to get you the stack trace details. Sorry!
Thanks. Melissa
On Thu, Jun 30, 2016 at 8:37 AM, Pavel Veller [email protected] wrote:
You guys must have built your own version to enable /scshipservices, correct? Can you please post the stack trace details?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kevinobee/Sitecore.Ship/issues/60#issuecomment-229645721, or mute the thread https://github.com/notifications/unsubscribe/ALbST8qy4f8J6thZcPbxnT7lh8NK7cOmks5qQ7iTgaJpZM4JCGrj .
If you don't have detailed errors enabled in your Web.config you won't see the YSOD with the stack trace in your browser. Go look at the log files on the server. You will find them in .\Data\logs. Is this a CD or a CM instance? do you have access to /sitecore? If you don't have access to the file system but can get into the console you can get to the log files via the File Browser. Also, if you can get to the console go ahead and check /sitecore/admin/showconfig.aspx and make sure your /scshipservices is still listed in the IgnoreUrlPrefixes. It's a <setting name ='IgnoreUrlPrefixes'...>. I have once made a mistake by having another config patch overwrite the ship.config's change.
Okay so it is a CM server. But I did go to the logs folder and don't see too much helpful there. But running showconfig.aspx, I'm not seeing my scshipservices url. What I see is below.
I see the ship.config reference. I do actually see ship.config in both projects (that were pushed, one after the other). And both have the scshipservices reference. Could there be another file that sends IgnoreUrlPrefixes that is overwriting the other? I'm going to search the whole solution and see. But please let me know what you think.
Thank you. Melissa
On Thu, Jun 30, 2016 at 8:52 AM, Pavel Veller [email protected] wrote:
If you don't have detailed errors enabled in your Web.config you won't see the YSOD with the stack trace in your browser. Go look at the log files on the server. You will find them in .\Data\logs. Is this a CD or a CM instance? do you have access to /sitecore? If you don't have access to the file system but can get into the console you can get to the log files via the File Browser. Also, if you can get to the console go ahead and check /sitecore/admin/showconfig.aspx and make sure your /scshipservices is still listed in the IgnoreUrlPrefixes. It's a <setting name ='IgnoreUrlPrefixes'...>. I have once made a mistake by having another config patch overwrite the ship.config's change.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kevinobee/Sitecore.Ship/issues/60#issuecomment-229648938, or mute the thread https://github.com/notifications/unsubscribe/ALbST-cW4g9afZ9Wm7w5e0EHoY8cIShrks5qQ7wXgaJpZM4JCGrj .
Okay so I found also a sitecore.config with below:
And reference.storefront.config with below:
And my ship.config as:
Wonder if it's okay to remove the references in the first two files? I'll compare closely.
Thanks. Melissa
On Thu, Jun 30, 2016 at 9:40 AM, Melissa Mussitsch < [email protected]> wrote:
Okay so it is a CM server. But I did go to the logs folder and don't see too much helpful there. But running showconfig.aspx, I'm not seeing my scshipservices url. What I see is below.
I see the ship.config reference. I do actually see ship.config in both projects (that were pushed, one after the other). And both have the scshipservices reference. Could there be another file that sends IgnoreUrlPrefixes that is overwriting the other? I'm going to search the whole solution and see. But please let me know what you think.
Thank you. Melissa
On Thu, Jun 30, 2016 at 8:52 AM, Pavel Veller [email protected] wrote:
If you don't have detailed errors enabled in your Web.config you won't see the YSOD with the stack trace in your browser. Go look at the log files on the server. You will find them in .\Data\logs. Is this a CD or a CM instance? do you have access to /sitecore? If you don't have access to the file system but can get into the console you can get to the log files via the File Browser. Also, if you can get to the console go ahead and check /sitecore/admin/showconfig.aspx and make sure your /scshipservices is still listed in the IgnoreUrlPrefixes. It's a <setting name ='IgnoreUrlPrefixes'...>. I have once made a mistake by having another config patch overwrite the ship.config's change.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kevinobee/Sitecore.Ship/issues/60#issuecomment-229648938, or mute the thread https://github.com/notifications/unsubscribe/ALbST-cW4g9afZ9Wm7w5e0EHoY8cIShrks5qQ7wXgaJpZM4JCGrj .
Thanks. I believe you found it. No exception stack trace means no error. Sitecore just doesn't let Ship handle the URL but otherwise has no clue what to do with it. The patches apply in alphabetical order but you will only see the name of the first patch file in the resulting configuration. It doesn't accumulate - that's why you see ship.config but the change that is active is from reference.storefront.config. Whatever is in the sitecore.config is your starting point.
It's NOT ok to remove the patches. Every config has it there for a reason. What you need to do is to combine the changes requested by ship.config and reference.storefront.config and make sure your combined patch runs last. The easiest way to ensure that is to put it into a z folder (App_Config\Include\zAfterEverythingElse\combined.ignore.urls.config).
Makes sense?
Hi Pavel, Yes it does make sense. We've had to create some z, files usually with a name rather than folder, like z_datafolder.config etc. So it makes sense. This commerce code is new to me. So the only question is that there is a lot in that reference.storefront.config file. The IgnoreUrls is a small part and is set differently than ship.config using a "<patch:attribute name="value">" command. The only three additional paths from that file are /js|/styles|/bundles. Should I just add the scshipservices to that file? Seems simpler? I like things being separate so it's easy to track changes, but not if it's overwriting things. The ship reference has nothing to do with commerce, but I'm not sure how else to get around it. Or just do like you suggested and then take the Ignore.Urls out of both files altogether so it's in one shared file at the end?
Thanks Melissa
On Thu, Jun 30, 2016 at 10:08 AM, Pavel Veller [email protected] wrote:
Thanks. I believe you found it. No exception stack trace means no error. Sitecore just doesn't let Ship handle the URL but otherwise has no clue what to do with it. The patches apply in alphabetical order but you will only see the name of the first patch file in the resulting configuration. It doesn't accumulate - that's why you see ship.config but the change that is active is from reference.storefront.config. Whatever is in the sitecore.config is your starting point.
It's NOT ok to remove the patches. Every config has it there for a reason. What you need to do is to combine the changes requested by ship.config and reference.storefront.config and make sure your combined patch runs last. The easiest way to ensure that is to put it into a z folder ( App_Config\Include\zAfterEverythingElse\combined.ignore.urls.config).
Makes sense?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kevinobee/Sitecore.Ship/issues/60#issuecomment-229669319, or mute the thread https://github.com/notifications/unsubscribe/ALbST4XoXTD1aXZ9nRhotN4E4EyzYqVzks5qQ83ogaJpZM4JCGrj .
That will work to. Config patches are applied using the following logic:
- All files from
App_Config\Includein alphabetical order without recursing into the sub folder - All subfolders from
App_Config\Includein alphabetical order. For each folder and its subfolders run logic described in1recursively.
I just added the scshipservices one to the storefront file. I ran the command and it worked great.
Thank you so much for your help Pavel!!
Melissa
On Thu, Jun 30, 2016 at 10:31 AM, Pavel Veller [email protected] wrote:
That will work to. Config patches are applied using the following logic:
- All files from App_Config\Include in alphabetical order without recursing into the sub folder
- All subfolders from App_Config\Include in alphabetical order. For each folder and its subfolders run logic described in 1 recursively.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kevinobee/Sitecore.Ship/issues/60#issuecomment-229676117, or mute the thread https://github.com/notifications/unsubscribe/ALbST8ZIy02JXH9NXuaUTE1PKZdWgrMBks5qQ9NRgaJpZM4JCGrj .
Thanks Pavel for fielding this one.
I will get these points included in the ship documentation so that things are a little clearer in the future.
-Kevin
On Thu, Jun 30, 2016 at 3:58 PM, Pavel Veller [email protected] wrote:
Glad I could help!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kevinobee/Sitecore.Ship/issues/60#issuecomment-229684651, or mute the thread https://github.com/notifications/unsubscribe/ABnDouE8ADM5T1H2ivsCYzPXYokgUptyks5qQ9mEgaJpZM4JCGrj .
