Forum Replies Created

Viewing 15 posts - 61 through 75 (of 113 total)
  • Author
    Posts
  • in reply to: Maintain State Between Workflow Tabs #1292
    Marcus
    Member

    Just wanted to update this, now that I have a keyboard and not a phone keyboard to write this.

    In any metabox (or any piklist part) you can add HTML.

    So

    ?>
    <script>
    var currentstep=1;
    </script>
    <?php
    

    Would setup a var for that metabox. (or tab)

    Then you can just setup a simple javascript check in the same metabox if you wanted to check against the current step:

    ?>
    <script>
    jQuery(".metabox-holder h2 a.nav-tab").click(function (e) {
    e.preventDefault();
    e.stopPropagation();
    if (currentstep==1 && jQuery(this).attr('href').indexOf('&flow_page=nextsteptabname')) { 
    alert('please save the tab you are on currently before moving on');
    return false;
    }
    });
    </script>
    <?php
    

    Tada, simple step checking. (obviously you can get a lot more detailed, but its all very easy using piklist)

    Marcus

    in reply to: Maintain State Between Workflow Tabs #1291
    Marcus
    Member

    If you’re going to use an alert. I’d set a JavaScript var in each of your piklist metaboxes that states what step your in. Then use a simple if statement to determine if they should go to the next tab not. (Capturing the click event for when they click on a tab)

    in reply to: themes folders and dropbox #1284
    Marcus
    Member

    Whoops.
    Forgot to add something to the replace:

    str_replace('/piklist','',self::$paths['theme'])

    Should read:

    str_replace('/piklist','/',self::$paths['theme'])

    Missed the ‘/’ from the str_replace

    Marcus

    in reply to: Maintain State Between Workflow Tabs #1283
    Marcus
    Member

    Two suggestions:
    1. Use the post hooks in piklist to move your user to the next tab AFTER they publish or save their work.
    2. Use transients, and hook into the post hooks of piklist.

    As they post/publish (actually save) their work, the tabs could then load automatically to the next tab, and you could keep the previous work by keeping it in transients, or even better, once they post, its just kept in the post_meta tables and you can retrieve it as you need too.

    Just a thought.

    Marcus

    in reply to: Created New Field (Heirarchical Taxonomy Select List) #1274
    Marcus
    Member

    Sure thing.

    Just please remember this is buggy and was my first attempt at creating a new field.

    But you’re welcome to play with it.

    The code for the piklist field is:

    piklist('field', array(
        'type' => 'taxonomy-all'
        ,'scope' => 'taxonomy'
        ,'label' => 'Choose Camp Categories'
        ,'field' => 'mae_merch_sett_cats'
        ,'template' => 'field'
        ,'catname' => 'campcats'
        ,'add_more' => true
    ));

    The field file, which needs to put in piklist/parts/fields/ folder is:
    https://gist.github.com/anonymous/8133544

    And the walker class that builds the checkbox list and is just an include in your field file is at:
    https://gist.github.com/anonymous/8133566

    If you have any luck getting it fixed please post.

    Thanks

    Marcus

    in reply to: Custom Post Type question #1255
    Marcus
    Member

    Just so we are on the same page, what type of structure are you doing this in?

    If its within a theme, then you need to have your meta boxes inside that theme folder structure, such as:

    /themes/themename/parts/meta-boxes/custom-post-type-name.php

    Or if its inside a plugin, then the same concept, just different location for your parts folder:

    /plugins/pluginname/parts/meta-boxes/custom-post-type-name.php

    If you’ve done that for plugins, but aren’t having any luck, please make sure to include the PLUGIN TYPE parameter inside your plugin file, so inside:

    /plugins/pluginname/pluginname.php

    Make sure it has the following structure.

    /*
    Plugin Name: My Plugin
    Plugin URI: http://myplugin.com/helppage
    Description: This plugin does stuff
    Version: 1.0
    Author: Marcus Eby
    Plugin Type: Piklist
    Author URI: www.marcuseby.com
    License: GPLv2
    */

    Notice the non-standard line “Plugin Type” that will make sure the meta boxes activate.

    Hope that helps.

    Marcus

    in reply to: add_more field focus bug (Firefox 25.0.1) #1252
    Marcus
    Member

    Hi Mark, same problem was already talked about here:
    http://piklist.com/support/topic/bug-add_more-not-working-in-settings/

    Using the same solution you found. So way to go.

    Marcus

    in reply to: Radio problem. #1249
    Marcus
    Member

    Unfortunately I really should have tested things out, before trying to roll this out to the client.

    I’m in a bit of a dilemma.

    What I said above, is inaccurate.

    Checkboxes DON’T work if the group has a named field and there is more than 1 choice. At least for me.

    I’ve tried everything, but still anything NON-FIELD related, radio, checks, don’t work in groups properly if there is more than 1 choice.

    As happens with the following code:

    
    piklist('field', array(
    	'type' => 'group'
    	,'add_more' => true
    	,'scope' => 'post_meta'
    	,'label' => 'Week Bookings'
    	,'field' => 'mae_sched_weeks'
    	,'description' => 'Here you can book each week individually and set the number of days for that week.'
    	,'columns' => 12
    	,'attributes' => array (
    	)
    	,'fields' => array (
    		array (
    			'type' => 'select'
    			,'field' => 'mae_sched_choose_week'
    			,'label' => 'Choose Week'
    			,'attributes' => array (
    				'class' => array (
    					'chooseweek'
    				)
    			)
    			,'columns' => 6
    			, 'choices' => piklist(
    				$wpdb->get_results("SELECT 
    				w.ID AS weekID, CONCAT('Week ',w.menu_order, ' (',REPLACE(wc1.meta_value,', ".$weekyear."',''),' - ',wc2.meta_value,')') AS weekTitle 
    				FROM {$wpdb->prefix}posts w
    				LEFT JOIN {$wpdb->prefix}posts wp ON wp.post_title='".$weekyear."' AND wp.post_type=w.post_type
    				LEFT JOIN {$wpdb->prefix}postmeta wc1 ON w.ID = wc1.post_id AND wc1.meta_key='mae_wks_start_week'
    				LEFT JOIN {$wpdb->prefix}postmeta wc2 ON w.ID = wc2.post_id AND wc2.meta_key='mae_wks_end_week'
    				WHERE w.post_parent = wp.ID AND w.post_type='weeks'
    				ORDER BY w.menu_order"), array("weekID","weekTitle")
    			)
    			,'on_post_status' => array(
    			  'value' => 'lock'
    			)
    		)
    		,array (
    			'type' => 'checkbox'
    			,'field' => 'mae_sched_act_days'
    			,'' => 'post_meta'
    			,'label' => 'Select Active Days'
    			,'value' => array (
    				'2','3','4','5','6'
    			)
    			,'attributes' => array (
    				'class' => 'text'
    			)
    			,'position' => 'wrap'
    			,'choices' => array(
    				'1'=>'s'
    				,'2'=>'m'
    				,'3'=>'t'
    				,'4'=>'w'
    				,'5'=>'t'
    				,'6'=>'f'
    				,'7'=>'s'
    			)
    			,'columns' => 6
    			,'on_post_status' => array(
    			  'value' => 'lock'
    			)
    		)
    	)
    ));
    

    I’ve checked and there are no duplicate field names, and I think I’m using the fields properly. 🙂

    Any chance that an update is coming, as these things are quite critical for me right now.

    Thanks Guys.

    Marcus

    in reply to: Radio problem. #1247
    Marcus
    Member

    Just wanted to give you guys an update in case you were looking at this.
    I’ve gone through the class-piklist-form.php file.

    For the other two scenarios, a radio button inside a grouped piklist function, with a field value, and the radio button on its own, in its own piklist function, we’ll call scenario 1.

    Scenario 2 is a radio button inside a grouped piklist function WITHOUT a field name set.

    So going through the file, I can see where the $field is being built, is where things seem to breakdown, by the time, get_field_value is executed, the $field[‘template’] has changed to $field[‘template’] = ‘field’ instead of $field[‘template’] = ‘radio’ (explaining why all my normal fields aren’t affected by this, only the radio button) So even though its set to ‘radio’ in the arguments, it changes to ‘field’ by the time the field vars are built.

    I’m not quite sure why this change happens, but its like I said, it doesn’t if the group has a named field (which means it automatically arrays all fields within it, which is not what I want, but I do want the visual grouping and organizing aspect, so I need to use it without the field name)

    hope this helps.

    Marcus

    in reply to: Radio problem. #1246
    Marcus
    Member

    I should have added. That the field itself has a field name. Just the outer group doesn’t. And every other control within that group does save properly.

    Marcus

    in reply to: Field simply not showing up! #1235
    Marcus
    Member

    Hey Adam, my bad, that should have read:
    get_post_meta(get_the_ID(), 'rs_ID', true);

    To get just a single var, false is for an array.

    Sorry about that.
    Too quick with the fingers, too fast for my brain.

    Marcus

    in reply to: Meta Box pull data from another CPT? #1232
    Marcus
    Member

    Kevin, so if I understand you and the demo correctly…

    I create a parent in my parents CPT.
    For the children’s CPT, I select the parent through a post-relate field. (how do I turn this into a select box)
    Now to show the different children in the parents screen, would be as simple as duplicating the code you used in the field-relate.php file below the meta box and changing the args too:

        $args = array(
          'post_type' => 'children'
          ,'post_belongs' => $post_id
          ,'posts_per_page' => -1
          ,'post_status' => 'publish'
        );
    

    Jess, No? Am I close?

    Marcus

    in reply to: Field simply not showing up! #1227
    Marcus
    Member

    To get a piece of meta data from the backend try this:

    $datavar = get_post_meta(get_the_ID(), 'rs_ID', false);
    

    So for the example above, on the back end, I have a meta box on all pages.
    When I set the rs_ID field to something, I can retrieve it on the front end page, by using get_post_meta();
    By passing the post id ‘get_the_ID()’ (in this case the page I’m on) and the field I want ‘rs_ID’ and finally whether or not its an array (in this case false, just one piece of data)

    Now when I use:

    echo($datavar);
    

    I would see only the saved data inside rs_ID from my meta box.

    Make sense?

    Marcus

    in reply to: Plugin vs. installing into theme #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

    in reply to: Plugin vs. installing into theme #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

Viewing 15 posts - 61 through 75 (of 113 total)