WPEC Page Settings Tidy Up

[instinct]

Hey guys. I've started thinking about how to tidy up the WPEC settings.

I've put together a spreadsheet of how it might be changed. Probably the most obvious change is the removal of the Admin tab entirely and sharing those settings around - mostly into the General Settings tab.

Please note that the new Page settings is only available if you install the Theme Engine V2 Plugin.

https://docs.google.com/spreadsheet/ccc?key=0AoRXr-CdZKuEdG9vWWV2czlKdFBseEdwQTJYemxGRFE&usp=sharing

So what do you think????

I've protected my sheet but feel free to duplicate the sheet and have a play. I'm keen to get these changes into our next major release and I don't think its hard since its mostly around moving things that already exist around.

[instinct]

Oh the other thing I want to do is change the word in the WordPress settings menu to WP e-Commerce as opposed to Store. I want to do this because its what BuddyPress and bbPress do. Any major objections to this?

[instinct]

Also here is how I think Page settings should look after a little more UI Mc Lov'n:

[paulgibbs]

Not familiar enough with the plugin to feedback on the spreadsheet, but per this screenshot above ^, you have 8 save buttons and 7 view buttons.

I'm assuming each save button will save the all of the settings for each page, so you only need 1 save button. This is why most WordPress admin pages have a single "save settings" button at the bottom of each page.

While that'd be a basic improvement, I don't really like it because there's a significant distance between changing a setting and scrolling and finding and clicking on a save button, so: auto-save the settings on change. I think this is a no-brainer. You can still have a single "Save" button just in case people like clicking save buttons (placebo buttons).

There's probably a similar idea to handle the view buttons, but nothing springs to mind immediately.

[paulgibbs]

Also, lots of tabs = lots of settings = lots of options.

Have you surveyed to see what settings people use? I bet a ton are never changed from default for 80% of your sites. Those should be removed from the UI (just make sure they're still filterable so other devs can still adjust them).

[instinct]

Thanks @paulgibbs I really like the logic around the placebo buttons. Makes a LOT of sense.

We did a survey on the new presentation settings and I think we've got that pretty much sorted now. Its just the other tabs now. While I think an e-Commerce site needs a certain amount of options if you look at that spreadsheet there are certainly a lot of things that could go into additional Plugins. Need community help and thoughts on this one :)

What are your thoughts about changing the Store link to WP e-Commerce?

[userabuser]

While that'd be a basic improvement, I don't really like it because there's a significant distance between changing a setting and scrolling and finding and clicking on a save button, so: auto-save the settings on change. I think this is a no-brainer.

@paulgibbs Auto-save settings? You can't be serious?

The point of a save button is to allow you to make changes and when ready, decide to save those changes.

Auto-saving settings could be detrimental to your store as the changes would be live.

Instead, if scrolling for a save button is an issue, better thought into the UI placement of the button needs to be had, perhaps a sticky save button that floats right-bottom (or top) of the screen depending upon where the user is in the view-port that allows them to quickly reach the save button without losing view of their current changes.

[tomjn]

Auto-saving would be inconsistent with the rest of WordPress, and it would mean brief moments on the frontend when things aren't live or properly configured if you need to change 2 or 3 settings at once.

Also what happens if js is either turned off or unavailable?

[instinct]

@paulgibbs - when you look at the BuddyPress page settings it also has lots of view and save buttons. In BuddyPress the number of buttons correspond to the number of modules you have activated i.e. activity streams... groups etc.

In e-commerce we don't have the luxury of turning pages off. Having a checkout page, catalogue page, single product page and cart page are all required for e-commerce to work.

I really don't like having multiple save buttons on a page. I find it pretty ugly and confusing and I'm going to assume that this is why in BuddyPress they have mini save buttons.

In my opinion the least confusing of all the options might be to keep the view buttons (because they are useful) and just have the one save button at the bottom. I'm assuming that people are used to scrolling to find save buttons in WordPress - the options-discussion.php page is all the proof we need of that.

[instinct]

Its not like wp-admin/options-discussion.php in WP has two save buttons, one for the general settings and another for the gravtar settings.

So perhaps like this:

[mihaijoldis]

maybe a Save Changes button that "follows" you and stays in a visible place on the screen as you scroll on the page ?

so like if you have to scroll alot to get to the option you want to change then scroll alot more to get to the save button.
with a "floating" save button you can click it any time you want it to save your changes
just an idea, cause i know i`ve seen this kind of buttons someplace i just cant remember where

[instinct]

I've not seen this done in WordPress. I think Gravity forms do this during form creation.

Sent from my iPhone

On 27/08/2013, at 12:34 PM, misulicus notifications@github.com wrote:

maybe a Save Changes button that "follows" you and stays in a visible place on the screen as you scroll on the page ?

so like if you have to scroll alot to get to the option you want to change then scroll alot more to get to the save button.
with a "floating" save button you can click it any time you want it to save your changes
just an idea, cause i know i`ve seen this kind of buttons someplace i just cant remember where

—
Reply to this email directly or view it on GitHub.

[danmilward]

What if we were to hide the following in an "advanced" slide down type of thing.

• User Related Login
• SEO related
• Page titles

And yeah I agree that one save button is the way to go.

Also folks this will be getting implemented in a few weeks. Any thoughts / feedback now would be great - or forever hold your peace ;)

