1 / 43
Sep 2011

Hi,



I'm currently developping wordpress plugin to enable full integration of E-Junkie (you guys rock!) shopping cart to wordpress CMS



trame :



I will use 2 custom post types :



*Products - to create product sell pages

*Orders - to manage payed transactions in wordpress admin (after data treatment)



The clients will be added automatically as wp users (client role) after treatment of the data sent by e-junkie.



I've already read the http://www.e-junkie.com/ej/help.integration.htm and do uderstand the major part of it.



None the less, i have several questions to e-junkie developpers (need you help here to see the logic of your data sending script) :



1 If seller uses "Common notification url" to send data to 3rd party service (say aweber with your code provided here : http://www.e-junkie.com/ej/help.integration.htm#aweber ), can he still have the data be sent to the script in wordpress without using "Payment Variable Information URL" on by product basis? Or it is better to set "Common notification url" to the wordpress script first, then the script itself will send data to aweber ?



2 As i'm looking to avoid plugin users to fill "Payment Variable Information URL" for each product, and have only one script to treat the data from e-junkie - what is the better way to treat item details in a cart ? (i have not found the variable sent to Common notification url that explicitly tells how many items were in the cart,please, advise on how to loop through the items in a cart ?)



2.1 item_nameX ? does it starts from 0 or 1 ? for less than 10 items does it look like item_name01 or item_name1 ?



3 Could I get more info on :



mc_shipping

tax

for_auction

auction_buyer_id



4 custom - I will try to append &custom=poduct_internal_id to all of the add to cart buttons , if buyer will have several products in the cart , how $_POST['custom'] will look like when sent to Common Notification URL ?



5 do the view cart buttons vary for different products? (i'd love to have my users add view cart button code only once in the plugin setting page, then the plug will display it on each sell page next to add to cart button automatically)



6 is there any way to create products in e-junkie in a automatic mode (say, script sending you the data for product details along with e-junkie user login to add products and gets add to cart button code in response ?) (yes I know, I'm dreaming, but that's so nice to have a dream to go for lol)



thank you for your responses,



sorry if some of my questions are not clear, i've just digged into this area and do not see all clear myself.



cheers,

serge

5 no



(int) possible UI for different images on add to cart, buy now view cart (use filter as img are always the same)



notes:



xhtml strict for border - use filter to remove



on setting page use filter to split view cart button into button and script, hook script in footer

4 ??? http://www.e-junkie.com/bb/topic/2800



any pointer on how to "look up" the cart and items in it? don't want to loose one option out of three for this issue



or I can use more than 3 options for variants of the product?



nevermind : http://www.e-junkie.com/bb/topic/2800#post13313 - extract e-junkie product id from button code on savepost hook (each modification) to use as internal custom_field



sanitize as intval and use mysql query to get post->ID as get_post() will fail if product page is not status=published (sale via affiliate buy now buttons) -- note: -- create a notification in order if sold product not listed on front side of wp ?

You may be interested to learn another of our clients has already developed a WP plugin for adding E-junkie cart buttons and managing product listings:

http://wpejunkie.com/



You might learn some useful things from that code, or maybe even consider refocusing your plugin development efforts to meet needs not already covered by that plugin rather than reinventing the wheel.



I am going off duty now and cannot address your other concerns at present, but I just wanted to reassure you I will revisit this topic tomorrow and respond further at that time.

Hi E-junkieGuru,



nice to meet you. Thanks for the link, I've already browsed the code (BTW there are plenty nice snippets there).



As for reinventing the weel - my customer ordered a more complex "weel", so i need to reinvent the whole thing from zero, as the WordPress API available today enables me to skip a lot of coding for even better integration into admin.



BTW any available keys on ConsoliBYTE QuickBooks Integration for E-junkie ? is it similar to aweber ? Client wants to send data there and in the wordpress at the same time (so might need aweber as well)



cheers,

serge

Question 7 :



It looks like i can configure the variants for products already existing in ej admin...



how do i do that ? (general way)



how do i add price parameter to the button for the variant selected by buyer?



what format (percentage or added price or full option price) should i use in this case ?

First, regarding ConsoliByte QuickBooks integration for E-junkie, they are a third-party service that we don't know much details about, but I gather they would provide their clients with a Common Notification URL to use in their E-junkie settings, so the order data for each transaction would simply get POSTed to ConsoliByte's integration script after payment completion.



Now, to address your other inquiries in order:



1) The forum thread you linked is correct. Moreover, if you just want to POST the order data to two separate scripts, you could place one script URL in the Common Notification URL and a different URL in each product's Payment Variable Information URL, or you could simply use the Common Notification URL alone to POST data to a "middleman" script that would simply resend the data to multiple other scripts. BTW, the only difference in data sets POSTed to each URL would be that the Common Notification URL does not receive the "Item Specific Non-IPN Data" variables documented on our Integration help page.



2) There is no variable explicitly stating the number of items in the cart. You could just count the number of, say, different 'quantityX' variables passed to get the number of different products regardless of item quantity, or add up the values for all 'quantityX' variables to get total item quantity.



