how do I require application_top.php in folder in admin with a composer package?

[wolfderby]

not to be anti-social, but the learning curve seems steep..

$nextOrderId = "SELECT MAX(orders_id)
    FROM `orders`
    LIMIT 1;";
    $orderIdResult = $db->Execute($nextOrderId);
    echo '<pre>';
    $oId = ++$orderIdResult->fields['MAX(orders_id)'];
    echo 'next oId is ' . $oId . '<br />';

???

[mc12345678]

not to be anti-social, but the learning curve seems steep..

$nextOrderId = "SELECT MAX(orders_id)
    FROM `orders`
    LIMIT 1;";
    $orderIdResult = $db->Execute($nextOrderId);
    echo '<pre>';
    $oId = ++$orderIdResult->fields['MAX(orders_id)'];
    echo 'next oId is ' . $oId . '<br />';

???

It can be. But also can be helped by providing reasons for doing what is thought is needed.

Again, note that when using the order class to create an oder, the orders_id is autogenerated by way of inserting the base order info into the orders table.

Further note that the above code reviews the table for the highest number and then adds one to that. Problem is, if someone places an order, then that order is deleted and then this code is executed, two customers would have had the same order_id. No fun for customer or store.

[mc12345678]

Btw, and this was something I learned I believe the hard way, but may have been through watching others get help... If in fact it is needed to determine the next value within a table using the autoincremented field, then the "math" should be done in the query instead of after the query has been run... so instead of just MAX(field_name), should use MAX(field_name) + 1. If the table gets truncated, then a query may return null instead of 0 and doing math after the fact could result in issues. Some of this is system/configuration dependent, but best to use something expected to always work rather than something that *might* work... :)

Still though doesn't seem like this information is needed for this at least until a further reason is identified...

[wolfderby]

Issues today: getting the order_id "right"

Possible solutions:
Solution "keep it ghetto" > no order object > sql lock the order tables > increment max order_id in sql > run inserts > unlock tables

