- This topic has 6 replies, 3 voices, and was last updated 5 years, 2 months ago by
.
-
Posts
-
-
-
@xeiter– Welcome to the Piklist community!
The built-in WordPress demos are an add-on that has their own parts directory:
piklist/add-ons/piklist-demos/parts/meta-boxes/some-file.phpYou can add another like this:
piklist/add-ons/another-add-on/parts/meta-boxes/another-file.php -
Thank you, Steve – I will check it out!
…and I am really glad that Piklist is not dead. When I saw that other thread I was like… OMG…. all good whew.. offtopic anyway (https://piklist.com/support/topic/is-it-true-that-piklist-is-dead/).
Thank you for your answer.
Kind regards,
Anton -
Hi again Steve,
ok I had a look and unfortunately, unless I don’t understand it correctly, you were talking about Piklist addons and I was talking about addons of my plugin.
Basically, here is the set up I have in my plugin. My plugins has:
1) “Plugin Type: Piklist” in the comments section to get it working with Piklist
2) /vendor directory that holds Piklist framework source code
3) /parts directory that by default holds all the Piklist partsI also have
/src/Addonsdirectory and that’s the directory that has my plugins addons (not Piklist addons)./src/Addons/AddonName1
/src/Addons/AddonName2
/src/Addons/AddonName3Under each of the directories above I’d like to have
partsdirectory and only “activate” those parts if my addon, “AddonName1” for example, is “activated” within my plugin (not using addon activation functinoality that Piklist provides).Basically I am seeking a way to breakout of the Piklist path conventions for parts and addons and have the
partsdirectory sit in each of my plugins addons directory:/src/Addons/AddonName1/parts
/src/Addons/AddonName2/parts
/src/Addons/AddonName3/partsApologies if I confused you. I maybe on the wrong path here. The reason I want it this way is that I am building a plugin that allows to activate/deactivate features and each feature would use Piklist.
Kind regards,
Anton -
@xeiter– Unfortunately, that’s not how Piklist works. The folder structure is pretty important.
A few things;
1) When you say add-ons, what do you mean? With Piklist, add-ons are like the built-in Demos.2) You should NOT INCLUDE PIKLIST IN YOUR PLUGIN. I typed that in all caps for a reason… it’s super important. We don’t approve of it, and never will. Here’s why >
Hope that helps.
-
@Steve, thank you for picking up the issue of having Piklist included in my plugin – I will refactor.
Re: your question 1) when I say Addons I do not mean Piklist addons. I mean my own plugin addons (let’s call them “Features” instead).
I am building a plugin that would get administrators to enable/disable features through the their own WP admin interface (kind of like Piklist Addons or WP Plugins). It uses PSR4 for its folder structure and each Feature sits inside /src/Feature directory. I am using Piklist as a framework for defining CPTs, metaboxes, setting pages etc. – some tihngs are plugin wide definitions and some are Feature specific.
My thinking here was to get each Feature to be incapsulated into its own directory /Features/Feature-1 and that would include the “parts” directory where I would define stuff only related to the particular Feature.
It’s a not a big issue though. if I can’t have it this way, I will re-think how I would use Piklist here.
Kind regards,
Anton -
Hi @xeiter!
I believe I understand that you’re hoping to have sub-directories for say, meta-boxes. So you’d have /parts/meta-boxes/feature/ and /parts/meta-boxes/foo/ as hypothetical directories. If that’s the case, then unfortunately Piklist doesn’t recursively navigate sub-directories out-of-the-box. You could, however, use hooks in the
piklist::process_partsmethod to make this possible. In fact you’d probably end up using those hooks anyway to enable/disable parts (i.e. meta-boxes, terms, settings, etc.) on your own terms.Hope this helps! 🙂
-
- You must be logged in to reply to this topic.