2.1) The forum thread you linked is correct.



3) Most of the data we POST is a simple pass-thru of all the IPN data we receive from PayPal, as-is, or for non-PayPal checkouts, we convert the data we receive from the payment processor into IPN format (e.g., change variable names). Here's another good reference for those variables:

https://cms.paypal.com/us/cgi-bin/?&cmd=render-content&content_ID=developer/e_howto_html_IPNandPDTVariables



Furthermore, we add some non-IPN variables to the base IPN data set, providing data specific to our system that PayPal does not handle. Any off-the-shelf script that can handle PayPal IPN should be able to handle our Integration submissions, as long as it can handle/ignore the extra non-IPN variables we send and does not need to validate the IPN with PayPal (which would fail since we are POSTing the data, not PayPal, and we already validate IPNs we receive from PayPal anyway).



4) The 'custom' variable is NOT item-specific; there can be only one 'custom' value per order. If more than one 'custom' value is passed to the buyer's cart, only the last value passed would get included with their order. It may seem a bit confusing that this value gets passed via Add to Cart URLs when it isn't item-specific, but that's simply the only way we can pass any variables to the cart at all, since we can't presume buyers would click any View Cart buttons. If you just need to match an internal product ID at your end to the E-junkie Item Number, note that our Item Numbers are customizable, so you could easily make them exactly the same. If you need to pass another unique, hidden value per item, you can pass Variations values; see more details here:

http://www.e-junkie.com/ej/help.variants.htm

http://www.e-junkie.com/ej/help.custom.purchase-buttons.htm

(that latter page is also relevant to many of your other questions here)



5) View Cart code is unique to each E-junkie seller (references the seller's unique client ID via the URL parameter &cl=XXXXXX) but otherwise the same for all of that seller's products. You only need to make sure you include at least one complete block of View Cart code in every page that has any Add to Carts, as the View Cart code calls our 'box.js' script that manages the overlay-style cart "inside" the seller's page. You can even separate the View Cart button link (which has the unique client ID) apart from the script portion of that code (which is the same for everybody) -- e.g., putting the script portion just before the </body> to improve page-load performance, maybe have your plugin just add that to every page automatically. Do NOT use a local copy of 'box.js', as that could be problematic and would miss any new features and bugfixes we may roll out from time to time.



6) That forum thread you linked to is still accurate; at present, we have no API to send product configurations to your end nor to add/edit products from your end, independently of just using Seller Admin manually. Due to past abuse, we also do not permit automated interfacing with Seller Admin, which would soon break anyway once we release the new, DHTML-based Seller Admin we've been working on.



7) I'm not sure if you have any questions remaining on this item?

