HTML / Liquid scripting

Here's my dillema:

When someone in our company orders equipment that is assigned to a certain commodity, and it's shipped to a NJ location, the coding should show a certain address. In this case, the address should have NJEDA in the company name. Someone ordered something recently and sent it to a NJ location but the address that came out was incorrect. I'm trying to find out where the problem is in the coding I've attached. I tried to clean it up a little to make it easier to look at. I used Notepad++ when I did it. Can someone take a look and let me know if they see the problem? I'll help in any way I can. It's the BILL TO section in the code that should be showing the NJEDA address. That starts around line 155 looking at it in Notepad++.

Thanks in advance,
Chris

 

I don't use Liquid, myself, but the code is pretty straightforward. Since it was shipped to a NJ location, assign ship_outside_nj = true shouldn't have executed. Can you tell what the ship_to_address.state field was? Could it have been "nj" (lowercase,) "Nj" or something? Maybe try this:

Code:

					{% capture statecode %}{{ ship_to_address.state | upcase }}{% end capture %}
					{% if statecode != 'NJ' %} 
						{% assign ship_outside_nj = true %} 
						{% else %} 
					{% endif %}

I'm not sure what the else is doing after the assign ship_outside_nj = true, but I doubt it would cause a problem like this. It's still a problem for the text "New Jersey." I don't know if you use a select box to get the state code or if it's just user input. Either way, you might want to validate it before it gets to this point to make sure it's a code you expect. You could check that it's length is 2 or compare it with a list to make sure. Like I said, I don't have experience actually making something in Liquid, so I could have missed something. This is my best guess.

 

You know what I noticed.....there is a /DIV tag missing in one of the addresses. Do you think that could cause the problem? I wouldn't think so, but I'm still waiting to hear what address it actually went to. As for the state, the admin showed me how an address is added. STATE isn't even required in the first place (how dumb is that?). There isn't anything stopping someone from putting in the whole state name, or putting the state right after the town (Anytown, NJ) which wouldn't get picked up since it's in the wrong field. I'm going to fix the DIV tag and have them test it. I'll post results when I get them.

 

I also doubt that not closing a div would cause the wrong address to display, though I'm not impossible to surprise.

It sounds like you are on the right track to find a solution. I sympathize. In most other languages, it's important to know where the data comes from, and what it's been through, to avoid things like injection attacks. That isn't as much of a problem in Liquid, as an injection should only affect the one page, so people are more confident in the security. Unfortunately, that can mean they pay less attention, making it harder to have the specifics of what to expect in the variables. You know the situation better than me, but from what I assume, if it were me, and they don't change the form and validation to guarantee a 2-letter, uppercase, state code, I would try to make the code extract the information considering the possible inputs a visitor might give. For an input that is too hard for the code to figure out, I'd provide either a default address that could handle any request, or an error page if there isn't such an address. The error page could be one of the following:
If the address has already been recorded, or it's not possible to correct, the best you could do is probably to just ask in a form or script if the address is in New Jersey, if that would work. That's one of those redundancies that could annoy me in a site, but I'd rather answer a question I already answered than get an error message. If the address hasn't already been recorded, or it's possible to change it, I'd give some help knowing how to fill in the form, and link back to the form or another one that can change the data. If it could redirect to the form, filling in the information as entered, and give help to know what to change, it would be more professional, if it is possible. If not, it might be possible to recreate a copy of the form, though this would require more maintenance etc. and is likely outside your job. If nothing else, I'd make the script send an error message to the user and log it on the server or alert someone who can fix it.

I hope they fix the form validation, as I think forms should be the handler of user input, not scripts like yours which handle the information already gathered.

 

Yeah, tell me about it. I was just run over by the bus. I was asked if I knew HTML and next thing you know, I get this in my inbox. I have no problem looking at it all, but don't ask me to recode as that is not my job. The code was provided by the company the hosts the whole thing. They should be the fixers. Still no word on if it worked or not. The wheels here spin slowly.