10 / 32
Jul 2014

can you at LEAST, PLEASE enable the mouse wheel for the product edit panel then!!



and make the last selected option the current index in dropdown/option list!



that is still flash and only takes a few lines of code tops! :slight_smile:

Are you referring to the Select Product menu when you go to View/Edit/Delete Products? That should already normally default to the last-edited product in the same Admin login session -- i.e., as long as you don't log out, the Select Product menu should always default to the last product you'd edited.



The new Admin is being built in HTML, so that should obey OS/browser-standard behavior for menus, including mouse-wheel navigation. Meanwhile, while the menu is open you can click in the scrollbar track, above or below the scrolling slider, to jump up/down in the list by a whole screenful at a time; also, typing a letter while the menu is open will jump to the first item starting with that letter in the menu list.

it has the last selected product there..but not when you open the drop down.. you always start at beginning and have to scroll back down..etc..



but just enabling the mouse scroll for scrolling through the drop down would be great!..





Im assuming its written in AS2? being thats been around for a while?





thanks

1 month later

yes please make this a priority :slight_smile: i love ejunkie, the service is great and it really helps run my business without me being there. BUT not being able to access the dashboard via iphone and ipad is a REAL drag. i've tried a couple of crappy app flash programs that didn't work (supposedly to allow ejunkie to work on iphone/ipad).



my 02.



thanks, david

2 years later

Is two+ years not enough to get us away from flash yet?

Latest word from our Admin developers is that they've completed a run-through of the total project in full, so now they're reviewing that completed body of code from end to end to look for bugs, adjust and optimize as needed, etc. Sounds like we'll have a complete alpha version ready for formal internal testing/QA review any day now.

1 month later

At this point I am actively looking for alternatives for me and my clients. That represents probably close to twenty ejunkie accounts.



I hate to say it but I have come to believe that there is no active development. It has been years but there is nothing to indicate anything has changed or is in the works other than an occasional posting from someone saying "soon".



I understand complex interfaces but the e-junkie isn't that complex. We could at least see something.



One of the other shopping carts I use integrated Stripe processing in 3 whole days. Had it debugged and fully operational in less than a week.



With that cart I can login from anywhere with my phone, tablet, or computer and be done with my task in a matter of minutes. With e-junkie I have to wait till I'm at a computer, hope that Flash doesn't freeze, etc. So I'm pleading - get this stuff done.



I mean we are coming up on Q4 and there is absolutely no indication that anything has happened other than occasional postings saying "any day now".



Okay enough ranting now. I like e-junkie - a lot. But i no longer recommend it to anyone as much of it is now archaic and I cannot point to any indication that new development is in the works. I want to be proven wrong and use the service for a long time. But things need to get updated and progress made. Give us something - anything - to give some confidence that this is getting worked on and that progress with items like the new interface and Stripe have a chance of showing up before say 2020.



I know some of you think 2020 sounds like a long way away. But that is almost how long we have been hearing about the new admin and not seeing it. At this point I see nothing tangible to indicate that a new admin is even in the works.



Help me out here e-junkie. Restore my confidence. Actually let me work on my clients concerns using modern tools like my phone, iPads, and other tablets. Catch up with the current state of the art.

13 days later

dstrange, thanks for your input because that's exactly how I feel too. Apart from not getting new features, the biggest show stopper is the lack of a non-flash interface usable on various devices. I understand they had staffing issues, lack of resources, etc., and so maybe could not respond to market demands on features, but when a company cannot turn around to make their site actually usable on a whole lot of devices, and promising for years , I start to feel that its time to move on. This along with lack of new features is starting to make ejunkies look risky to me. As stated by dstrange, would certainly think twice before recommending it to anyone.



I like ejunkies a lot and have been with them for years which is why I feel sad as I write this. We are constantly looking for alternatives now and I am sure it is only a matter of time before we make the jump. If any one has any good suggestions on alternatives, please let me know. And I don't think this is unfair to ejunkies as we would gladly stay if their system could actually be used on devices or had the basic features you expect from a modern shopping cart (such as providing a simple PDF receipt for each transaction with the details of products purchased so we don't have to do this manually for each customer!). It's not too much to ask I am sure.

