Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


TomB01 last won the day on November 28 2019

TomB01 had the most liked content!

About TomB01

  • Birthday 12/24/1954

Profile Information

Recent Profile Visitors

8,328 profile views
  1. I started with r1.8 and the last time I looked, I could not find it on the Apps Marketplace. Hmm … guess it was my search error, because it's there, now. Anyway, those files in my post a page back should work if you start with the r1.8 version, uploaded by kymation as you say - 2 years ago. Do this to the database: Then do the stuff in this post: It should work. I've had to re-edit the modules.php file with every update of Phoenix, but my USPS shipping has been working all the way through from to I've posted this before for you, so if it doesn't work, I apologize. There may be something else with your store that's different that we're not taking into account.
  2. That fixed it in both installs! Thanks! Glad to know it wasn't something I had messed up again. 😉
  3. Question - I've loaded this on a Phoenix sandbox test store and on my proposed Phoenix primary store (both updated to This happens on both installs: clicking on the "See More" button re-orders the featured products, while removing the images. My sandbox install is using my existing 2.3.4 store's images, etc. However, my proposed primary Phoenix store is still using the default apples, lemons, tomatoes, etc. I haven't touched the images folder. The error is consistent between both. The img src tag seems to be stuck on img src="images/" in the featured_products.php file. The index.php file retains the full link to the image, but not in the featured_products.php file (it only shows the Alt Text, not the image).
  4. Turns out, I needed this, too: ALTER TABLE `products` ADD `products_gtin` CHAR(14) NULL AFTER `products_ordered`; I just hadn't gone far enough in my testing. This is an additional field that was added in Phoenix (or sometime after 2.3.4), but is ordered before two other fields in the structure list. Thus, the "AFTER 'products_ordered'.
  5. Many thanks for this add-on! I was a bit tired of seeing trivial things in my store default to the main page, just because they've been added last. Something like a Featured Products was sorely needed. For the dummies like me, though, please let me suggest some changes in the Install_manual.txt: Change this - to this - Step 3: - Edit the Header Tags Module, "Table Row Click jQuery," by ticking the "featured_products.php" Pages checkbox. - Make sure you install at least one of the following modules: under Modules-Content, "Featured Products" (index), "Featured Products" (index_nested), or under Modules-Boxes, "Featured Products." Once installed, you can activate or deactivate them.
  6. So, Select "p.field1, p.field2. pd.field1, pdfield2 from tablename1 p, tablename2 pd;" is using an arbitrary character(s) to distinguish between different tables in the same Select statement? I guess ArtcoInc is showing that, too, the way he expanded the SQL statement. Cool!
  7. Dan is correct and glad you found the solution. To others - if this will help - take a look at that error message that Krisz1 got: I'm sure this is like explaining 2+2 to some of you, but when I saw similar messages, I keyed on the "Unknown column" part. That tells you there's a field (column) missing in the database table the follow-on SQL statement is trying to access. Then I looked in the SQL "Select" statement for the "from" word. The name that comes after the "from" word in the SQL statement is the database table. You will also see the "products_gtin" field name in the collection of field names that the "Select" statement is trying to gather. So in this case, "products p" looks like the source table for the SQL statement. I don't know enough about SQL to know if the comma after that is specifying another table. I also don't know what the "p" means at the end of "products," or at the beginning of the field (column) and table names, but that doesn't matter. I'm going to check the "products" table, first. With those partial bits of information, go to the phpAdmin (or whatever client you're using) and find the "products" table in the database. Look at the structure for the "products" table in 2.3.4 and then look at the structure for the "products" table in Phoenix. In phpAdmin, there's an actual tab for "Structure." That should show you the extra fields (columns) existing in 2.3.4 that you need to add to Phoenix. You should see the "products_gtin" field in the 2.3.4 "products" table (in this example). Develop a similar SQL "Alter" statement as above, adjusting/editing for the variable type (TEXT, VARCHAR(##), etc.). Run that in the SQL window in phpAdmin on the database (don't touch the 2.3.4 one), then re-load the Phoenix store page that caused the error. It should go away. Or, at least the error changes to something else that you can also research similarly. Eventually, you should arrive at no errors when you re-load the store's page in question. Interestingly, I don't have a "products_gtin" field in my "products" table - either 2.3.4 or Phoenix. That's probably because I never installed the same add-ons that you guys did. So, maybe everyone arguing against a do-all script is correct. I had a horrible experience in the past trying to use an all-at-once SQL script for porting an OsC database (coming from MS2.2 to 2.3.4). Granted, it's not a single button-push, but maybe it really is better to encourage the logic and method of manually copying the database. Remember to back up, back up, back up - both before and after. 😉 This is very rudimentary, but hope it helps ...
  8. @burt, Ha! Right on cue: you just dropped another supporters code down the chimney! 😉
  9. Yes - no disrespect meant toward Gary. It's sort of like Santa Claus keeps pushing presents down the chimney, but you're still trying to unwrap the first one. 😀
  10. OK - did that and promptly got error messages in the Admin and fatal errors in the Store. I've been working on this, off and on, since Thanksgiving - including about two solid weeks when I was on vacation during Christmas/New Year's. If I had tried this a month or so ago, I probably would've had a heart attack. However, I've blown it up so much since then, that things are not phasing me so much anymore. Using the sandbox helps immensely, though. So ... the phpAdmin indicated a successful copy of all the tables - excepting the configuration, configuration_group, sessions, and whos_online were not copied. (Copy was done with phpAdmin as mentioned earlier in this thread.) Starting with the Phoenix Admin, it blew up on the Supporters Low Stock Alert and when accessing the Catalog->Categories/Products, not recognizing a couple of fields in the products table. I researched that by comparing to another Phoenix database and discovered that products_cost and products_reorder_level had to be added. In this case, I was able to reference the Readme files for the supporters' code (d18 and d20, to be exact) and run the SQL statements again (ALTER TABLE products ADD etc., etc.). Checking the store, it blew up with error messages on the categories_description and products_description tables. Turns out, Phoenix added four fields to the categories_description table and three fields to the products_description table. Copying the Alter statement from above, I ended up with the following that I ran on the database: I'm not sure this was documented anywhere. At least, I haven't seen it while following the Phoenix threads since T-giving. I'm coming from 2.3.4, so maybe these fields were in CE Gold or Edge? Final step was to upload all my existing catalog images and it now appears my sandbox is a working version of my store in Phoenix, with all the supporters add-ons. 🙂 I will keep testing it for a couple of days and try porting everything over to my actual store this weekend. I sort of hope Gary doesn't have another update between now and then. 😉
  11. More likely to break it, than slim it down - if I do that.
  12. Excuse me for going back to the well again, but Got SQL? (to list the settings of the tables) In particular, can you confirm the settings that are important for Phoenix? Is anyone working on a migrate-to-Phoenix-from-older-OsC Checklist? That might be a small effort for potentially great reward. I have these databases backed up six ways to Sunday, multiple copies of the databases, and an operating sandbox. So I can mess with parts without breaking anything, but it still seems daunting.
  13. Well, seems like I got a pretty comprehensive result when I used a wildcard for "id." As in: Unfortunately, the magnitude of the response to that is leading me to believe that this is close to impossible. Looks like moving the entire database is the better option. I'm just concerned because when trying that in the past, I ended up with entirely different configurations than the default Phoenix.
  14. @ecartz, This is great info - thanks! Any clue on how to find out other fields that are shared among tables? EDIT: Never mind - it's further down in your stackoverflow link - very helpful!
  15. This looks like a great strategy, but I'm having trouble finding relations between tables. Isn't the table address_book an important part of migrating customer accounts? How do I find these relations if I'm wishing to port data manually, only as few tables as needed?