Tagged: ,

Viewing 9 reply threads
  • Author
    Posts
    • #1214
      Marcus
      Member

      Hey 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

    • #1216
      Steve
      Keymaster

      Marcus– This is the only folder structure Piklist currently recognizes >

      Let us know if you think we can improve it.

    • #1217
      Marcus
      Member

      Steve 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

    • #1218
      Marcus
      Member

      Just 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

    • #1219
      Steve
      Keymaster
    • #1220
      Marcus
      Member

      Thanks 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.php

      Line 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

    • #1221
      Marcus
      Member

      SOLVED

      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

    • #1222
      Steve
      Keymaster

      Marcus–

      Based on your recommendation here>

      We added this:

          self::$paths[$type] = $path;        
          $path = str_replace(chr(92), '/', $path);
          self::$urls[$type] = plugins_url() . substr($path, strrpos($path, '/'));

      That doesn’t work?

    • #1223
      Marcus
      Member

      It 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

    • #1224
      Marcus
      Member

      By 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

Viewing 9 reply threads
  • You must be logged in to reply to this topic.