I have a task to override most of admin panel pages with custom, however I couldn’t do that.
I created the same directory structure as in strapi github repo for admin package, but nothing happened
src
├── extensions
│ ├── admin
│ │ └── admin
│ │ └── src
│ │ └── pages
│ │ └── HomePage
│ │ ├── ContentBlocks.js
│ │ ├── HomeHeader.js
│ │ ├── index.js
│ │ └── SocialLinks.js
│ └── content-manager
│ └── strapi-server.js
├── index.js
├── plugins
└── themes
└── override.cs
Update 03/08/2022
It looks like Strapi team decided to remove customization options in v4, so if you want to override something like dashboard pages you'll have to use patch-package
There is a complete section in the official docs called Admin panel customization.
According to the docs, you can do a lot of customization options, which are:
Customizing the admin panel is helpful to better reflect your brand identity or to
modify some default Strapi behavior:
The access URL, host and port can be modified through the server configuration.
The configuration object allows replacing the logos and favicon, defining locales and extending translations, extending the
theme, and disabling some Strapi default behaviors like displaying
video tutorials or notifications about new Strapi releases.
The WYSIWYG editor can be replaced or customized.
The forgotten password email can be customized with a template and variables.
The webpack configuration based on webpack 5 can also be extended foradvanced customization.
Related
I'm having some issues creating unit tests for my Puppet control repository.
I mostly work with roles and profiles with the following directory structure:
[root#puppet]# tree site
site
├── profile
│ ├── files
│ │ └── demo-website
│ │ └── index.html
│ └── manifests
│ ├── base.pp
│ ├── ci_runner.pp
│ ├── docker.pp
│ ├── gitlab.pp
│ ├── logrotate.pp
│ └── website.pp
├── role
│ └── manifests
│ ├── gitlab_server.pp
│ └── nginx_webserver.pp
Where do I need to place my spec files and what are the correct filenames?
I tried placing them here:
[root#puppet]# cat spec/classes/profile_ci_runner_spec.rb
require 'spec_helper'
describe 'profile::ci_runner' do
...
But I get an error:
Could not find class ::profile::ci_runner
The conventional place for a module's spec tests is in the module, with the spec/ directory in the module root. So site/profile/spec/classes/ci_runner_spec.rb, for example.
You could consider installing PDK, which can help you set up the structure and run tests, among other things.
In our project we create docker images, push to registry using fabric8 maven plugin. We have a requirement in which we need to find out the details of each image (name, tag , registry pushed to etc) that gets created in the project build.
Is there any out of the box solution in fabric8 for that ? or do we have any java API's of fabric8 available which we can use and integrate in our existing maven plugin to get such info?
As far as I know, there is no way to get such info from the plugin itself. But when building Docker images with fabric8's docker-maven-plugin, a hierarchy like the following is created on the target/ folder by default :
target
├── docker
│ ├── build.timestamp
│ └── my
│ └── registry
│ ├── image1
│ │ ├── tag1
│ │ │ ├── build
│ │ │ │ └── Dockerfile
│ │ │ ├── tmp
│ │ │ │ └── docker-build.tar
│ │ │ └── work
│ │ └── tag2
│ │ ├── build
│ │ │ └── Dockerfile
│ │ ├── tmp
│ │ │ └── docker-build.tar
│ │ └── work
│ ├── image2
│ │ ├── tag1
│ │ │ ├── ...
... ... ... ...
In this example, 3 images were built :
my/registry/image1:tag1
my/registry/image1:tag2
my/registry/image2:tag1
So browsing this hierarchy can inform you about the images names, tags and registries. I agree that it is not the cleanest solution.
Alternatively, you can use spotify's dockerfile-maven-plugin (https://github.com/spotify/dockerfile-maven), because it creates a docker-info JAR containing what you're looking for :
META-INF/
META-INF/MANIFEST.MF
META-INF/docker/
META-INF/docker/my/registry/
META-INF/docker/my/registry/image1/
META-INF/docker/my/registry/image1/image-name
META-INF/docker/my/registry/image1/repository
META-INF/docker/my/registry/image1/tag
META-INF/docker/my/registry/image1/image-id
META-INF/maven/
META-INF/maven/my/registry/
META-INF/maven/my/registry/image1/
META-INF/maven/my/registry/image1/pom.xml
META-INF/maven/my/registry/image1/pom.properties
This docker-info JAR could then be put into a repository manager to help retrieving information about built images, and moreover to version your different builds.
So I have:
buildSrc/
├── build.gradle
└── src
├── main
│ ├── groovy
│ │ └── build
│ │ ├── ExamplePlugin.groovy
│ │ └── ExampleTask.groovy
│ └── resources
│ └── META-INF
│ └── gradle-plugins
│ └── build.ExamplePlugin.properties
└── test
└── groovy
└── build
├── ExamplePluginTest.groovy
└── ExampleTaskTest.groovy
Question:
It seems like build.ExamplePlugin.properties maps directly to the build.ExamplePlugin.groovy. Is this the case? Seems terribly inefficient to have only one property in the file. Does it have to be fully qualified, i.e. does the name have to exactly match the full qualification of the class?
Now in the example, I see:
project.pluginManager.apply 'build.ExamplePlugin'
...however if I have that in my test, I get an error to the effect that the simple task the plugin defines, is already defined.
Why bother with test examples that require 'apply' when that is inappropriate for packaging?
I'm new to Xcode and just found out that it stores a bunch of user information and other stuff in the project directory that I don't really need in version control or want to put up on Github.
This is what an Xcode project basically looks like:
1 AppName/
2 ├── AppName
3 │ ├── Base.lproj
4 │ │ ├── LaunchScreen.xib
5 │ │ └── Main.storyboard
6 │ ├── Images.xcassets
7 │ │ └── AppIcon.appiconset
8 │ │ └── Contents.json
9 │ ├── AppDelegate.swift
10 │ ├── Info.plist
11 │ └── ViewController.swift
12 ├── AppName.xcodeproj
13 │ ├── project.xcworkspace
14 │ │ ├── xcuserdata
15 │ │ │ └── user1.xcuserdatad
16 │ │ │ └── UserInterfaceState.xcuserstate
17 │ │ └── contents.xcworkspacedata
18 │ ├── xcuserdata
19 │ │ └── user1.xcuserdatad
20 │ │ └── xcschemes
21 │ │ ├── AppName.xcscheme
22 │ │ └── xcschememanagement.plist
23 │ └── project.pbxproj
24 └── AppNameTests
25 ├── AppNameTests.swift
26 └── Info.plist
My inclination is to just commit the AppName/ and AppNameTests/ and exclude the AppName.xcodeproj/ directory. What's the recommended way of doing this?
You'll want to use a .gitignore file to specify which files you don't want to store in GitHub.
Here is how to create the file, and here's what should go in that .gitignore file.
A better question is what should go in my git ignore file. This is a link to the github repo containing the file you need
https://github.com/github/gitignore/blob/master/Global/Xcode.gitignore
Make sure u start with this file so the files are properly ignored because if you don't some files my be added already and you will have to manually remove them.
The "recommended way" really depends on what you want to do with the project. Typically, there are three choices:
check-in only those files which are necessary to build the project
add files that reflect development customizations (such as project files that store the names of the currently-visible files in editors)
generated files, to make a complete snapshot of the project state.
With the last, you can get into problems with timestamps (while git can be told to know something about commit-times — see Checking out old file WITH original create/modified timestamps — few people do it). Without a system that retrieves files using their original timestamps, you end up with a set of files that demand recompilation each time you do a commit.
Even saving the customization files can be problematic, if you move the files to another part of the filesystem (or attempt to share the files with others).
So... use .gitignore to filter out files not needed to build. But check that you can successfully build using a fresh checkout.
I am trying to create war hosting OSGi bundles. The complete configuration should be able to host WAB bundles, and now I try to integrate pax-web-extender-war for that.
It requires some dependencies like slf4j-api and slf4j-log4j12 and here is the problem: I always get this exception:
org.osgi.framework.BundleException: Fragment bundles can not be started.
at org.apache.felix.framework.Felix.startBundle(Felix.java:1782)
because slf4j-log4j12 is really a fragment bundle. I assumed Felix should cope with this but it does not. So I tried to move this jar to WEB-INF/lib but then wiring fails as osgi cannot resolve it as a bundle.
So,
Where should I put fragment bundles ?
Should it be somehow configured in framework.properties ?
is Apache Felix even capable of working with fragment bundles ?
Following is current layout of the war (note that it is based on felix http bridge sample):
.
└── WEB-INF
├── bundles
│ ├── commons-fileupload-1.2.2.jar
│ ├── commons-io-2.4.jar
│ ├── hello-wab-1-SNAPSHOT.war
│ ├── org.apache.felix.http.bridge-2.2.0.jar
│ ├── org.apache.felix.http.samples.filter-2.2.0.jar
│ ├── org.apache.felix.webconsole-4.0.0.jar
│ ├── pax-web-api-2.1.0.jar
│ ├── pax-web-extender-war-2.1.0.jar
│ ├── pax-web-spi-2.1.0.jar
│ ├── slf4j-api-1.6.6.jar
│ ├── slf4j-log4j12-1.6.6.jar
│ └── wrapper-json-1-SNAPSHOT.jar
├── classes
│ └── org
│ └── apache
│ └── felix
│ └── http
│ └── samples
│ └── bridge
│ ├── FrameworkService.class
│ ├── ProvisionActivator.class
│ └── StartupListener.class
├── framework.properties
├── lib
│ ├── org.apache.felix.framework-4.0.3.jar
│ ├── org.apache.felix.http.proxy-2.2.0.jar
│ ├── org.apache.felix.webconsole-4.0.0.jar
│ ├── org.osgi.compendium-4.3.0.jar
│ └── wrapper-json-1-SNAPSHOT.jar
└── web.xml
I suggest adding pax-logging to your bundles, it'll keep away the pain of logging in the OSGi world. Pax-Logging
For the fragment-bundles you just need to add them to the usual bundles. I'd say in your setup probably in the bundles folder. Since it's a fragment bundle the Exception you get is right, it's not a "startable" bundle. It will only resolve and hopefully attached to the hosting bundle.
By the way, Felix is capable of working with fragment bundles :)