I a trying to write an extension for Bolt CM. I decided I should start by just doing the tutorial they provide, although I can't get it to work. When viewed on the "Extend"-page in the CMS itself the extension shows up but does not work. Instead, it shows local/author/urlfield — [INVALID] — [DISABLED].
I'm quite sure that the problem is located in the extensions/composer.json file. I added the namespace of my extension to the "require" array (second from above):
"require": {
"sahassar/gmaps": "^4.0",
"myname/myexension": "^1.0",
"larsvanscheijndel/urlfield": "^1.0",
"wikimedia/composer-merge-plugin": "^1.3"
}
If I change the name of the extension in this file, it changes in the CMS aswell.
I really can't find where to use namespaces, where to use file locations, and whether to use all lower case, camel case or any other type of casing.
Can anyone help? All input is appreciated.
Related
i discovered a problem with custom fields. I installed the multi select plugin (https://www.npmjs.com/package/strapi-plugin-multi-select) and its showing up in the admin dashboard via general -> plugins.
In the content type builder when i want to create a new field and i click on "custom" the multi select field is not showing up for selection. I tried it with different other custom field plugins and none is working.
I sadly don't get any error, maybe someone here experienced the same issue 🙂
my dependencies looks like this:
"dependencies": {
"#strapi/plugin-graphql": "4.5.0",
"#strapi/plugin-i18n": "4.5.0",
"#strapi/plugin-users-permissions": "4.5.0",
"#strapi/strapi": "4.5.0",
"better-sqlite3": "7.4.6",
"dayjs": "^1.11.6",
"deep-rename-keys": "^0.2.1",
"deep-rename-keys-ts": "^1.0.1",
"geographiclib": "^1.52.2",
"geographiclib-geodesic": "^2.0.0",
"graphql-type-json": "^0.3.2",
"nexus": "^1.3.0",
"pg": "^8.8.0",
"strapi-plugin-country-select": "^1.0.0",
"strapi-plugin-multi-select": "^1.1.0",
"strapi-utils": "^3.6.11"
}
Thanks in advance for any help!
So i found a solution to solve the symptoms of the problem, not the root cause.
It somehow has to to with a webpack error i'm experiencing when building the project:
No inputs were found in config file 'tsconfig.json'
Well there were inputs, which is kinda strange.
After trying to fix the upper bug and deleting different directories .cache .tmp .dist .node_modules, package-lock.json, and even the project folder itself. I tried to re-clone, re-install and re-build.
Nothing seemed to help EXCEPT to clone it into another directory than i usually store my repos.
My webpack error was gone and i could install and use the plugins without hassle!
I don't know if someone ever will experience the same error, but this solved the symptoms and i could get back to work ;)
You need to rebuild your strapi after plugin installation. This is the same for all plugins in Strapi CMS please go to your strapi folder and run
yarn build then yarn develop
I'm quite new to this VueJS things. And this is my first App creating a SPA with separated server-side app. I faced the problem right before deploying my app on a shared hosting. Simply, when i run "npm run build", it return with an error in which i don't even know the cause. Here is the error i faced.
first img
second img
Please help me resolve this issues, i know there are jquery errors, but i think those are not the problems
You have es-lint checker. It checks unused vars so you have unused variables inside these listed components like from and to. You should remove these variable from your components.
Those errors come from your linter (probably eslint) which is a tool designed to ensure consistence and code quality : in your case it mainly complains about declared variables that are not used anywhere else in your code and $ being undefined (I guess you're trying to use jquery which you should not be doing in a vue project anyway)
On the images you posted you have all necessary infos : the title of each block tells you in which file the error is (for example App.vue in the first image) and then you have line/column to locate precisely where you need to adjust :)
Note that you can configure your linter (what should be error/warning/skipped out) overwriting (or creating if it doesn't exist) a config file at the root of your project (if you use eslint for example, you can create a .eslintrc file). See the config part of the official doc
On a project I'm working on, I need to update Imagemagick to at least 7.0.8, in order to have support for HEIC I'm uncertain how to do that, though.
In my composer.json file, I have this:
"require": {
"laravel/framework": "4.2.x-dev",
"intervention/image": "dev-master",
--- rest of composer.json ---
According to phpinfo(), that gets me ImageMagick 6.7.7-10.
I'm uncertain how to proceed to update ImageMagick (both locally, and eventually to the production environment) to the version I need.
I guess, first I need to ask, is this even possible under Laravel 4? (If it's not, then the rest of this becomes a moot point, because the project scope doesn't allow for the time to update the entire project to Laravel 5.)
If it is possible, what am I missing? Is there a simple package I can add?
Edit: This project is using PHP 5.6
When I run my Workspace on the simulator I get the message
"Class PFFile/ PFLogger is implemented in both (Path) and (Path). One of the two will be used. Which one is undefined."
I don't know how to solve this problem. I already tried cleaning and resetting.
objc[7398]: Class PFFile is implemented in both
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PhotoFoundation.framework/PhotoFoundation (0x11fdaf1b8)
and
/Users/Sven/Library/Developer/CoreSimulator/Devices/20F88AC5-6C5F-4492-8324-9205B54FB32C/data/Containers/Bundle/Application/8DD1D026-2D96-49E1-A485-6FCBD9899005/FitTip.app/Frameworks/Parse.framework/Parse (0x108c27408).
One of the two will be used. Which one is undefined.
objc[7398]: Class PFLogger is implemented in both
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PhotoFoundation.framework/PhotoFoundation (0x11fdaff28)
and
/Users/Sven/Library/Developer/CoreSimulator/Devices/20F88AC5-6C5F-4492-8324-9205B54FB32C/data/Containers/Bundle/Application/8DD1D026-2D96-49E1-A485-6FCBD9899005/FitTip.app/Frameworks/Parse.framework/Parse (0x108c279f8).
One of the two will be used. Which one is undefined.
Cause
You're seeing this error because both Parse and PhotoFoundation have files named PFFile and PFLogger. In Objective-C, your program cannot have two classes that share the same class name. This is part of the reason why Apple advocates using a three letter prefix for your own class names. Apple's own frameworks always use two letter prefixes, hence PhotoFoundation related classes have a PF prefix.
Unfortunately in this case, Parse also chose to use the PF prefix across all of the classes in the library that they built. In isolation this won't cause a problem, but when other frameworks come into the picture there's a risk of namespace collisions (which is exactly what's happening here).
Solution
You avoid a namespace collision by simply making sure you don't use the same names. In your case, you don't own either of these classes so it's not as straightforward. Luckily this issue was already reported on the Parse SDK GitHub page and the fix was implemented on the latest version of the Parse SDK (1.17.2). Parse's PFFile and PFLogger were renamed to PFFileObject and PFSystemLogger respectively.
You probably have an older version of the Parse SDK installed in your project. This can be verified by going into the root folder of the project and opening up Podfile.lock in any text editor. You can see what version of the library is currently installed by CocoaPods. Run pod update Parse and CocoaPods should update it to the latest version.
TL;DR pod update Parse. If that fails: pod repo update, pod install
Slightly different problem. Etrecheck pointed out this problem:
Class MDSPathFilter is implemented in both /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata (0x7fff9a7d1420)
and /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdbulkimport (0x10ad41948)
One of the two will be used. Which one is undefined.
I am not proficient in this stuff, but able to follow directions if anyone has any to share. They both look too important to poke at ...
I'm making a custom application using Laravel. By default Laravel generates a composer.json file like the following:
{
"name": "laravel/laravel",
"description": "The Laravel Framework.",
"keywords": ["framework", "laravel"],
"license": "MIT",
}
Is it good practice to change the name, description, license etc on my project?
More info: I am developing this project for another company. They will use it internally (as a public website) and may or may not hire a different developer in the future.
To be honest, changing it provides no real benefit unless you're planning to release the project as a composer projects that allows people to run composer create-project you/yourproject.
There's no real rule around changing if you plan to keep it internal only, but there are two arguments, one for and one against.
Changing it keeps it simple, and gives developers working on your project a nice little source to some basic information.
Keeping it as the default allows you and other developers to access some basic information about the systems creation.
So ultimately, it's entirely up to you.
Yes, you should edit it to reflect the current state. At least delete info that you don't want, like the MIT license (you probably don't want to license proprietary code that way), the keywords, description and name.
Maybe in the future, composer create-project will deal with it more properly (the source project needs to have a name to be identifiable, but creating a project almost never needs to keep that name) - but this also won't help you with existing projects.
Keep that meta data correct (at least delete incorrect data) - you never know the benefits. Personally, I hugely like having the right project names because that name gets displayed on my Satis pages as "projects using this package", i.e. the reverse dependency - so I know what to update if I change a library.