I am pleased to confirm we are starting formal alpha-testing/QA review internally as of this week. Once that's completed, and we've addressed any bugs discovered as a result, we will have the confidence to open it to select clientele for a round of beta testing, after which we can finally take it live for the general public. We offer our deepest thanks to you, our loyal clientele, for your considerable patience and understanding while we completed this long-anticipated and overdue upgrade.



Regarding receipts, the buyer normally receives a receipt email from the payment processor (e.g. PayPal) rather than from us, since we don't handle any actual payment funds, whereas they do. If you wish, you can also format your E-junkie-generated thank-you pages like an invoice, as we explain in more detail on this help page:

http://www.e-junkie.com/ej/tips.thankyou-page.invoice.htm

Thanks E-junkieGuru for the update and as always look forward to the new version once its here.



As for receipts, I am sure I have covered this in detail elsewhere so I feel disappointed that I have to spell it out again. E-junkies is simply incapable of producing a decent acceptable receipt with the list of products included, either in the thank you page or sent by email. There is no token to include the list of products. A receipt MUST HAVE a list of products. I know the payment is processed by processors like paypal, but your system "knows" when a transaction has succeeded. You have access to invoice numbers, transaction IDs, prices, customer details, date of purchase, etc., all of which is present in the email you send a supplier about each transaction. Yes, let me say that again. You already send the info in an email to us along with a whole lot of other info that is suitable only for the supplier. Therefor you can certainly format the same information in a different way and create a receipt that is sent to the customer. Its not even hard to do and will not even take one day of programming. A receipt is the most basic thing a shopping cart can do. Please don't make excuses.

The thank-you pages we generate already include by default a bullet-pointed list of all items ordered by the buyer; in fact, we have no way to remove those item names from our thank-you pages. The help page linked in my previous reply above simply explains how to display additional item and order details to that default list of purchased items -- e.g., in the example provided at the end of that help page, sample item names in boldface such as "Example Tangible Item Name" show where your actual item names for that order would be displayed in the page.

So you are confirming that the data is displayed in a thank you page that is hosted by you. But didn't you say that you don't handle the actual payment and so you cannot actually show this data. Do you see the inconsistency?



We use our own thank you page. Customers want to receive an email receipt for their account and the thank you page example you have doesn't look official for their accounts. So you already have the information for the transaction, you already send an email to us the supplier about the transaction with all the details, it should not be hard at all to send one to the customer too.



Sure enough, you can use your excuse that you are waiting for the non-flash UI before you do this, but please do not say it cannot be done, or that is already done.

You can edit the Thank You email your customer receives and you also control the look of the e-junkie generated Thank you page. So I think you can get where you want to be. It just won't be a PDF file. I also don't recall if you can use HTML in the generated email but you can make it say anything you like and pass variables from your sale to it.



If you are using your own Thank You page you can pass variables to it to populate that page with. But I would just use the automated page and format it the way you want it. At least that is what I advise my clients to do.

I did not mean to suggest that we are technically unable to display order details, since we obviously have a record of whatever details the payment processor passed back to us when they confirmed completion of the buyer's payment. Rather, it is not our place to provide a receipt for payment funds tendered that we had no role in actually handling, and our doing so could raise legal issues in various jurisdictions. This is one reason the aforementioned technique refers to formatting a thank-you page as an "invoice" rather than a "receipt" per se.



Think of it in real-world terms: in a physical store, who should hand the customer a receipt for their payment -- the cashier who actually received cash from the customer, or the will-call clerk who provided merchandise to the customer after the cashier told them it was paid-for? Translating that to online terms, the payment processor is your cashier, whereas we are just the initial order-taker and will-call clerk.



Since you're redirecting to a thank-you page on your own site, you can use the method we explain here to embed our generated thank-you page content (formatted as an invoice, if you like) within an iframe inside your site's thank-you page:

http://www.e-junkie.com/ej/tips.redirection.download-link.htm



You can also use our custom/third-party Integration feature to have us send all the order data to an external script that could then do whatever you wish with it, such as generating a receipt to send the buyer:

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



If you'd like some help setting up such a custom script, we can recommend the independent developers for hire listed at the Developer Directory link at the top of our site.

