Database query help please

[Kofod95]

https://github.com/CE-PhoenixCart/Phoen ... es.php#L56

It seems you're right. This line would need to read the id from the url instead of the cart-session.
My suggestion: copy and rename the module, its template and language file(s). Make the change in the new module, and change all references to the name (ie the class, the config-keys, the language constants and the defined name) to fit your new module. Uninstall the core module and install your new module.

//Daniel

[bestmate]

Thank you @Kofod95

I appreciate your help with this. Many thanks. Unfortunately, I am new to phoenix and have only newbie knowledge. So, approaching your suggestion is not something I am competent to do. Is there another way, perhaps?

[Kofod95]

There's always another way
Tomorrow evening, if you haven't sorted it by then, I'll see if I can do something that would help you do this. Time doesn't permit it before, sorry.

//Daniel

[bestmate]

@Kofod95 You are so kind, thank you very much. I appreciate your help with this.

[Kofod95]

Sorry, we got an unexpected (but welcome) visitor, so I didn't get around to it tonight. I'll try to find the time tomorrow, though!

//Daniel

[Kofod95]

First of all, there are several ways to accomplish what you want:

1. Use the built-in auto-selection as is, which means adding the product to the session-cart before the module loads and remove it again before the full page is served to the customer. A big draw-back here, is that you would have to update any shopping-cart loading before the drop-down selection, unless you’d want customers wonder why their cart is not empty, only to find it empty when they click.
2. Create a new module that has the exact behavior you want.
3. Use Javascript to change the selection based on the data in the URL
4. Other ways; some I haven’t thought of and some that I just don’t want to present too much in-depth

For number 1, I’m not sure how I would go about it. Perhaps a hook that reads the value from the URL and adds it to the cart, if the attribute-values are there and later removes it again, with some sort of check to make sure it only removes if it was added by the hook. This is not really a method I would pursue, but whenever I have to do something, I usually look at what core does first, to see if I can extend that in some way to work in my situation. In this example, I can’t see a good way (which doesn’t mean that there is none – I’m only a hobbyist!), so I will move on to other solutions.

