Finding out which TPL generates which page

[declanwmagee]

Sorry, me again with another silly question...

 

I am finding that I am looking through TPL files too often looking for specific strings.  Is there an easy way (in the Chrome element inspector, for instance?) to find out which TPL file is generating a PrestaShop page?

 

thanks

 

Declan : )

[Bill Dalton]

It often isn't which page ... it is what part of the page.

 

Header.tpl and footer.tpl in  your theme is much of what you see. However most themes are using a custom module for the footer. If you are on a product page in addition to header and footer you will use product.tpl, your ajax cart will add another tpl to the mix. So the pages are a mix of tpl organised by blocks and several modules and their tpl files can be assigned to each block and each has a position that you can change and arrange.

 

If you are looking for strings, are you trying to edit the string?

Edited December 16, 2013 by Bill Dalton (see edit history)

[declanwmagee]

Thanks for getting back to me, Bill!

 

I found the one I was looking for.  It was category.tpl.  Here's what I was trying to do:

 

I have been assigning pictures to my categories.  I am a coin seller, and coins are round, so my pictures were square (like my avatar).  In most cases, ,that's fine, but on each category page the image is defined as "category_default", which is 500 x 150.  This form factor makes sense with the page layout, but left huge white areas either side of my little square picture.  In order to fit that form factor, I decided to do a 500 x 150 crop of an example of each category (just the top of the coin), as this would look quite fun, and would avoid the customer thinking the image was a product for sale, which it isn't, it's just a nice example of the category.

 

So far so good, but then moving onto a category with subcategories, the page uses the "medium_default" image, which is a little square, which didn't cope well with my 500 x 150 cropped image.  So I was looking to change the image the subcategory links use to "category_default", same as the category page itself.

 

And, by tracking down the right TPL file, I did manage it, and am quite pleased with myself.

 

I suppose it's just a case of learning how all the TPLs fit together!  And it seems there's no easy way to find out which one is generating which block in the page.  I was thinking there might be a way of seeing which TPL is controlling the content, like you can look up which CSS file is controlling the style of an element in the inspector.  

[Bill Dalton]

 

am quite pleased with myself.

 

I know exactly what you mean.  Real satisfying when it all comes together.

 

Sounds like you are having fun. See you around.

Edited December 16, 2013 by Bill Dalton (see edit history)

[declanwmagee]

Well, I've been through EVERY tpl in all three places where you find them (modules, theme/default, and theme/default/modules), and I just can't find where this:

 

 

...is drawn from.  Each of those locations has a couple of likely candidates, in blockmyaccount and blockmyaccountfooter, and also my-account.tpl, but the list items in all these are not the list items in the MyAccount block that is actually being used.  

 

How do I know?  Because all I'm trying to do is correct the spelling mistake "My credits notes", and that syntax isn't used in any of those tpls.  

 

Where else can it be?  I haven't looked in any .js or .php files - should I ?

 

thanks in advance - I am getting much more familiar with how it all works, but this one has stumped me.

 

Declan : )

Edited December 16, 2013 by declanwmagee (see edit history)

[Bill Dalton]

For this type of thing go to, Localization >  Translations

 

Notice the selection box, the default is Front office and that is what we need for what you are looking for. Click on the English flag. When the next screen appears it is best and faster to use your browser search this page function and search for the line you wish to edit.

 

Using this method you may edit almost all of PS and installed modules. It has the added advantage of not messing up translations if you use more than one language.

[declanwmagee]

Thanks for the reply, Bill!

 

Clicking on my little flag gives me this:

 

 