E-junkieGuru, I am not sure why you refer to legal issue on producing a receipt because you are not a payment processor. If this is really the case, why does the rest of your response aim to show how this can be done in a thank you page, simulating an invoice/receipt. Wouldn't that lead to legal issues?! I dont think your shopping cart is just a clerk or order taker. You do a lot more than that. On a technical level, you collect customer information on your form and on the other side, would only release products once the payment goes through. What kind of legal issue is there in generating a log of the transaction based on the data you have already collected and knowing that the transaction has gone through. Would you be kind to expand on it please, because I find it very puzzling. Other shopping carts do it so why not you (example: Roman Cart which provides a very similar service to you)



Now, as for your description on how to simulate an invoice, you simply dont provide the desired functionality as I have explained this several times now, and over the years. Yes, I can put an iframe pointing to your site on my own thank you page. This iframe needs to be filled with something that would look like an invoice. For this I require transaction data and a "PRODUCT LIST". I have included your guide on tokens below. None are about including a list of products purchased that can be shown in one page. The product list is an essential part of an invoice/receipt. Without it, there is no receipt. The same goes for emails sent. There is no token to include a list of products purchased in an email, even as a simple text list.



From:

http://www.e-junkie.com/ej/help.custom.thankyou-page.htm



Template variables you can use in the Common Thank-you Page HTML field



[%first_name%] (Buyer's First Name)

[%last_name%] (Buyer's Last Name)

[%payer_email%] (Buyer's PayPal Email)

[%txn_id%] (Transaction ID)

[%auction_buyer_id%] (Auction's Buyer ID [for eBay sales only])

[%shipping_name%] (Shipping recipient's name [if applicable])

[%address%] (Shipping Address [if applicable])

[%city%] (Shipping City [if applicable])

[%state%] (Shipping State [if applicable])

[%zip%] (Shipping ZIP/Postal Code [if applicable])

[%country_full%] (Shuipping Country [if applicable])

[%country%] (Shipping ISO Country Code [if applicable])

[%total%] (Item total)

[%fee%] (Payment Processor's Fee [if available])

[%affiliate_share%] (Affiliate's commission [if applicable])

[%affiliate%] (Affiliate's email [if applicable])

[%currency%]

[%invoice%] (Unique Invoice ID generated by E-junkie)

[%tax%] (Sales tax or VAT)

[%shipping%] (Shipping + Handling)

[%gross%] (Order total)

[%p_date%] (Payment Date, example: January 1, 2009)

[%c_date%] (Current Date, example: January 1, 2009)

[%c_time12%] (Current time (MST) in 12 hour format, example: 7:07 pm MST)

[%c_time24%] (Current time (MST) in 24 hour format. Example: 19:07 MST)

[%custom%] (If you passed a custom variable in the button code)

You may find of interest this FAQ page explaining in real-world layman's terms how the purchase process works in regards to our system, which is a bit different from most other e-commerce platforms that have built-in functions to process payments:

http://www.e-junkie.com/ej/faq.how.laymans-terms.htm



I was merely making a semantic point that the term "receipt" indicates proof of something having been "received", namely actual payment funds in this case. We do not handle any buyers' actual payment funds whatsoever; they never touch or pass through our system in the course of checkout, so we cannot provide any proof that such funds have been tendered at all. We only take the payment processor's word for it, after the fact, that they have received payment from the buyer, and then we process the order accordingly (send emails, issue links, log order details).



What we CAN provide is an "invoice", which is merely a summary of order details. Every common thank-you page we generate* already includes a list of the specific item(s) ordered, so there is no need to use any particular template tokens to insert such a list, because that list is already included in the page by default. Our technique to format the thank-you page like an invoice merely explains how to ADD further order details to that default list of items ordered. If you embed our generated thank-you page content inside your site's thank-you page, that would also display the same list of items along with whatever additional details you chose to add to that list.



*The one exception to that all-items-ordered list is with the link we include by default in product-specific thank-you emails for digital products; in this case, that link would open to a thank-you/download page for just that one item alone. If you prefer not to show this item-specific thank-you page, you can either disable product-specific thank-you emails or Enable Templated Email for them to replace our default message with a custom template. In the latter case, the template tag [%thankyou_link%] would insert a link either to a consolidated thank-you page listing all items in the order or otherwise to your site's thank-you page if you redirect to one.