[QUESTION]Manufacturer listing modification

[Kogkalidis]

I want to disable pagination in manufacturers list. So when I click "Manufacturers" all of them to appear. How can I achieve this?

[vekia]

you're talking about front offie or back office?

as far as i know front office display all manufacurers on one page

[Kogkalidis]

As far as I discovered, I suppose that there is a relationship between setting product limit per page and manufacturers per page I need front office!

[monova]

Have you figured it out? i need this also

[Kogkalidis]

Which is your version? If 1.5.4.1 there is some pagination error so pagination doesn't work so with EVERY page, you see all the brands.. So you just delete pagination code in manufacturers' tpl.

[monova]

I'm using 1.5.6.0.

I have deleted pagination.tpl from my manufacturer-list.tpl, but that's not working.

 

I have 14 manufacturers and in backoffice i have set to only show 12 products.

As you can see, in http://shop.jenci.ro/manufacturers it shows 12 of them, but you can see the other 2 on http://shop.jenci.ro/manufacturers?p=2 (second page of manufacturers), so removing pagination.tpl does not solve my problem.

 

Any ideeas?

Edited November 14, 2013 by monova (see edit history)

[Kogkalidis]

Did you check the controller? manufacturer.php or something like this (check the one in controllers folder) or something like this..

 

In general I have heard some bad things for 1.5.6. Don't implement new versions immediately

Edited November 14, 2013 by Μάγος Μέρλιν (see edit history)

[garyjj127]

Did you ever sort this out? I found that the manufacturer list in this version uses the default pagination entry for products, so if you set the default pagination in the preferences section to, say 1000, it will remove pagination from the manufacturers page (if you have fewer than 1000 manufacturers!), but it also sets the products to 1000 per page. Not ideal.

 

I have solved this, but only after editing the database:

 

1. I added a line to the PS_configuration table, copying the PS_PRODUCTS_PER_PAGE line, and naming it PS_MANUFACTURERS_PER_PAGE, giving it a value of 1000.

 

2. I edited the ManufacturerController.php file (around line 118), changing the reference to PS_PRODUCTS_PER_PAGE to PS_MANUFACTURERS_PER_PAGE.

 

3. Removed the line {include file="$tpl_dir./pagination.tpl"} (around line 67) in manufacturer-list.tpl.

 

I can now see all my manufacturers, and it leave all other pages unaffected.

Just to say, I have pretty much no knowledge of how to edit a database, so backed the table up before I did anything, and had extremely sweaty hands for a few minutes while checking my mods!!

 

I hope this helps anyone else who has the same problem.

[prestashopninja]

Geia sas,

 

garyjj127's proposition woudl work maybe and could save the day, yet I'm afraid it won't be the correct approach to alter the core database.

In fact, your simple question is quite a challange for the programmers as while there would be at least three or four decent ways to do that, it's the first time for me to see such a request and probably I'm not alone in this.

 

If it's not that urgent, I'd like to see what other programmers have to say in this so you'll also benefit from the best solution, otherwise I can share my ideas.

[prestashopninja]

Dear @musicmaster:

 

This is not to place to show your ads. There are some other parts of that forum to do it. If you have something to share, please do it.  

[monova]

do share i think there are a few

[musicmaster]

First, just like garyjj127 (post #8) I faced the question how to increase the number of returned records. I too used a hack in the function assignAll() in manufacturerController.php. My hack was inserting an extra line that overrules the PS_PRODUCTS_PER_PAGE:

$this->n = abs((int)(Tools::getValue('n', Configuration::get('PS_PRODUCTS_PER_PAGE')))); /* after this line ... */
$this->n = 999; /* ... an extra line inserted */

The rest of the mod is in the attached manufacturer-list.tpl file. Note that at the beginning I have a loop that filters out all manufacturers with zero products and puts the remaining manufacturers in a new array: $manufacturersx.

 

 

BTW I am using PS 1.5.6.1

 

 

manufacturer-list.zip

[garyjj127]

A very simple solution musicmaster, thank you! prestashopninja, may I ask why adding the extra line to the database would not have been a solution? Is it because the alterations would not be carried forward on an update?

[prestashopninja]

Because while there are more than one possible solutions without altering the core database, we need to favor them as if we ever want to upgrade one day, the auto upgrade itself may fail and/or the changes we did on the database may get lost so we'll stay with barehand, barefoot. For practical reasons like that, the theory says not to touch the core database structure unless you 100% have to.

[garyjj127]

Thanks for the clarification. I did wonder if it would affect future updates, and didn't really want to alter the database. However, the other solution has now been implemented on our site and works just as well!

[prestashopninja]

When people (third-party developers) need to alter the existing database structure, they usually intend to do what we call" database denormalization" and create a mySQL view, so that you will have two separate tables (one being the original and the new one containing your own fields) and you can use them as a single table.

 

If you are ever interested to learn more or for anybody who will need such a solution in the future, you can check mySQL's "CREATE VIEW" syntax.

[musicmaster]

I see there is a discussion about the proposal of Garyjj127 in post #8 to add a configuration variable. My view is the following:

 - the configuration table was made for that purpose. If you check the latest entries in the configuration table you will see that they are from the third party modules that you use.

 - As far as I understood, what Garyjj127 proposed was just adding an entry to the configuration table. Not changing its structure. So I don't see any problem with that in connection to updates.

 - however, it is good use to have a author specific prefix. So rather than  PS_MANUFACTURERS_PER_PAGE you should make an entry like GARYJJ_MANUFACTURERS_PER_PAGE. That way you avoid problems if Prestashop might add new functionality in the future.

 - Adding an entry directly to the database is a bit rude. You could let Prestashop do that for you. If I am correct (I haven't tested the code) it would be 

Configuration::updateValue('GARYJJ_MANUFACTURERS_PER_PAGE', 1000);

[prestashopninja]

@musicmaster: For this issue spesific, you are right and your solution will work. That was why originally I wanted to see more than one ideas. There's also another point to keep in mind: The performance. When you create a separate table and a view (which is a simple mysql "JOIN" query in turn, but the difference is that it's cached) the benchmarks would be quite different.

Anyway, after this point, maybe it's hypothetical and needlessly complicated for such in issue and thank you for sharing your solution.

Edited April 5, 2014 by prestashopninja (see edit history)

[garyjj127]

Yes I agree it's much easier to use musicmasters solution for this problem, as it's far easier to implement, and there's no need to mess with the database. I guess there are arguments both ways for adding lines to the database, as there are obviously other issues that can be solved this way. I just wanted clarification on whether database mods would impact future updates, and musicmasters last post seems like a very good idea!