There's nothing to indicate a failure and "Install Extension" finished its log with EndJob Installation successful.

I even pushed an update out for it as a workaround for my previous problem, and those changes stuck. This is brand new development that is loading in the View and the .js but 404'ing other files in line with the behavior of the larger issue.

My workaround was to change my method to use an older, pre-existing module's API since they share the methods between them... but that kind of workaround won't work for new development. I can only redirect to old methods reigstered in the DB and move my .js files into SiteAssets for so long.

Back to beat the dead horse after some more digging and no real solutions yet. I'm suspicious this is a multiple webserver issue after reading 

https://cdn.iowacomputerg...-overview-202007.pdf

A new configuration feature was added in 9.6. Notably from page 3: "If you utilize DNN in a default configuration with more than one server you will often see issues such as missing pages, or outdated information from the old cache not being cleared"

I compared the WebServers table of all of our installs. All of the other sites have multiple entries (probably an Azure thing?) but all use the same IISAppName since their inception.

However, the problem site is employing two different IISAppNames, sometimes with LastActivityDate of each only a few days apart. These issues only started happening after the upgrade to 9.6, about 20 days later. To my knowledge no modules were installed around that time nor were any other big changes made other than the 9.6 update.

The intricacies of this are greek to me, but maybe this might help point at a potential cause for these issues? As far as I can tell, there is something going wrong with the caching part of uploading files where the database is not being updated when new files are added outside of a DNN process.

The only time the caching provider issue comes into play is if you are working with more than one active node. If inside of Azure APp service it is very possible that the machine name, and even IIS App Name, will change on a regular basis. But as long as you don't have auto-scale turned on it should never exist in more than one server at a time.

Even if it did, physical files, within Azure Auto-Scale are ok, it becomes an issue for other items that are cached, but it shouldn't impact a .HTML file or otherwise.

Your issue seems, to me, to be an issue with file permissions and/or overwriting the files when they are loaded via the resources.zip. it is possible that an individual file copy failed, yet the installation would be successful.

That's good to know - thanks for the input. Is there a good place to check those settings or compare against the other sites I might be missing?

As for a file failure through resources.zip, how do the other problems speak to the issue? Modules are one thing but this was discovered on single files. I can update an existing .html or .js file through FTP or other means and that file will not update on the site, it'll remain cached in its old state even after a cache clear. The first instance of the issue was uploading a .png through FTP.

Our update to 9.8 is failing as well and I suspect this is the issue, but I am not the one overseeing that at the moment. 

It's worth mentioning the sites in my previous post that are all "behaving" are children of this site in a sense, as they were cloned from it in Azure.

I guess we need to know the specifics of what you mean. Static files, such as HTML & CSS files DO have a client cache policy set of 365 days on them, so a CTRL + F5 refresh is going to be needed, or you will need to add a cachebuster to the URL. That isn't an issue, but a configuration behavior of the platform.

Right - on releases and module installs/updates it's been pretty common practice to put a cachebuster on the URL, and SHIFT+F5 if that fails.

My complaints about the cache have been more about the database, not the browser cache. My understanding is DNN should be writing new files to the Files table so it knows they "exist" and will then display them. 

The issues I have been seeing are that any file uploaded to DNN through FTP or Azure's Kudu scm is ignored by DNN. They aren't written to the Files table. If I put them into a folder accessible by SiteAssets I can rectify it by going into that DNN menu and using sync (presumably alerting DNN to write them into the database). 

If I install modules through the usual route it writes part of it to the Files table, so I get the intial view on the page. Nothing goes into DesktopModules, not even a root folder with the module name. That's what made me wonder about multiple webservers: if it's in the Files table but I can't find it at all in the website's directory... is it somewhere else? 

I really appreciate your continued contribution and patience.

 

There is a setting for "Auto-Sync File System" that would have the system automatically look for files loaded into the /Portals/__ directories.

We typically recommend AGAINST this practice for performance reasons however and would elect to a manual sync after uploading if you need a file to be visible.

Luckily file upload traffic to anything under /Portals/ is few and far between, so manual sync has been working fine. The bigger issue is the DesktopModules once, since it's halting new module development. 

The "simple files" part of the issue can be handled pretty well. I can manually sync anything under /Portals/ and if we've installed simple modules that are only a view and some .js, I can move that .js under /Portals/ and however the view is being saved it can direct it there.

But for more complicated modules that use /DesktopModules/ModuleName/API to get some data from the database or elsewhere it's a big issue since the API calls 404 when they shouldn't be.

/DesktopModules folders are NOT at all synced into the database for file content.

BUT any static file (HTML, css, js, images, etc) are subject to the static file caching rules.)

Now, that shouldn't impact actual API endpoints. (unless they have a content type of a static file.)

Good to know. And interesting - they feel like symptoms of the same problem but maybe they aren't? On one hand I can't put files into the website any other way than Site Assets; on the other, using Install Extension isn't unpacking anything at all into DesktopModules or anywhere else (at least not that a FileZilla recursive search over wwwroot could find) but they're still partially displaying.

As far as the API calls go, I understand why they'd 404 if DesktopModules/ModuleName that they're referencing isn't there. I'm confident they work; in a lot of cases the "new modules" we install about once a quarter are reskinned old modules that use the same API endpoints, just for different tables. Or we'll do updates to existing modules to add on to them. We hit both cases recently after the advent of whatever this problem is and no luck to both.