I only have one language installed - UK English (I took out US English because I didn't want to have to duplicate everything), and as you can see, I'm just using the default theme.  Trying to keep it simple while I learn...

 

PS 1.5.6.0 on localhost if that's relevant!

[Bill Dalton]

Easy fix

 

Find where you installed PHP. Find you php.ini

 

Read this article,

http://presto-changeo.tumblr.com/post/17589539698/understanding-php-ini-how-and-why-you-need-one

 

 

suhosin.post.max_vars = Maximum form elements that can be submitted in a page. In Prestashop this is important for the Tools->Translations page which can have thousands of textbox’s in which to enter translations, so make sure this is set high enough (10,000 should do the trick).

[Bill Dalton]

Although you do need to fix up your php.ini, very simple thing to correct, if you are working on your web site locally on windows. Here is a great tool to have for the amazing price of FREE.

 

http://www.wingrep.com/

 

Sometimes you do need to search files, and that is when this program will come in handy. That said, you will seldom need it after we get your php.ini fixed up.

[declanwmagee]

Beautiful, Bill!

 

PHP.INI fixed, and now the page is full.

 

I found the spelling mistake, fixed it and saved, but the change hasn't been reflected in the front office - probably a caching thing - I'll get back to you on that.

 

Still none the wiser as to where that list is generated from though!  I'd like to take some options out of it too, if I can find it (credit notes for starters - I'm not in the habit of dishing them out!).

 

I don't suppose your wonderful translations page can tell me where these fields are, in reality?

 

EDIT: but I bet your WinGrep can....I'll do the caching thing first, then try and find it with Grep

Edited December 16, 2013 by declanwmagee (see edit history)

[declanwmagee]

Found it!  In a translation .PHP file in the blockmyaccount module

[declanwmagee]

...which means that the list is where I thought it was, it was just the rogue phrase that was being replaced by the module translation file gb.php

 

Full steam ahead!

 

Thank you Bill, and thank you again! 

[Urbanfarmer]

"Easy fix

 

Find where you installed PHP. Find you php.ini"

 

 

I have the same problem. I'm behind the learning curve. I am looking in cpanel and can't find where I installed php. I assume I'm in the wrong place. 

[declanwmagee]

Is your installation hosted, Mr Farmer, or is it local?  If it's hosted, try looking in your root directory, and if there's no PHP.INI in there, you can create one with the relevant handful of settings:

 

http://presto-changeo.tumblr.com/post/17589539698/understanding-php-ini-how-and-why-you-need-one

[Urbanfarmer]

It is hosted. I just created php.ini in /home/username and added the suggested 7 lines from the article, but nothing changed. I still get that limit warning. 

[declanwmagee]

Mine's hosted locally, and I restarted Apache and MySQL just to be on the safe side.  You can't do that, of course.  

 

Sounds like PHP can't find it.

 

Is there no directory called PHP one level up from your home directory?  Perhaps they won't let you see that far up.

 

We need someone who knows more about hosting - Bill?

[Urbanfarmer]

Nothing above home. I went to my Inmotion php admin to look around and don't understand anything about it. I didn't see anything remotely related. 

 

I hate learning curves......, but overall I'm very impressed and happy with PS. 

[Bill Dalton]

Urbanfarmer, if putting the php.ini in your root dosen't do it you'll need to contact your host support and request the change.

[Urbanfarmer]

I just talked with Inmotion and they said to put it in /public_html, which I did. I hard refreshed both the cpanel and translations page. No change.

 

So I have a php.ini file and I put in this:

 

 memory_limit = 64M

max_execution_time = 1000;
max_input_time = -1;
post_max_size = 20M;
upload_max_filesize = 20M;
max_input_vars = 10000;
suhosin.get.max_vars = 10000;
suhosin.post.max_vars = 10000;

[Bill Dalton]

Urbanfarmer, here is an interesting article about how the php.ini works at your host.

 

http://www.inmotionhosting.com/support/website/php/recursive-php-ini

 

 

Step 5.In order for your memory limit to take effect you will need to make the php.ini recursive.
Important! Making the php.ini recursive is an important step. If you do not know how to do this, please see our article on Make the php.ini recursive in the .htaccess.

[Urbanfarmer]

Solved for me. I ended up chatting with Inmotion (great customer support). They had to create php.ini in the root. I then pasted the changes from the blog and now I've got a huge page with a lot of red and white fields. I'll have to figure out what these are and what I can do with them.

 

Thanks for the help.........

[declanwmagee]

Hooray!  We've all learned stuff today.  My site is still on localhost, so it's good to know about some of the pitfalls when it's ready to go online...