[instinct]

Just added a little bit of text under the home page settings. What does community think :)

[benhuson]

Would that be the same as setting the main store URL to blank?
Would that work rather than having a separate option?

[instinct]

I don't know. Maybe if you select the checkbox it greys out the Main store form field so you can't change it...

What are your preferences? @benhuson @visser @garyc40 @JustinSainton :)

[benhuson]

Following the style of WordPress Reading settings, maybe it should be something like this?

[visser]

Page select should be a select dropdown with Chosen jQuery (http://harvesthq.github.io/chosen/), replace the 'http://localhost... [input box] [view]' option that @benhuson included with that.

You can add advanced options (e.g. slug control, SEO titles, Page ID, etc.) off-page, within an 'advanced view' or separate to core via an addon Plugin. Remember the user community aren't programmers and don't always have Permalinks on either.

[benhuson]

I imagine the idea was you don't need to set up a page before configuring, you could just enter the URLs you wanted to use.

But good point on permalinks @visser, what happens if not using pretty permalinks?

[JustinSainton]

Yeah, I like Ben's idea of essentially mimicking what WordPress does. I'm not super sold on including a library like Chosen for this. If we were going to include something like that, it would seem proper to utilize it across all of our input fields rather than just this one field. If that's a decision we make, it should be considered separate from this. Tangentially, I prefer Select2 over Chosen.

[instinct]

Cool. I like Ben's idea too.

I have a feeling that @garyc40 already used / included a library here:
#516

I could be wrong. And I don't know which library (assuming he did).

[JustinSainton]

Yeah, haven't seen a PR for that issue, so who knows. But any library we implement for input UI should be implemented across the plugin, not just in settings.

[instinct]

Agree

[garyc40]

@visser @benhuson : @benhuson is correct that in the new theme engine we're not requiring pages to be set up. The user can just assign a URL and that is it. In case permalink is not enabled, the query string will kickin and the URL will end up looking something like this: http://store.com/?wpsc_page=cart (where cart is the slug that the user defined).

I also want to take this opportunity to further clarify why we have that Pages settings tab for the new theme engine, so that we're all on the same page (cough) when commenting on this issue. We're moving away from using shortcodes inside pages to define WPEC URLs. So shortcodes such as [productspage], [transactionresults] etc. will go away. All the slugs will be managed in Settings -> Pages.

I know a lot of people will say that this is probably not flexible to the end-user ("what about SEO?", "I want to add content before the main shopping cart" etc.), let me explain why we have to do it this way.

We wanted something as close to bbpress / buddypress by automattic and this is similar to the way those are setup, just entering the URL for the main "controllers" (I'd rather avoid using the word "pages" among us developers because it's easily confused with WordPress pages, however I totally understand that for the average user, there seems to be no better wording than "pages").

If you take a look at bbpress, you can surely create a page with the slug "my-forums" and put a shortcode such as [forums] in there, and the main forum will be displayed. However that page will not be the main slug for the forums post type. All forum posts will reside under "forums" parent slug.

Relying on a shortcode within a WordPress page to define the main slug of a custom post type, while undeniably easier for the end-user to perceive, is extremely hard to do right, due to the way the main $wp_query object is setup. We will end up with a situation where, when outputting the "outer" part of the main shopping page such as header, sidebar, footer etc. $wp_query->post will be the page containing the shortcode, while inside the page's content (output by the_content()), there will be another loop populating $wp_query with products. That's basically two nesting loops that rely on one single global variable. This situation is bad because, if a widget in the sidebar depends on detecting the main shopping page, it will most likely fail (because outside of the "inner" part, the main query will be that of the page containing the shortcode).

Current 3.8 branch of WPEC is circumventing this by creating a separate query object called "$wpsc_query". But first of all, it doesn't work that well in the first place. There are still reports of users having issues with the main page title being the first product's title. Second, we're creating two query objects and doing things like this all over the place:

list( $wp_query, $wpsc_query ) = array( $wpsc_query, $wp_query );

That is insanely hard to debug and maintain if we do it in more than 2 or 3 places.

Third, we're making redundant database queries, one to fetch the page, the other to fetch the products.

So that's the reason why I decided to go with what bbpress did with their custom post types.

[benhuson]

@garyc40 I completely agree this is the best way to go.

The core WordPress model of setting the home page/blog based on a dropdown of pages is slightly different in that although those pages exist the blog page is never actually loaded as a 'page', it just uses the slug of that page to generate the rewrite rules to handle it differently - I think?

So, it's the same as we're doing but using real pages to generate a dropdown UI to set the permalink.

Regarding the SEO issue you mention, I wouldn't worry about that.
I guess we could have a 'wpsc_above_content' type filter above the content for people to insert stuff?

I belief that the rewrite rules for a CPT will take precedence over any page permalinks if there is a page of the same name.

I have used this before to allow people to create pages with the same slug as a CPT which won't show on the front end, but them in the code searched for pages with the same slug as my CPT and inserted that content at the top of my template. Not sure wether using rewrite precedent like this is OK, but if it is it would be fairly easy to create a plugin to show content on WPEC pages if there are hooks in place.

[ReactorShop]

I don't see translation plugins covered in this discussion, so have you taken into account how will these changes may impact translation plugins, like WPML, Polylang, qTranslate, Xili-language, etc.?

I've seen support threads @ Wordpress.org, where users claim to be using WP e-Commerce with qTranslate or Polylang, even though both are limited in their WP e-Commerce translation capability. A radical modification may affect how these installations function, or even halt their operation.

My current work interfacing Polylang to WP e-Commerce in my website allows for translated CPT page slugs to be shown in permalinks.

Are you going to provide a filter hook or another form of translation support mechanism (e.g. using MO files/string table/wpml xml file?) to allow for these pages CPTs slugs to be handled by translation plugins?

[instinct]

@benhuson @iorivn

Taking both of your comments into account I redesigned the page settings screen. I also looked at how other Plugins handle page settings. I think I've taken the best of all Plugins and made something more awesome. Please let me know what you think...

[instinct]

@ReactorShop Hey buddy. The best way to ensure you get the WP e-Commerce Plugin that you want it to get involved - so you've come to the right place!

So have you tried out the new Theme Engine Plugin? The best place to have a conversation about translation plugins once you've tested it would probably be here:

https://github.com/wp-e-commerce/wpec-theme-engine-v2

If things don't work right then I would create an issue there. @garyc40 would you agree with that?

[ReactorShop]

I'm sorry, I still haven't had the chance to try the new Theme Engine Plugin.

I'm still using WPEC 3.8.12.1 in my development environment, and got as far as testing UPS order shipping quotes, while increasing Polylang's translation coverage via a plugin.

I have some fixes for the UPS module and the shipping.helper.php file, which are not applied in WPEC's 3.8.13 Beta.

I just need to complete my order testing process to complete my production server installation, and then I'll fork into my development environment your current WP e-Commerce version.

For now, I'm just commenting when I see some development decision that may affect my current setup. Soon enough, I'll provide patches for all of you to evaluate.

[JeffPyeBrook]

The built in wordpress dropdowns work well for selecting the pages. This is a screen shot from my theme options page.

The main advantage over typing in the slugs is going to be avoiding typos or issues when page slugs are modified

[instinct]

Use case:

1. people set the home page of their site to be their store
2. they also want to use this plugin http://wordpress.org/plugins/sliderme/

Compatibility for these types of things is non negotiable. So I guess that means 'wpsc_above_content' type filters is necessary from day 1?

[benhuson]

@JeffPyeBrook I like that approach using page dropdown menus - I also use that in my own themes/plugins too.

I like the fact that by setting a permalink in this way you can then control things like page title and slug etc from the pages section of the admin which feels intuitive for users. It also means it is probably easier to add support for other plugins like SEO, XML site map generators and probably translation plugins too because they exist as pages in the wordpress admin (although I havn't really tested this). And you can easily pull the page content into the top of your template using get_page_by_path() to get the matching page.

It does mean that you have to create pages for all those slugs though which makes the setup process more long winded unless you create them automatically or have the option to set slug or select page.

Both this and the setting text slugs methods are much better that the current shortcode method though.

@instinct Yes, I think there is definitely a likelihood of people wanting to display custom content on these page which we should factor in somehow from the beginning, even if it's just hooks and filters.

[ReactorShop]

@benhuson Regarding translation plugins, I don't know about qTranslate, but Polylang handles WPEC's CPT pages translations fine.

The "challenge" lies on WPEC's side, because WPEC validates the ID retrieved by the wpsc_get_the_post_id_by_shortcode filter (at least until 3.8.12.1) against the page ID currently processed to be shown.

I don't use the CPT page's short codes in my plugin to switch the translated page's ID for WPEC to validate, but the page's page_name slugs (from post IDs), which conforms with the approach you all are sharing here.

Regarding the WPML translation plugin, here are some lines of code that show short codes being used to provide the CPT pages translations (from the WP e-Commerce Multilingual plugin).

function filter_pre_option_product_list_url($lang = null){
    return $this->_get_url_for_page_by_shortcode('[productspage]', __('Products Page', 'wp_e_commerce_multilingual'), $lang);
}    

function filter_pre_option_shopping_cart_url($lang = null){
    return $this->_get_url_for_page_by_shortcode('[shoppingcart]', __('Checkout', 'wp_e_commerce_multilingual'), $lang);
}

function filter_pre_option_transact_url($lang = null){
    return $this->_get_url_for_page_by_shortcode('[transactionresults]', __('Transaction Results', 'wp_e_commerce_multilingual'), $lang);
}

function filter_pre_option_user_account_url($lang = null){
    return $this->_get_url_for_page_by_shortcode('[userlog]', __('Your Account', 'wp_e_commerce_multilingual'), $lang);
}

function _get_url_for_page_by_shortcode($shortcode, $page_title = '', $lang = null){