Skip to content
This repository was archived by the owner on Nov 6, 2019. It is now read-only.

Conversation

@vedanshujain
Copy link
Contributor

We can remove this once select2 is added to the core. By default it will not be loaded or enabled, an option to enable it is also added.

Copy link
Contributor

@iandunn iandunn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks really good, great job!

[ Doh, accidentally submitted half-way through review, I'll edit to make my notes more descriptive ]

wp_enqueue_style( 'camptix' );


if ( (bool) $this->options['select2_enabled'] ) {
Copy link
Contributor

@iandunn iandunn May 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need an option for this; adding it doesn't break backwards-compatibiliity, and I don't imagine many users wanting to disable it. Here's some more info on how we typically approach options:

https://nacin.com/2011/12/18/in-open-source-learn-to-decide/
https://wordpress.org/about/philosophy/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want a configuration because of accessibility (select2/select2#3744) . Looks like this is also the blocker for merging select2 in core. What do you think ? At the very least, we should enable by default.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. They could always call wp_dequeue_script() from a plugin to disable it, but I realize that'd require some development experience.

It sounds like one our coworkers has already forked Select2 to make it accessible, so maybe we should switch to that instead?

If you feel like it, it might even be good to send a PR to selectWoo to merge in the upstream changes. That'd help us by fixing any bugs that haven't made it downstream; help selectWoo users for the same reason; and eventually help WP Core and Drupal, by making it easy to merge the a11y fixes upstream.

In general we try to be good open source citizens, but of course it always has to be balanced against time spent on our own priorities. This seems like a really good opportunity, though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, rather than trying to merge downstream, maybe it'd be better to just cherry-pick commits from downstream and send PRs upstream? That may be more efficient, since any changes will need to be tested in either direction. Whichever you think is best :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have send in some PRs in wooSelect (woocommerce/selectWoo#18 and woocommerce/selectWoo#17) but it will take a while before they get merged. I want to wait till they get before we use wooSelect, since it doesn't have downstream changes, but we can use it right away as well. What do you think ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds like they'll be looking at it soon, so waiting is probably fine in this case. If it takes them longer than expected, then we can always go ahead and use the setup the latest master build now, and then update it after your PRs are merged.

camptix.js Outdated

/**
* Use select2 for dropdown
*/
Copy link
Contributor

@iandunn iandunn May 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the indentation is off a bit in a few places around this line.

camptix.js Outdated
/**
* Use select2 for dropdown
*/
$( document ).ready( function loadSelect2Country() {
Copy link
Contributor

@iandunn iandunn May 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The coding standards call for tabs instead of spaces.

We've got a custom phpcs.xml.dist file in Meta repo that describes the standards for WordCamp.org. Using phpcs makes it really easy to find any violations before committing. There's also a .githooks/pre-commit script in the Meta repo that you can use to automatically do PHP syntax checks, run phpcs, and run phpmd before committing.

I'd recommend setting those up, even if you only run them manually. It's a lot easier than memorizing everything at first, and more consistent.

@@ -0,0 +1,5746 @@
/*!
Copy link
Contributor

@iandunn iandunn May 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about using npm / package.json to register this as a dependency and include it, instead of manually bundling it?

That'd make it easier to get security notifications via npm audit and GitHub.

We'd still need to explicitly bundle it in the SVN repo, but that's no problem.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree that we should use npm. Lets wait for wooSelect, we can this push this as a separate change.

<label class="tix-yes-no description"><input type="radio" name="<?php echo esc_attr( $args['name'] ); ?>" value="1" <?php checked( $args['value'], true ); ?>> <?php _e( 'Yes', 'camptix' ); ?></label>
<label class="tix-yes-no description"><input type="radio" name="<?php echo esc_attr( $args['name'] ); ?>" value="0" <?php checked( $args['value'], false ); ?>> <?php _e( 'No', 'camptix' ); ?></label>
</div>
function field_enable_select2( $args ) {?>
Copy link
Contributor

@iandunn iandunn May 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kudos for doing coding standards fixes, and for doing them in a separate commit :)

The Development Practices doc has some helpful points on writing commit messages.

Use the imperative mood when possible: “Relax term ID comparisons…” instead of “Relaxes term ID comparisons…” [ from Core handbook ]

Something like Replace spaces with tabs., or just a generic Apply coding standards. would fit a little bit better.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably best to avoid updating the commit messages, rebasing, and force-pushing until we've finished reviewing everything else, though, since the force-push will wipe out a lot of the GitHub comments.

?>
<input type="hidden" name="tix_attendee_info[<?php echo esc_attr( $i ); ?>][ticket_id]" value="<?php echo intval( $ticket->ID ); ?>" />
<table class="tix_tickets_table tix-attendee-form">
<table class="tix_tickets_table tix-attendee-form <?php echo ( isset($this->options['select2_enabled']) && (bool) ( $this->options['select2_enabled'] ) ) ?
Copy link
Contributor

@iandunn iandunn May 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is one of the places we'd like to add it. It'd also be use it for the currency dropdown and the Summarize fields in wp-admin.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a separate patch for currency, since its not a part of camptix. Or am I confusing with a different currency dropdown ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. CampTix has a currency dropdown on the Tickets > Setup > General screen. The Summarize one is under Tickets > Tools.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok. Added.

@iandunn
Copy link
Contributor

iandunn commented May 28, 2018

I tested it locally and it worked well for me. I'll take a closer look at the code tomorrow, but those should give you a few things to look at.

We can remove this once select2 is added to the core. By default it will not be loaded or enabled, an option to enable it is also added.
@vedanshujain vedanshujain force-pushed the select2-registration-form branch from 0b4787b to e9542b0 Compare June 7, 2018 14:00
Copy link
Contributor

@coreymckrill coreymckrill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, the idea here is to add the Select2 lib in for now, and then switch it out for selectWoo once your PRs are merged?

If so, we should talk about that a bit more, it seems rather drastic to me...

I added a couple of minor inline comments, but otherwise this looks good 👍



if ( (bool) $this->options['select2_enabled'] ) {
wp_register_style( 'select2', plugins_url( '/external/select2/css/select2.min.css', __FILE__ ), array(), $this->version );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The version numbers used to register the stylesheet and script should be the version of Select2, not CampTix.

wp_register_style( 'select2', plugins_url( '/external/select2/css/select2.min.css', __FILE__ ), array(), $this->version );
wp_register_script( 'select2', plugins_url( '/external/select2/js/select2.min.js', __FILE__ ), array(), $this->version );

wp_enqueue_style( 'select2' );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noting here at that since the Select2 assets will always be both registered and enqueued if the option is enabled, you can save a step by just calling the enqueue functions with all the same parameters, and they will take care of the registration as well.

But I guess another question is, should the assets always be enqueued, or only for certain views?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants