[done] Enhanced advanced search Reply to topic

Hi. I wanted a search function in Storez which would display products in the same way that they are displayed in the store rather than as a simple list. To bring it inline with many current examples of Online Store systems.

I noticed a minor problem in the new adv_search.php in that the list selection for the SQL call was a rev out of date. So while fixing that, I set about enhancing adv_search to handle both the existing list outputs, and a new templated product output. The existing single page and multiple page options are still supported in both views.

A new block Product Search is also created which uses the new adv_search.php, and defaults to displaying by products, but the block can be easily changed to display as a list instead.

adv_search.php search capability has been extended to allow search by Featured Products or by Promotional Product. These can also be selected by URL GET options. In line with this the Featured and Promo blocks have been changed very slightly to update their links to "All Featured Products" and "All Promotions" instead of simply linking back to the whole Storez module.

The idea is that the GET options plus the product template could also be used to create a center block displaying all promo or featured items as a scroller or similar. (Not yet implemented - )

The attached zip contains all the new files, plus a text file for changes/additions to the english language file for Storez. The updates are released to the Storez community as GPL v2 or later, containing my copyright in addition to others where appropriate, for inclusion with or use in tandem to Storez 9.5.0. Tested on DF 9.2.1.

Thanks for the continued work on Storez!

Noted - I'll review before a future release.

Reviewed - unfortunately you dropped stuff that others use, dropped code that you assumed to be redundant, and then re-formatted other sections, which means I can't use your file.

With sql queries, I have to provide for v10 requirements for sql strict - in particular, the use of GROUP BY - when you SELECT *, you then have to GROUP BY every one of the 50 product fields.

I have rationalized the code and templated everything, rather than just have bits of template here and there.

I've adjusted Featured and Promo to be 'either/or' rather than just 'and' on the basis that Featured and Promo will often produce a zero result.

The final result should meet your needs without diminishing the needs of the rest of us.

Phoenix wrote

With sql queries, I have to provide for v10 requirements for sql strict - in particular, the use of GROUP BY - when you SELECT *, you then have to GROUP BY every one of the 50 product fields.

Could you explain that a little more please? I must be misunderstanding something, as I've run my dev site permanently in @@SESSION.sql_mode STRICT_TRANS_TABLES for several years. And the code worked there.

And

only netted me "Database changes
Note: database will operate under sql strict conditions - more later." So any insight gratefully received. Am I looking at a huge task to upgrade Pro_News to v10?

As to the changes to Storez code it is your module and you are, of course, entirely free to make/not make any changes you wish.

It's not about my insistence on coding methods.

Fair comment, in that it's not STRICT_TRANS as such.

Probably worse in some ways - actually TRADITIONAL plus a couple of nasty twists like ONLY_FULL_GROUP_BY.

I know from bitter experience when I was running v10 CVS and it was turned on its head by DJs changes from 18 months ago. Back then, error reporting was abysmal, so it took me a while to work out wtf was going on.

Since that time, I have been changing all instances I came across, plus there's his insistence on ISO syntax "LIMIT x OFFSET y" and a few other quirks that arise e.g. remove any "LIMIT 1" as part of an unbuffered query.

DJ turned it ass up again two months ago and made it crystal clear that he will change HIS cms as he pleases without regard for anyone else, so I abandoned all work on and with NeverFly, but I still maintain those standards in Dragonfly (v9).

I doubt you will have problems adapting pro news, but it may help to start making adjustments as you come across them now, rather than later - I haven't detected any issues with the adjustments under v9.

In any event, I think you will find that I have managed to accommodate your needs - please let me know if that is not the case.

On the plus side, you and Movix stimulated me to get my mind back into Storez

Thanks for the explanation. I've no issue with essentially full ANSI SQL, just didn't understand that was what we were talking about. Was the only version available when I learnt SQL in c. 19..., errr, well just after System R was developed!!! (Was working on the other side of the interface then.) Guess it must make compatibility with Postgre etc easier.

I don't think I use aggregated values in PN anyway, everything is pure data relationally.

Yeah, I've stayed steadfastly away from v10 as I figured it'll be 12 months from initial release to production use at least. 12 months after "sometime" is way too distant for me to grapple with. 😉

I don't mind the time "NeverFly" 😉 is taking, but I am upset that it has essentially forced v9 to a standstill feature-wise (ForumsPlus being the only really big exception.)

And how will it ever get tested with so few ... ? Look what happened to 9.2.3: out there for a year so assumed trouble free, but only a few had actually managed to clean install, so it wasn't really used, and thus tested, until the 9.3 updates started to come out.

Think I'll move up to 9.3.3.1 test/dev as soon as I get a chance.

Oh, and I meant what I said, choice of what goes into Storez is yours. I just needed an end-user Search which would let a user find 1 specific item out of dozens which were very similar (all same brand, similar labels, but different flavours, sizes, etc.) and order straight from the search results hence the template. Having developed it, seemed reasonable to submit. As it happens client has delayed so my version my never go live per se.

Thanks again.