Number 2 (lol!) is always a possibility. Most of PhoenixCart is made up of modules, meaning you can easily move things arround or even remove it. Of course, certain things is needed in order for the cart to function, but instead of locking a certain behavior, Phoenix enables you to customise and leaves it up to you to make sure that you didn’t forget to install a continue-button in the shopping_cart, if you uninstalled the core one.
Modules can of course be completely new things, adding functionality not inherent to the core of Phoenix, but they can also be an exact copy of an existing module with nothing more than the name changed. If you wanted to, you could add 10 modules with ”Buy” buttons on the product info page, all using the same code, but with different placements and sizes. Silly example, but I know some have duplicated the ”Buy” button in order to have two; one at the top and one at the bottom of the page. My point with this is only to make clear that creating new modules is rather basic, and anytime you are looking at something in a module, you know you can easily customise this in any way your skills allow you to.
There are already some ressources available to guide you into making a new module:
https://phoenixcart.org/phoenixcartwiki ... ent_Module
https://phoenixcart.org/phoenixcartwiki ... _Example_2
viewtopic.php?p=10963#p10963 (and the following post)
For your need, it’s quite simple: You only need one little change in core behavior, so copy either includes/modules/content/product_info/cm_pi_options_attributes.php (and includes/languages/{language}/modules/content/product_info/cm_pi_options_attributes.php for each language as well as includes/modules/content/product_info/templates/tpl_cm_pi_options_attributes.php) or includes/modules/pi/product_info/pi_options_attributes.php (and ncludes/languages/{language}/modules/pi/product_info/pi_options_attributes.php for each language as well as cludes/modules/pi/product_info/templates/tpl_pi_options_attributes.php) and make the change at the line that controls the pre-select (line 56 in the content module that is pre-installed in a clean install, line 69 in the PI-module:

Code: Select all

? $_SESSION['cart']->contents[$_GET['products_id']]['attributes'][$option_id] ?? ''

change to (eg)

Code: Select all

$selected_options_array[$option_id] ?? ''

and add something before the loop, that populates that array. This could be like this (inserted in line 32-39 of the content module, 45-52 in the PI-module)

Code: Select all

		$url_options = explode('{', $_GET['products_id']); 
		array_shift($url_options);
		$selected_options_array = [];
		if(!empty($url_options)){
		  foreach($url_options as $selected_options){
		    $selected_options_array[strtok($selected_options, '}')] = substr($selected_options, strpos($selected_options, '}') +1);
		  }
	    }

It might not be the prettiest code, and there are probably better ways to achieve this, but that was what I could come up with that allows multiple options and values in the url. What it does, is making an array based on the url, remove the actual products_id from the array, and if the array still has stuff in it, then make a new array with the option from the url as key and the value from the url as value.
When that is done, you can install your new module and uninstall the old. There should be no difference, other than it allowing you to control the options. It may be worth it, adding some kind of override, so that attributes added to the cart will take priority over linked attributes, just to avoid confusion, but I’ll leave that to you.
By making a new module, you know that your changes will never bee lost when updating your store. You still, of course, need to maintain this new module yourself, but since it’s not very different from the core, you should be able to update it with copy-paste, and every customisation you do will be your own responsibility anyway, so the simplest possible change, is the one that will be easiest for you to keep updated, which means that new modules are rather easy to maintain.

For number 3, you’d need a hook or a header-tag module to inject your JavaScript (listen_injectSiteEnd() would be a fine listener). The hook will be a simple upload, which I think would fit better here, while the header-tag can be installed and configured, so fits well for things that require various ”settings” to be confirgureable. This method, using javascript, has the drawback of adding js-code to do something the php code already is capable of, but it’s a rather simple solution that does not require too much work (write some js, put it in a hook, upload, done).

For 4, you could go into overriding either classes or the template. Every template-file can be placed in your selected template (override in a clean install) in a directory structure that matches the one it came from (just note that the template directory comes first in the template instead of last as it does in the module directory, so here it would be eg templates/{your_template}/includes/modules/content/product_info/tpl_cm_pi_options_attributes.php), to override the matching core template file. I haven’t looked into this for your example, as the logic with the pre-selection is done in the module, but you could in fact just scrap the output totally and replace with your desired output.
Classes can be overriden in includes/system/override, but I haven’t tried whether overriding a module-class is possible or not. If so, that may be even more simple than creating a new module, but a new module is, in my opinion the cleanest, which is why I went ahead and wrote the necessary changes for that.

The above lines assume you are using version 1.0.8.20, so they might be different on other versions.

//Daniel

[Kofod95]

Oh, and by the way...

I would recommend you to do things like the above on a test site first, to avoid any errors live.
Personally, I help two different stores. Both of them are build and tested on my PC, using Xampp.
My Xampp has quite a few installations of Phoenix; one for each of the shops, one for everything I want to try out and one for my own add-ons. Further, I sometimes install a new one to test something specific that would interfere with a lot of other things, but that's probably just me.
So, when I develop add-ons, I begin in my "add-ons" local install and create it there. Once happy, I install that set in the copy of the site it's supposed to be added to, to make sure it works fine with other add-ons and customisations.
Further, both stores exist twice online; one live on the main domain and another hidden in a password protected sub-domain. This means, that everything I do is tested locally first, to make sure the code even works, next it is tested on the sub-domain to make sure no server configurations messes with my code and only then is it added to the live site. Should anything not work as desired, I make the changes needed locally and re-upload to the sub-domain, which makes sure that my local install always mirrors the live install.

//Daniel

[bestmate]

@Kofod95

Hello Daniel,

Thank you so very much for your help with this. I finally got it working. What I did was create a hook with JavaScript to capture the selectbox option, then pass it back to the product_info page in the URL. I also modified the pi_gallery.php file to capture the selectbox option, query the database, fetch the colour name, convert and attach it to the active_image name to display image with colour selected.

@burt

Thanks to everyone on here that contributed to getting a solution and giving me some Phoenix knowledge.