Joe McShea

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 57 total)
  • Author
    Posts
  • in reply to: SharePoint 2016 list dialog height get shortened #2066
    Joe McShea
    Keymaster

    This has been fixed in 2018.04…and only about 5 months later than I originally said…sorry.

    Joe

    Joe McShea
    Keymaster

    No problem, glad I could help.

    I honestly thought this was going to be a bad one. Worst case is, I couldn’t even reproduce it, in which case we’d need to go down the rabbit hole of trying to figure out what’s different between your install and mine. And that could have easily happened, since this problem doesn’t affect all SP19 installs, and nobody has figured out why some and not others.

    But then when I could reproduce it I thought uh oh, something very bad is happening, until I realized the JavaScript was actually running without issue. And once I saw the CSS was coming back “200 ok” I knew it really couldn’t be my problem, but what the f?

    Anyway, gave me something to blog about 😉

    Joe

    Joe McShea
    Keymaster

    Hello,

    I have now tried this solution and it did work (after clearing my browser cache a few times). The instructions are a little vague and finding the feature was a bit of a pain, so here is where it was for me:

    Add Roles and Features Wizard - IIS 6 Metabase Compatibility

    This is in the “Add Roles and Features Wizard” found in “Server Manager”.

    Not a bad night. I went from “Oh my god, why does Microsoft hate me?” to “Oh, that was easy”, in about a half an hour 😉

    Joe

    Joe McShea
    Keymaster

    I think I’ve found the cause of this. Looking at the network tab, I saw that my CSS is being loaded as I said, but looking at the headers, SharePoint is identifying the Content-Type as “application/octet-stream.” This is very wrong and evil, and is causing the browser to not treat the file as a style sheet, thus no styles get applied.

    I’ve confirmed this from the following TechNet post: SharePoint-hosted CSS files are loaded as application/octet-stream

    There is an accepted solution on that post, which is to add the feature “IIS 6 Metabase Compatibility(Web-Metabase).” (It gives a bit more detail) I haven’t tried it yet.

    Joe

    • This reply was modified 1 year, 3 months ago by Joe McShea.
    Joe McShea
    Keymaster

    Hello,

    Ok, I have managed to stand up a 2019 RTM development machine, and my results are the same as yours. It looks like none of my styles are being applied, including jQuery-UI styles. What’s strange is that looking at it in the debugger, those files are getting loaded successfully, but the page looks completely un-stylized. If I inspect elements, the DOM inspector doesn’t see any styles that should be applied except default styles. The classes are all correct, and the css got loaded but doesn’t appear to have been applied.

    I rather expected the problem to be JavaScript crashing somehow, but there’s no evidence of that. In fact, as ugly as the page looks, it still sort of functions. Like if I click on ‘Add Container’ or ‘About’ on the menu, those dialogs boxes do pop up (also looking ugly of course), and I can add a container and see it show up. Even the drag and drop of the fields and containers works. And, I can save the configuration and it is applied to the actual form which works (sort of). The sort of is of course that no styles are applied there either, but if I configure tabs it hides and shows fields correctly, it just looks like crap.

    And there are no JavaScript exceptions at all (other than one jQuery exception when I try to load the configuration, but that’s expected and handled, I haven’t configured the list yet).

    Anyway, this is pretty annoying, because I didn’t have this problem with SharePoint 2019 Preview at all. I’ll certainly look into it, but I’m stumped at the moment, and unfortunately I’m tied up all next week so I’m not going to get a chance to look at this until after Memorial day sometime. I’ll let you know if I make any progress.

    Joe

    • This reply was modified 1 year, 3 months ago by Joe McShea.
    Joe McShea
    Keymaster

    Also, what kind of site are you trying to use it on? I’ve only tested it on a classic team site. I don’t know what happens on a noscript site, which includes at least My Sites, the web application root site, communications sites, and any self-service provisioned sites, but I kind of expect to have issues on those sites (quite possibly issues that cannot be overcome, or that can only be overcome by turning off noscript if that’s an option).

    Joe

    Joe McShea
    Keymaster

    I have tested SPEasyForms on the only 2019 environment I’ve had, which was preview (and now expired), and I didn’t have any issues with it, but I didn’t test it very thoroughly either. I assume you’re on the latest release (2018.03)? I’ll need to setup a 2019 RTM environment and take a look, but that’s going to take some time. If you’ve done both the sandbox and non-sandbox install and had the same issues, it doesn’t seem likely that you’ve missed a step.

    A screen-shot would probably be helpful, and if you can launch developer tools and tell me any console error messages you see that might be helpful too. Also look at the network tab in developer tools, and look for any errors there (i.e. usually anything in red).

    Joe

    • This reply was modified 1 year, 3 months ago by Joe McShea.
    in reply to: Deploy Solution to subweb only #1995
    Joe McShea
    Keymaster

    Hi Michael,

    I believe that a one line modification to SPEasyFormsInstaller.aspx could make it do what you want. I haven’t actually tested this, but I took a quick look at the code and I’ve copied in the modified function below, with a comment showing the modified line. Just make a copy of SPEasyFormsInstaller.aspx and replace the initClientContext method with the one below, and it should do what you want.

    initClientContext: function(success, failure) {
      if (!spEasyFormsInstaller.clientContext) {
        spEasyFormsInstaller.clientContext = new SP.ClientContext();
    
        if (!spEasyFormsInstaller.site) {
          // modified to get the current web instead of site
          spEasyFormsInstaller.site = spEasyFormsInstaller.clientContext.get_web();
        }
    
        if (!spEasyFormsInstaller.siteUserCustomActions) {
          // because site is actually web, this will now get the web user custom actions
          spEasyFormsInstaller.siteUserCustomActions = spEasyFormsInstaller.site.get_userCustomActions();
          spEasyFormsInstaller.clientContext.load(spEasyFormsInstaller.siteUserCustomActions);
          spEasyFormsInstaller.userCustomActions = spEasyFormsInstaller.siteUserCustomActions;
        }
    
        spEasyFormsInstaller.clientContext.executeQueryAsync(success, failure);
      } else if (!spEasyFormsInstaller.siteUserCustomActions) {
        spEasyFormsInstaller.siteUserCustomActions = spEasyFormsInstaller.site.get_userCustomActions();
        spEasyFormsInstaller.clientContext.load(spEasyFormsInstaller.siteUserCustomActions);
        spEasyFormsInstaller.userCustomActions = spEasyFormsInstaller.siteUserCustomActions;
    
        spEasyFormsInstaller.clientContext.executeQueryAsync(success, failure);
      } else {
        success();
      }
    },
    

    Joe

    in reply to: SharePoint 2016 list dialog height get shortened #1994
    Joe McShea
    Keymaster

    Hi Jeff,

    Nice. I’m still working on a fix, but not finding much time to work on it. Hopefully, I’ll release something before May is done.

    Joe

    Joe McShea
    Keymaster

    Um…Ow! Why does your Corporate hate me? 😉

    What you’re proposing should work fine. Specifically:

    RE: 1) The configuration page is not dependent on the User Custom Actions at all. As long as it’s in the same site collection as the list, it will work as well without them as with them. Of course, you’ll no loner have links to it on the ribbon or the list settings page, but that’s surmountable.

    RE: 2) and 3) spEasyForms.init() expects to be called after the form is rendered. As long as those scripts and script blocks are loaded in the same order, they should work the same regardless of how they’re loaded. The timing might be tricky. Due to Client Side Rendering in SP 2013+, the form is rendered by MS JavaScript some time after window.onload, so you might have to do something similar to ExecuteOrDelayUntilScriptLoaded to wait until the form has been rendered. To determine that the form has been rendered, you could look for the Created By and Last Modified fields, which are the last fields rendered in most forms (probably all forms, but I haven’t done an exhaustive survey).

    So technically, SPEasyForms isn’t dependent on user custom actions at all. It’s just dependent on those scripts and script blocks being loaded in a certain order, and after the form is loaded. It just so happens that script link and script block user custom actions satisfy those requirements very well, making SPEasyForms possible. But with a bit of work, you can manually load it just as well, there’s no magic in user custom actions.

    Joe

    • This reply was modified 1 year, 3 months ago by Joe McShea.
    • This reply was modified 1 year, 3 months ago by Joe McShea.
    • This reply was modified 1 year, 3 months ago by Joe McShea.
    • This reply was modified 1 year, 3 months ago by Joe McShea.
    in reply to: How to remove form and start again #1982
    Joe McShea
    Keymaster

    If you click the export button, it will open up the configuration file in a new tab. Go to that document on your SharePoint site and delete it (or rename it) and reopen the editor. It is now an un-configured list.

    Alternatively, you can hit the import button, leave the textarea blank, and then hit ok, which will clear out the configuration. The only difference is that with this method if you hit save without configuring, it will save an empty configuration file instead of no configuration file. So if you plan to configure it again with SPEasyForms, either method works.

    Joe

    in reply to: Can rearrange forms any longer #1980
    Joe McShea
    Keymaster

    BTW, to fix existing forms for now, you can edit the snippet contents and remove any list elements. Save the configuration and reload the page. The drag and drop won’t start working again until you reload the page.

    If that doesn’t work, try removing all HTML snippets, and again reload the page. If it works now, you can try re-introducing HTML a little at a time to see if you can isolate what HTML it doesn’t like. But in general, the drag and drop will not be broken or fixed immediately by adding/removing/editing HTML. It won’t break (or be fixed) until you reload the page.

    Joe

    in reply to: Can rearrange forms any longer #1978
    Joe McShea
    Keymaster

    Hi,

    Sorry to take so long getting back to you. I have seen this happen before. It’s dependent on what is entered into the HTML snippet, and I hadn’t quite tracked down what HTML it doesn’t like, but I’ve now specifically seen it happen when I add an HTML unordered list (UL/LI) in a snippet.

    That shouldn’t be too surprising since the jQuery nested sortable plugin I’m using to allow that drag and drop behavior had a problem with any list elements that weren’t intended to be sortable. I thought I’d fixed that but it appears to have crept back in.

    I’ll see if I can fix it again, but in the meantime you may be able to fix it by just not using any list elements inside you HTML Snippets (i.e. no OL/UL/LI tags). It is possible to have a similar problem without lists in your HTML if it’s just not legal HTML. If you’re having it with a snippet that doesn’t contain lists, send me the HTML and I’ll look into it.

    Joe

    • This reply was modified 1 year, 3 months ago by Joe McShea.
    in reply to: SharePoint 2016 list dialog height get shortened #1976
    Joe McShea
    Keymaster

    Hi Jeff,

    I’m inserting the following style, using a CSS OnPreRender handler, so it gets inserted just before SharePoint starts rendering the form.

    <style type='text/css'>.ms-formtable { display: none; }</style>

    This hides the table element with class ms-formtable. The tricky part will be the timing.

    I think I do have a fix for this issue, but I need to do more testing and haven’t had a lot of time to work on it.

    I’d also like to make it so you can configure SPEasyForms to not hide the table at all, in which case SPEasyForms forms might load a bit jumpy, but non-SPEasyForms would load as normal, at your option. The default would still be to load as it does now (with the fix for dialogs of course).

    I’ll get out a fix as quick as I can. In the meantime, if you come up with a user custom actions fix, let me know.

    Joe

    • This reply was modified 1 year, 3 months ago by Joe McShea.
    in reply to: '_spPageContextInfo' is undefined #1968
    Joe McShea
    Keymaster

    Hello,

    Sorry to take so long to respond. I didn’t see this right away, and then I was sick as a dog for a while. Anyway, I don’t have much in the way of ‘this is how you get around this kind of problem type’ advice for this one, because I’ve never seen it before and it appears to be a very serious problem. And it’s a pretty fundamental problem, as in _spPageContextInfo is loaded on every SharePoint page, by OOB SharePoint JavaScript, so it not being defined by the time my scripts are loaded as user custom actions should never happen.

    There are some differences between my page and other SharePoint pages though. SharePoint pages are generally ASPX pages with some code behind, that use server side controls to load the initial JavaScript files that initialize _spPageContextInfo. My page is just HTML, so I had to manually put in script tags to load enough of the JavaScript to get _spPageContextInfo initialized.

    So it seems like the most likely issue is that one or more of the OOB SharePoint JavaScript files that I’m loading with script tags isn’t getting loaded for some reason. The most likely cause for that would be that I’m getting a ‘404 Not Found’ response, or a ‘403 Forbidden’ response, or some other HTTP error code response on one of more of those scripts.

    Try opening the developer tools, go to the network tab, make sure it’s recording, and refresh the page. Then look for anything that looks like an error and let me know what you see.

    I don’t believe it’s any kind of general problem with SharePoint 2013 either. I have a SharePoint 2013 Foundation developer VM that I check each release on, and it worked fine with 2018.03. I’ll check it again just to be sure.

    Joe

Viewing 15 posts - 1 through 15 (of 57 total)
Scroll to top