We have been seeing this for quite some time now.
There is a custom module in our project that is currently under development.
We maintain separate versions(git branches) for release candidates and development code(bleeding edge). The code for module that gets auto-disabled is currently available in bleeding edge only.
Due to some technical constraints in our hosting platform we always have to deploy our release candidate first in to our development server(Dev) whenever we want to deploy our latest release candidate in to test server.
Very often we are seeing this issue after we deploy latest release candidate in to Dev server, then push it to test server from there, and later development version is restored in Dev server. Then we see that some modules got disabled automatically.
My assumption is that drupal is auto disabling modules when it cannot find code for a module.
Is my assumption correct?
If "Yes", where in drupal core can I find the code that is auto-disabling missing modules?
& Is there any way I can permanently prevent drupal from doing this?
It sounds like this is a dependency issue. When a module is disabled that may be depended on by other modules, those modules are also disabled. So lets say your custom module is depended on by other modules. Then when you disable your module, those modules are subsequently disabled.
If you look on the modules page, you'll see what depends on your module.
Related
We have a modular monolith application, each module being an extjs app. Modules share alot of features / functionality, therefore the most of code is sitting in a common extjs package that gets imported into each module, the module themselves are relatively thin. We also provide an accessibility build, ie., everything is built at least twice (once with normal theme, once with high contrast), but for some apps more (some logic is managed through extjs macros to exclude / include different regions at build time).
The end result is agonizing build time. ~10 apps, each built at least twice, each build lasting just under 2 minutes. It's all because each app is built from scratch. Is there a straightforward means to build it together? So that instead of rebuilding extjs code / common package code / themes 10 times, it would be just built once and reused in build process of all apps?
This looks very relevant "saving and restoring sets" . But it seems to be some lower level feature, which would as far as I understand it come useful if we were reimplementing build process from scratch and tossing out app.json. Is there a clear way how to incorporate it into existing higher level features like sencha app build?
You could go ahead and build the packages (if any) separated from the application, then drop the packages in the owning directories of the build. However, Sencha CMD and the way the class system and resolving the dependencies works makes it really hard to untangle the build process, so it's hard to give a general advice here.
You might want to look into the package loader of Ext JS and the "uses" configuration option for the app.json.
I have just started a new site where I am using 2sxc version 11.11.4 (started with 11.7.3 and upgraded to see if that would fix it). I have the data and views set up just like I have done on another site using version 10.25.2. On the newer version though, I'm unable to use the remove button/action. I did some searching and found a few references to adding lines to the web config file (https://github.com/2sic/2sxc/issues/1654, https://github.com/2sic/2sxc/issues/2205). I tried this and it worked great.
So, my question: will a fix be implemented for this or will we have to add these lines of code to the web config file on any site we use 2sxc on?
Also, could these lines of code affect any other DNN features, other modules, etc.?
I think you are talking about my solution here
https://github.com/2sic/2sxc/issues/2205#issuecomment-705647892
This is specific to a server where the WebDAV features have been added/enabled in Windows. I do not think its an issue that can or will be fixed in 2sxc.
I do know that it is safe to add those two items in web.config. All its doing is telling ASP.NET to NOT make WebDAV available in this application's (DNN's) context. I am not aware of any DNN feature or modules that need or use WebDAV. Its just something handed down from the server because its installed and its causing a weird change in behavior that makes the DELETE (and other) command types get ignored (IMHO, presumably because they are handled before they get to DNN).
What is the best way to dynamically provide configuration to a vespa application?
It seems that the only method that is talked about is baking configuration values into the application package but is there any way to provide configuration values outside of that? ie are there cli tools to update individual configuration values at runtime?
Are there any recommendations or best practices for managing configuration across different environments (ie production vs development) ? At Oath/VMG is configuration checked into source control or managed outside of that?
Typically all configuration changes are made by deploying an updated application package. As you suggest, this is usually done by a CI/CD setup which builds and deploys the application package from a git repository whenever that changes.
This way it is easy to ensure changes have been reviewed (before merge), track all changes that have been made and roll them back if necessary. It is also easy to verify that the same changes which have been deployed and tested (preferably by automated tests) in a development / test environment are the ones that are deployed to production - because the same application package is deployed through each of those environments in order.
It is however also possible to update files in a deployed application package and create a new session from this, which may be useful if your application package has some huge resources. See https://docs.vespa.ai/documentation/cloudconfig/deploy-rest-api-v2.html#use-case-modify
I'm about to start a pretty huge project.
This project is a website.
The backend will be made with Node
The frontend will be made mostly with Angular
Backend is going to be an API (which is cool with Angular) but also (later) for an Android app.
Frontend is going to be a fork of this repo : https://github.com/maxime1992/webTemplate and I want to be able to pull from upstream to keep the fork up to date.
I am wondering. How should I manage it?
Should I create only one repo, containing back and frontend with Git submodule or subtree.
Should I create two separated repos, one for the frontend, one for the backend and then use symlink to have them together? But if someone wants to run it on Windows ... Too bad.
I want this project to be open source on GitHub so I would like to have something clear and easy for everyone :)
Tell me how you would do it, what's good, what's wrong ... I'm really curious!
As indicated in the comments, Git submodules (or Git subtrees) are not the right solution for this. Use a dependency management tool for this, which will work cross-platform (Linux, Mac, Windows), and is the standard way of doing this.
Separating your backend and frontend into separate projects is a good idea, as it will allow you to manage projects independently and add functionality or additional client applications later without bloating your application.
Since you're already using Angular for the frontend, I suggest you take a look at Bower, which is the de-facto standard dependency management tool for frontend projects. It allows you to define a bower.json file to define your dependencies, e.g. Angular and other frontend libraries, allowing you to assemble your frontend project without having to download and store libraries manually.
In your backend project, you would then also add a bower.json file which declares your frontend project as a dependency by pointing to its Git location and branch. Bower will then take care of downloading your frontend project and adding it into your backend project.
Check out some of the popular Bower tutorials for more info on this...
You can use bower link to automatically create symlinks between your projects - this will work across operating systems as well.
Some other tools that you might want to check out:
Yeoman for scaffolding a base project. There are some nice generators for scaffolding Angular projects, including things like LESS/SASS and Bootstrap (https://github.com/yeoman/generator-angular)
Wiredep for automatically wiring your Bower dependencies into your index.html file.
Getting your initial project setup right will be important. You can start small and grow things to a more advanced configuration later.
I'm trying to divide my solution by three configurations:
Development
Testing
Release
All above will have different publishing location, so users can work with release, do their test in testing and see what is new in development release. All three versions will be build with different name postfixes and icons and installed on each user workstation.
For now I get :
Unable to install this application because an application with the
same identity is already installed. To install this application,
either modify the manifest version for this application or uninstall
the preexisting application."
I can't even install this more than once at one workstation.
So What can I do to achive this?
You can not install the same application multiple times unless you change the deployment. The easiest way to do this is by changing the assembly name. This article explains this.
As time past, I can now see that the solution was quite close, just required me to be able to specify my requirements first.
So, now I can tell that it mostly depends on number of such configurations:
if it is limited and low, i.e. live/test/dev, you can have each as separate project in solution, like AppLive, AppTest, AppDev, this requires refactoring to move everything that is common into separate projects, but it makes code and releases clearer and easier to manage.
if those configurations are unlimited, or number is high, than way to go is to load configurations from file and pick one from the pool based on custom logic.
Currently I'm using mix of both, as I want to be able to release test versions earlier than live, but also my application is used by multiple branches, and each of them has some unique styling, logos and such, so this is applied from embed xml file, and proper set is identified based on Active Directory entries.