E-junkieGuruFirst, regarding ConsoliByte QuickBooks integration for E-junkie, they are a third-party service that we don't know much details about, but I gather they would provide their clients with a Common Notification URL to use in their E-junkie settings, so the order data for each transaction would simply get POSTed to ConsoliByte's integration script after payment completion.





I'll get their account to see their script and/or their way to integrate e-junkie, maybe their script could be the "middle_man"



2 - 2.1 found the solution : loop the counter through item_numberX to count how many different items i have in the cart and through quantityX to see each quantity of separate items



3 solved



4 solved . I will get ej product name from add_to_cart /buy_now buttons and use it as internal wordpress reference saved in database, this way the listening script will connect IPN item_number with wordpress $post->ID for further treatment. A sort of converter e-junkie product number = > wordpress product ID



5 easily solved within the plugin (i will use filters to manage view cart button output so that it stays valid in xhtml strict 1.0 and put YOUR script just before </body>), this will help user to add view cart button only once in the plugin setting page and forget about it (as it is unique to ej user).



For add_to cart / buy now / buynow URLs the user will have separate boxes to input button html on edit product screen in wordpress admin (this way the plugin may do further modifications accordingly product settings)



6 last question : is it possible to send the url of item specific listener alog with the button url ?



I really do not want users to be forced to enter "Payment Variable Information URL" on each product. I'd like to send this "Payment Variable Information URL" variable with add to cart button. Thus i could have them be generated by wordpress and receive "Item Specific Non-IPN Data" for treatement... any idea on that?



7 yes one more left : i think it would be easier on my side to have buttons with variants as forms $_POST to add to cart. Any pointer here in forums on that? Thus the user may configurate variants in wordpress admin only without being forced to modify it twice (wp + ej) in the admins.



Thanks for you time,



cheers,

serge

Apologies for my delay in following up on this.



If ConsoliByte could forward the data to another URL after they receive it, that might work, or you could write your own middleman script to receive data via the Common Notification URL, and then that script would simply resend the data to ConsoliByte and whatever other script(s) you require.



It is not possible to specify a Payment Variable Info URL via the button code; this can only be defined in the product's settings in Seller Admin.



View Cart button code follows a common format, where XXXXXX here is the seller's E-junkie client ID:



<a href="https://www.e-junkie.com/ecom/gb.php?c=cart&cl=XXXXXX&ejc=2" target="ejejc" class="ec_ejc_thkbx" onClick="javascript:return EJEJC_lc(this);"><img src="http://www.e-junkie.com/ej/ejview_cart.gif" border="0" alt="View Cart"/></a>



Add to Cart code for items not using Variants/Variations also follows a common format, where XXXXXX here is the client ID and YYYYYY is the Item Number:



<a href="https://www.e-junkie.com/ecom/gb.php?c=cart&i=YYYYYY&cl=XXXXXX&ejc=2" target="ejejc" class="ec_ejc_thkbx" onClick="javascript:return EJEJC_lc(this);"><img src="http://www.e-junkie.com/ej/ejadd_to_cart.gif" border="0" alt="Add to Cart"/></a>



The "WP E-junkie" plugin takes advantage of all that and has the seller simply provide their Client ID in the plugin settings and specify only an Item Number in the "shortcode" used to insert an Add to Cart button in content posts. For products using Variants/Variations, it just has them paste in their button code from Seller Admin, which is a bit more complex to accommodate option menus/fields:



<form action="https://www.e-junkie.com/ecom/gb.php?c=cart&i=YYYYYY&cl=XXXXXX&ejc=2" target="ejejc" method="POST" accept-charset="UTF-8">

[menu/field code for product options goes here]

<input type="image" src="http://www.e-junkie.com/ej/ejadd_to_cart.gif" border="0" alt="Add to Cart" class="ec_ejc_thkbx" onClick="javascript:return EJEJC_lc(this.parentNode);"/>

</form>



