I wrote an extension and was wondering, if it is possible to have seperate settings in a multidomain environment.
As far as I can see, the extension configuration (defined via ext_conf_template.txt) is global per TYPO3 installation (compare TYPO3-docs here).
Is there a possibility to define them seperately for each domain, that is served by the (single) TYPO3 installation?!
(of course, there's a kind of workaround by defining them via typoscript and define them seperately in the root template of each domain, but I'd like to make the settings configurable with the nice built-in UI in the backend).
Related
Is it possible to create documentation of certain projects within the mkdocs framework?
I am aware of server deployment via mkdocs serve. We can also once the documentation reached a certain level we like perform mkdocs build and this will create a site folder, which we can in fact download locally and browse by opening the index.html file.
This approach however is not perfect, as every time we can switch a tab, it runs into a between step where we have to manually matches with another HTML page we are interested in.
Is it possible to save how save the entire mkdocs locally or as a pdf?
It must be for local usage but without a server approach.
According to documentation, you can set this values in mkdocs.yml configuration file:
site_url: ""
use_directory_urls: False
site_url must be set to an empty string if you want to use file:// scheme.
use_directory_urls should be set to false for links between pages to work correctly.
You also need to disable the search plugin or use another plugin, which supports file:// scheme.
Note: not every theme can display properly in offline mode.
It is well known that nextjs API routes provide a straightforward solution to build your API with Next.js. and that any file inside the folder pages/api is mapped to /api/* and will be treated as an API endpoint instead of a page.
I have just one doubt: is the code within the pages/api exposed to the world? I mean, can I build some logic there that has some key that must be hidden or maybe some MySQL connection?
Whether or not /api is in any way exposed to the world I do not know for sure, but according to Next documentation, "they are server-side only bundles."
In general though, for any key/sql connection that you want to run, I would put that into an .env.local file on your machine, a file that gets git ignored and never uploaded, and if you are hosting on Vercel, then use their environmental variables to store sensitive information.
You'd find environmental variables under:
{Your Account}/{Project}/Settings/Environmental Variables
p.s. Also from Next.js docs, I think you'd find this bit on getStaticProps useful.
Lets say I have a directory of .html files, accessible by the app server, and I want to display to users so they can access them with their browser:
/import/tps-reports/index.html
/import/tps-reports/report1.html
/import/tps-reports/report2.html
Is there a way I can expose the tps-reports directory to do this so that a user can access them via:
http://www.example.com/tps-reports/index.html
http://www.example.com/tps-reports/report1.html
Also, keep in mind that index.html may reference the other pages:
Report 1
So those links need to work as well.
Here is a possible answer:
http://docs.oracle.com/cd/E19776-01/820-4496/geqpl/index.html
You can set up an alternate doc root so that certain URI patterns point to different paths.
The examples are only really showing relative paths though...I wonder if its "ok" to use this to reference local file systems.
We have a SPA web application that we're trying to convert into a WinJS project as a native Windows Store app. For most part, the Javascript is working except for DOM manipulations deemed unsafe.
One thing that does not appear apparent is, how can the start page of the app (e.g. index.html) be supplied with query string and hash parameters? Our site main page is designed to behave differently based on parameters.
e.g. index.html?contextId=xxxxx#enviroment=xxxxx
I tried adjusting the value in package.appxmanifest to no avail. It will throw errors on query strings, and hash parameters will silently not persist.
UPDATE: Project background
A brief about what our app does, and then why the above naive desire won't work and the answer below how we went about this issue.
Our web app is a highly-dynamic data-driven application that completely relies on data to figure out what to render. Therefore the ?contextId=xxxxx parameter is so crucial as it tells our system to load the data which further informs what kinds of visual components to load and it goes on recursively to form wildly different UIs.
We were looking to therefore find some means to supply these parameters like traditional command-line parameters to the same executable to produce different UIs. And thus different "apps" by mere changes in those parameters. Like a "config transform" mechanism for web.config in ASP.NET web projects, that would be most welcome.
However further testing showed it is not possible; a single Windows store app project has a GUID that is supplied into the packaged app bundle. Building the same project multiple times with different "build config" would just mean overwriting a previous installation since they are the same app with increasing version numbers. The answer details how we went about this.
Windows Store apps don't work with URI parameters when launched from their primary tile. In that case, you should make sure that the app defaults to suitable values, e.g., if you were thinking to supply defaults in the manifest, then default to those in the app's activation handler for the ActivationKind.launch case when eventObject.detail.arguments is empty.
There are two other ways to launch an app that can supply other arguments.
First is to launch via a secondary tile. When you create the tile from the app (which is subject to user consent), you supply the launch arguments. In your activation handler, for ActivationKind.launch, those args will be in the eventObject.detail.arguments property.
Second is to launch the app through a URI association. You use a custom schema for this, which is declared in the manifest. The app will then see ActivationKind.protocol and eventObject.detail.uri will contain the full URI including any parameters. A URI launch can be done from another app, by entering the URI into a browser address bar, or through a shortcut that a user could configure on the Start screen.
The first step is to convert our Windows (8.1) Store project into a Universal app structure, which would then spin off a separate Windows Phone WinJS project (this is nice when we wish to target Windows Phone later) and a shared project.
Practically everything from the Windows Store project is moved to the shared project (including default.html or index.html). What remains in the Windows Store project is a customised config.js carrying the parameters
window.customWin8 = {
contextId: xxxxxxxxxx,
customParam: 'xxxxxxxxxx'
};
The downstream modules that sense for query string/hash parameters would then fall back to this alternative object if it exists to pick up the data it needs.
Now, for every differing app we wish to deploy, that would for now seem to require a separate Windows Store project so it gets its own GUID and won't conflict with other apps. All these projects would reference the very same shared project thanks to the Universal structure Visual Studio affords. The only down side is it seems Visual Studio 2013 does not have a direct UI method to make this referencing to the share project and has to be hand code into the jsproj file.
<Import Project="..\Common.Shared\Common.Shared.projitems" Label="Shared" />
With this adjustment they can all build and package with their isolated "build config".
I am working on many apps that uses RegFree COM Activation, everything works well except that one of the application is ran using an older technology that uses a JIT-type compiler.
To get RegFree COM working, i have to provide a manifest to the launching executable (correct me if i'm wrong) with my dependencies listed. All my other applications are built in-house and i have full control over my manifest (authoring and if i embed it, if i leave it Side-By-Side, etc). But this JIT-compiler (ala Java JRE) isn't mine and it already contains (embedded) a manifest.
I've extracted the manifest (using MT with -inputresource and -outfile), modified it and re-embedded it. It works like expected. However, having no ownership over this executable, i am worried about the legality of such a manipulation (modifying a third party's executable and redistributing it!) and would like to avoid having to do such a thing.
Also, i am worried that at some point this executable may be signed by the third-party and thus modifying the embedded manifest is going to break the signature.
Is there a way to have the sxs-loader look for another manifest first? It seems that if it finds one embedded, it takes it by default (which under most cases is fine).
Can i provide a configuration file or anything that would skip the embedded manifest and go for my side-by-side provided one (myExe.exe.manifest, instead of RT_MANIFEST resource inside myExe.exe) ?
You can only do that system wide as far as I know. Add that to the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PreferExternalManifest"=dword:00000001
Make sure to trip activation context cache by updating last modified date on your executable, otherwise your manifest changes won't be picked up (renaming and renaming it back seems to work).
On Win XP external manifest is preferred over internal, but since Windows server 2003 Service Pack 1 they changed it to opposite.