- This topic has 9 replies, 2 voices, and was last updated 8 years, 3 months ago by
Marcus.
-
AuthorPosts
-
-
October 31, 2013 at 9:40 pm #1214
MarcusMemberHey guys, I’ve got a small but relatively important issue that came up.
I am slowly converting all the theme work I’ve done for this current client into plugins, including piklist.
When I moved my meta-boxes out of the piklist/parts/meta-boxes folder and moved them into my plugin folder /addons/mae-registrations/parts/meta-boxes the boxes show up, but none of the fields do.I’m assuming this is because piklist doesn’t like the fact i’m not using /plugins/ as the plugin folder name, and rather using /addons/
But wanted to know if you or anyone else for that matter is having the same problems, and if you/they have a solution.This isn’t urgent, but it does allow me to make the process of updating the multisites easier when they are plugins. Short-term I just moved them back to the piklist folder.
Thanks guys.
Marcus
-
November 1, 2013 at 10:02 am #1216
SteveKeymasterMarcus– This is the only folder structure Piklist currently recognizes >
Let us know if you think we can improve it.
-
November 1, 2013 at 10:41 am #1217
MarcusMemberSteve I’m not disagreeing in fact I’ve done the folder structure exactly like you show. I’m saying in my config I’ve changed the name of my plugins folder not my plugin.
I feel it not being named plugins is causing the problem. Unfortunately it has to be a nonstandard name.
Marcus
-
November 1, 2013 at 12:01 pm #1218
MarcusMemberJust thought I’d explain it a little better so there is no confusion.
On a clean install of wordpress your default folders are:
/wp-admin/
/wp-content/
/wp-includes/And inside /wp-content/ their are standard folders as well:
/wp-content/plugins/
etc.I changed my /wp-content/ folder to /anothername/
and my /wp-content/plugins/ folder to /anothername/addons/
for security and client reasons.So when I moved everything from /anothername/addons/piklist/parts/meta-boxes/ (which is working brilliantly)
to /anothername/addons/mynewplugin/parts/meta-boxes/ (same folder structure as what you linked to above) I get the meta boxes, but none of the fields show up.So since I followed the correct pathing instructions as you linked to above, /plugin-folder/parts/meta-boxes/ I can only assume that it must be because of my changes to the /wp-admin/ folder name, and the /plugins/ folder name that this is happening. That’s just my guess. If it is correct, then somewhere the pathing is hardcoded or using an incorrect wp constant.
Sorry for the confusion Steve.
Marcus
-
November 1, 2013 at 2:28 pm #1219
SteveKeymasterDid you ever try this?
http://piklist.com/support/reply/reply-to-plugins-dir-renamed-wp_plugin_url-3/ -
November 2, 2013 at 2:41 am #1220
MarcusMemberThanks Steve. I changed that back from your original post, which fixed that previous problem but didn’t fix this one.
But I’ve somewhat found the problem. (just haven’t fixed it)
In file: class-piklist.phpLine 153, part of the render() function: ($view is one of the passed arguments)
If the plugin is inside the piklist folders:
The $view var when var_dumped shows the relative path to the file (just the folders)
'fields/show'If the plugin is within my plugin folder:
The $view var, shows the full path to the file, including the file name itself.
'C:/html/master/personal/ssgoverhaul/publichtml/pluginfoldername/addons/mae-weeks/parts/meta-boxes/weeks-test-metabox.php'So when $view is processed by the next part of the function:
$_file = (path_is_absolute($view) ? $view : self::$paths[$_display] . '/parts/' . $view) . (strstr($view, '.php') ? '' : '.php');It makes an unreachable path for $_file
Marcus
-
November 2, 2013 at 3:17 am #1221
MarcusMemberSOLVED
In class-piklist.php LINE 136:
In function add_plugin:
self::$paths[$type] = $path;The path for the plugin folder was being pulled via dirname(dirname(__FILE__))
Which on a local machine was producing the backwards ‘/’ which affected the paths throughout the code.
So changed the line to:
self::$paths[$type] = str_replace('/', '\\', $path);And all is good. Have to figure out a better way to load the proper path for the plugin than dirname(__FILE__) on a windows machine, as it always seem to cause problems.
Hope it helps someone else who has as weird a configuration as mine.
Marcus
-
November 2, 2013 at 6:45 pm #1222
-
November 3, 2013 at 3:37 am #1223
MarcusMemberIt should, if you move self::$paths[$type] = $path below the $path = str_replace(chr(92), ‘/’, $path);
Now all I should have to do, is move the self::$paths[$type] line 3 lines lower.>>UPDATE<<
No, turns out that didn’t work.The fields don’t show up and its not considered an absolute path.
Went back to my original SOLVE above, and voila. Working.Weird huh?
Marcus
-
November 3, 2013 at 7:26 am #1224
MarcusMemberBy the way, this change only solved things on my local machine. I didn’t change it on my remote, as it tends to break it. 🙂
For now, I’ve got it working on both, but I do hope you get a chance to look at it later.
It’s just a problem with pathing on a windows machine. I’m usng WAMP.Marcus
-
-
AuthorPosts
- You must be logged in to reply to this topic.