Note the difference between "Variants having individual price/etc." vs. "Variations which tell more...": while menu values for Variants must exactly match the values given in the product's Define Variants screen, the menu/field values for Variations can be completely arbitrary and don't even require Variations to be enabled or defined in the product settings (we only use those to generate the button code). See related tips here:

http://www.e-junkie.com/bb/topic/5418#post18738

If ConsoliByte could forward the data to another URL after they receive it, that might work, or you could write your own middleman script to receive data via the Common Notification URL, and then that script would simply resend the data to ConsoliByte and whatever other script(s) you require.




i think in the future i will opt for "middleman" as it is more independent solution i can control on my side.



The "WP E-junkie" plugin takes advantage of all that and has the seller simply provide their Client ID in the plugin settings and specify only an Item Number in the "shortcode" used to insert an Add to Cart button in content posts.




typing shortcode is not that easy for some users (personal experience), i will provide them with a single textarea to paste the add to cart button for the current product. That's all they need on wordpress product pages (the view cart and some other essential stuff will be controlled from plugin settings). As for adding e-junkie buttons to wordpress you may simply paste them into post content, wich works fine as well.



Forms will be integrated in the next version of the plug (i was asking this for future, as making this thread be my personal ressource list)



Now the buttons :



<a href="https://www.e-junkie.com/ecom/gb.php?c=cart&cl=XXXXXX&ejc=2" target="ej ejc" class="ec_ejc_thkbx" onClick="javascript:return EJEJC_lc(this);"><img src="http://www.e-junkie.com/ej/ej view_cart.gif" border="0" alt="View Cart"/></a>





this html will throw some errors in xhtml strict 1.0, will it affect button functionality if i remove / replace



target="ej_ejc" (how can i valid this, any javascript to add target argument here?)

border="0"



thanks for the links

Note the difference between "Variants having individual price/etc." vs. "Variations which tell more...": while menu values for Variants must exactly match the values given in the product's Define Variants screen, the menu/field values for Variations can be completely arbitrary and don't even require Variations to be enabled or defined in the product settings (we only use those to generate the button code).





... which means the user has to add/enable variants in e-junkie admin before sending the data with button code for the product having variants with indivudual price/etc



and no such need for variations...



did i get this right?

Yes, you're correct on the differences between Variants vs. Variations.



Regarding the target="ej_ejc" attribute: in case the buyer has JS disabled in their browser, the cart buttons would normally operate in "fallback" mode by showing the cart in a separate window/tab, as specified by that target attribute. You could remove the target, but then if JS is disabled, the cart buttons could only show the cart by navigating away from the site page in the same window/tab. In this case, we change the cart's Continue Shopping button into a Go Back button, but some buyers may still find this confusing e.g. if they absent-mindedly close the cart window and can't find their way back to the site.



Interestingly, target attributes have never been part of any HTML/XHTML "strict" standard, only in HTML/XHTML "transitional" or "frameset" specs:

http://www.w3.org/MarkUp/2004/xhtml-faq#target



If you are not expecting your page source to reside within XML data nor be parsed by XML tools, you may not really need to use XHTML at all:

http://www.e-junkie.com/bb/topic/2673#post6938

Thanks for your reply.



The XHTML Strict 1.0 is the format used by Thesis http://creersitepro.com/voir/thesis/ and i develop mostly for that wordpress theme (as it's the one i find most flexible for professional projects)



i see the main dilleme : to loose some % of sales or not to loose... in this case i'll change the doctype to transitional on product pages and provide a checkbox in plugin settings to replace target attribute by rel="external" + some java to open it in a new tab and leave the doctype as is.

14 days later

Half way there.



Now wp has a store section to publish product pages, organise catalog and wp understands the data received from e-junkie (opens accounts for clients in automatic mode, registers transactions and orders) .



see example http://store.creersitepro.com



discount code for testing product :



cutfree



cheers,

serge