Solution "pro zen-er" > create order object > create order_totals object > create cart object > create currencies object > fudge SESSION data? since this is run in the admin? > I feel like I'm slowly build an entire zen-cart shopping cart. then after all the objects are made can I just then run $order->create(); I'm pretty sure those zen_db_perform('s are my pay-dirt.

I might do "keep it ghetto" then aim for "pro zen-er" if I have time

[mc12345678]

Whatever you choose. Let me say this with a little "tough love"... To insert a new order, you *DO NOT* need to know the order_id that is to be inserted when creating a new order...

You insert the data (without it including an order_id) and *then* ask what the order_id has become...

Session data... doesn't matter where you are in the system, having that session data variable set allows use/reuse of existing code that handles everything you need.

Building/rebuilding a cart? Of COURSE! You're incorporating the act of making a purchase on your Zen Cart store...

As far as locking all the tables or whatever, the only order table that really matters and the only time it matters for the most part is the orders table at the point of making an insert to that one table... Once the unnumbered data is inserted which then gets a number assigned, all other related orders tables get similar additions to reference that order_id.

Personally, I think it would be more work, time and effort to "take the short-cut" than it would to do a simple search through the order class perhaps on '$_SESSION', identify all of the unique parameters and really should only need to concern oneself with the create-like methods... then considering that data, compare to the data that you are receiving from your other direction and line the two up... the order class can handle not receiving something, but also need to be sure that as a user of the store that you are going to get out of this process what you want/need... for example, the shipping, payment, and normal home address information... right now, there doesn't appear to be a consideration of ensuring that the data is "uniquely" captured in the database. Meaning if person X places their first order, on their next order if they use the same addresses will the addresses be looked up and referenced or will they just be added to the person's account.

Are these purchasers gaining access to your Zen Cart store by making a purchase through the route you are implementing? Do they already have an account? If they do have an account, what verification is being done to ensure that the purchase they are making elsewhere (to be tracked here) should be associated with the data they have in the store? E.g. What authentication has been performed to relate the purchase made at this other shopping location with the person(s) in the shopping cart?


Again, you can choose what information you're not going to store in the database about an order, but you'll want to also understand what impact that has on order/data retrieval for you and for the customer(s).

And again whatever you do... stop trying to determine the value of something that automatically determines its value on its own... Let me see if I can think of an example...

Ok, perhaps obscure, but think of it this way, the order_id is the position in a race or marathon. Whoever appears at the end of the race is given a number associated to "how they did" in the race. Once they pass the finish line that number is assigned, but they had a lot to do to get to that finish line. Some may have taken easy paths, some harder, but in the end, they were given the number at which they finished (along with their time) rather than them "appearing" out of the blue and claiming a number... the process of performing the insert to the database is what assigns that number associated with finishing the race... that's also why you'll see in some places in the forum where it is said the first one to checkout wins... if you have limited quantity of a product, you don't want to oversell (taken care of in a way in the process)...

Anyways, hope you get the point..

[wolfderby]

Whatever you choose. Let me say this with a little "tough love"... To insert a new order, you *DO NOT* need to know the order_id that is to be inserted when creating a new order...

You insert the data (without it including an order_id) and *then* ask what the order_id has become...

Session data... doesn't matter where you are in the system, having that session data variable set allows use/reuse of existing code that handles everything you need.

Building/rebuilding a cart? Of COURSE! You're incorporating the act of making a purchase on your Zen Cart store...

As far as locking all the tables or whatever, the only order table that really matters and the only time it matters for the most part is the orders table at the point of making an insert to that one table... Once the unnumbered data is inserted which then gets a number assigned, all other related orders tables get similar additions to reference that order_id.

Personally, I think it would be more work, time and effort to "take the short-cut" than it would to do a simple search through the order class perhaps on '$_SESSION', identify all of the unique parameters and really should only need to concern oneself with the create-like methods... then considering that data, compare to the data that you are receiving from your other direction and line the two up... the order class can handle not receiving something, but also need to be sure that as a user of the store that you are going to get out of this process what you want/need... for example, the shipping, payment, and normal home address information... right now, there doesn't appear to be a consideration of ensuring that the data is "uniquely" captured in the database. Meaning if person X places their first order, on their next order if they use the same addresses will the addresses be looked up and referenced or will they just be added to the person's account.

Are these purchasers gaining access to your Zen Cart store by making a purchase through the route you are implementing? Do they already have an account? If they do have an account, what verification is being done to ensure that the purchase they are making elsewhere (to be tracked here) should be associated with the data they have in the store? E.g. What authentication has been performed to relate the purchase made at this other shopping location with the person(s) in the shopping cart?


Again, you can choose what information you're not going to store in the database about an order, but you'll want to also understand what impact that has on order/data retrieval for you and for the customer(s).

And again whatever you do... stop trying to determine the value of something that automatically determines its value on its own... Let me see if I can think of an example...

Ok, perhaps obscure, but think of it this way, the order_id is the position in a race or marathon. Whoever appears at the end of the race is given a number associated to "how they did" in the race. Once they pass the finish line that number is assigned, but they had a lot to do to get to that finish line. Some may have taken easy paths, some harder, but in the end, they were given the number at which they finished (along with their time) rather than them "appearing" out of the blue and claiming a number... the process of performing the insert to the database is what assigns that number associated with finishing the race... that's also why you'll see in some places in the forum where it is said the first one to checkout wins... if you have limited quantity of a product, you don't want to oversell (taken care of in a way in the process)...

Anyways, hope you get the point..

I think it should work if I remove my "hammering in the oID" just haven't done it yet. The various order table's autoincrement value (under operations in phpmyadmin) was high and I couldn't seem to get it to reset. However when I got the bad/high oID values out, the reset oID in the admin store manager seemed to fix it.

[wolfderby]

So I have this "working" however I was thinking of launching it publicly on a git repo, (ideally to help me get a coding job), but I don't think it's quite there yet.

Would anyone be interested in me doing a screen cap video to show this script in action? I was thinking of putting it on youtube w/ a private link because it's using my personal store data I don't quite want out there right now. (I would private message people this link)

I'd be looking for constructive criticism in hopes of this script helping other people as a possible add-on, helping me get a job like this: (https://pineapplepayments.com/jobs/p...ipt-developer/) and to just better my skills in working within other paradigms.

[mc12345678]

Know of or remember the movie "Field of Dreams"? Build it and they will come...

If concerned about the store content, then build a separate "disposable" store... Do your video (don't wait for others to chime in especially this far in a thread), launch and see what happens... Further, if you make it a plugin and offer it to the Zen Cart community you may get hits off of that as well... Besides both could exist, the github repo and the ZC plugin which would further show your "engagement" with coding and design... Also, remember someone is more likely to appreciate someone that tries rather than someone that waits...

Sorry for not responding sooner, but because I didn't visit this site between the two messages I didn't get notified of the second message to be able to respond sooner.

[wolfderby]

Gotcha good advice. Thanks.