Challenging upgrade and redesign issues 😳

Kjeld · 2021-02-09 11:53:30

I am about to upgrade and redesign my site Old Photos of Japan. It is currently running on txp 4.6.2 and it uses a design from 2007…

There are three issues that are overwhelming me:

1. NO MORE MLP

The site uses MLP (version 4.6.0.20160216) for English and Japanese. However, Bloke wrote that MLP doesn’t work anymore with the latest txp version.

If at all possible I don’t want to break the links that link to the site, because these articles are all evergreens and popular on sites like Pinterest.

QUESTION: How would I (re)create a bilingual site with the old links without using MLP?

2. TO THEME OR NOT TO THEME

I am doing a drastic redesign of the site. In the past I would create the new design on a separate site and then copy and paste it onto the old one. But now there are themes.

QUESTION: I haven’t yet worked with themes. Would adding the new design as a new theme be the most efficient way to redesign the site? Is there anything I should be aware of when doing this?

3. UPLOADING LARGER IMAGES

The new design uses much larger images. I am assuming the only way to get larger versions of the current images on the site is to upload them one by one in the images section. However, there are almost 700 images…

QUESTION: Do I have to upload the large versions of the images one by one in the images section, or is there another, easier and faster way to do this?

Dragondz · 2021-02-09 13:24:05

Hi

For point 3: You can uplaod multiple images at once on image tab now but how much you should test, or use fpx_image_import to upload images as ftp and then import them into txp database but it will be new imag not replacement images!

Cheers.

colak · 2021-02-09 13:24:50

Hi Kjeld,

Some responses to your questions

MLP.

Indeed it will not work. You should create a dev environment and import your db, and then update txp. This, will allow you to keep all the old links (alas not those produced by MLP), although there are other solutions:)

Solution 1

Use a deep URL schema such as /section/category/title. You could have 2 sections one for en and another one for jp. You can then use categories to organise your content. The resulting urls will look something like /en/buildings/ and for individual pages /en/buildings/osaka-prefectural-office-on-enokojima-island.

You can then make a use of one custom_field for its equivalent jp article. All you will need to do is just add the id of the article in Japanese and Link it in your page by using <txp:permlink id=’<txp:custom_field name=“translation” />’>Flag</txp:permlink>.

Solution 2

Use cookies. oui_cookie is an excellent plugin. You can have both languages in the same article and depending on the selection of cookie, this is the language you will see. The possibilities are endless here:)

Solution 3

Tested by Oleg, and makes use of pageless articles.

Old links

I forgot how the alternative language links worked in MLP. If you remind us there may be an htaccess rule but I doubt it as all articles will now be having their own ids.

Themes

As this is the first time you will be using them, I would work in a dev environment hosted either on your computer or a subdomain in your server. Finish the design and the content there, before transferring it to your main domain.

Images

With the later, txp versions you can upload multible images at a time, alas you will need to add the alts manually.

jakob · 2021-02-09 13:30:14

Interesting! Recently, I’ve been helping quite a few people upgrade from 4.6.2 upwards and for the most part it works quite well depending on the plugins.

1. Replacing MLP: I helped out someone recently with a mini language-prefix url scheme plugin so that they could do /en/… and /de/… and then the rest of the url would be handled as normal. The en or de part is separated out into a variable that can then be output or if_queried on the page.

That’s only part of the puzzle. For sections, you can either set up a set of variables to map en->ja and ja->en matching sections, or you can use a plugin like my jcr_section_custom to store the respective “partner section” with each section in the section edit pane. The site author used a similar principle for articles: a custom field holding the article_id of the respective “partner article” and a custom field denoting the current article’s lang code.

For fixed strings the site author used smd_babel, prefixing the string names with the respective lang code, e.g. en_mystring and ja_mystring.

We also used a modified version of jcr_image_custom to store the caption and alt-tag (or copyright) with each image. Again, those were named by prefixing with the lang code. You can then design your page templates using the lang code variable as a tag-in-tag to output in the respective language. It’s not perfect and depends very much on your site setup, but it worked.

2. Themes: Yes, it’s much simpler now. If you already have your pages and form templates, you can rename what’s called the “default” theme after upgrading and export that to disk. You’re done. If you were using cnk_versioning or something to work on your templates as files, you can use etc_flat in its place. That can replace the old way.

3. Larger images: You’ll need to check what your server can handle but in my experience servers now manage downsizing from larger images much better than before, so you can start with a larger image and then downsize. smd_thumbnail will allow you to make interim thumbnail sizes for things like leveraging srcset.

The new images panel can handle uploading multiple images at a time now, so it’s no longer one by one. Stef/bloke has some helper plugins for dealing with larger galleries too.

Adding new sizes to existing images: If you want to maintain the same image numbers as you have up to now, you may be able to do that with some judicious offline work on your computer. For example:

Set up some smd_thumbnail profiles for the different sizes you need them to be. They are stored in folders named according to the profile inside the images folder, e.g. /images/profile-name/1.jpg. You can leverage this principle to generate different sizes of your existing images on your computer. You might have small, medium, large, huge etc. (but it can be whatever you want). Using your favourite image resizing app, you can create the images to your exact specs in each folder, then upload them via FTP.
If you want to start from a larger image size, you may need to also update the image and thumbnail widths and heights in your txp_image table. One way to do that is to export that table to csv or excel format, then either use some cell formula to recalculate what the new widths and heights should be. Then replace the old w, h, and thumb_w, thumb_h columns with your new ones. The other way is to resize your images first, then use a terminal or command line command to lists the images with their sizes. Copy that and fashion a separate excel file out of those that matches the image names in txp_image. Now use these for your new w, h, and thumb_w, thumb_h columns. Then reimport to your database online.

Kjeld · 2021-02-09 13:36:45

Dragondz wrote #328664:

Hi

For point 3: You can uplaod multiple images at once on image tab now but how much you should test, or use fpx_image_import to upload images as ftp and then import them into txp database but it will be new imag not replacement images!

Cheers.

Thank you. Uploading images for new articles is no problem. I need to replace the current images.

Bloke · 2021-02-09 13:42:47

1. MLP

As stated above, it won’t work. It’s a hack at best. Now, if none of the solutions outlined by colak/jakob are to your tastes, I might be able to kludge MLP to work with 4.8.x. I’ve not looked at the code in years but I’m sure it’ll come flooding back. No guarantees, as things like txplib_db.php (which MLP replaces with its own session-based version) have been updated extensively. So if you can possibly use one of the other approaches then that would be preferable.

2. dev/live

If it wasn’t for the fact you rely on MLP and need to upgrade Txp from a pre-theme environment, I would have encouraged you to use it. But if you upgrade Txp in-situ now, your current site will break. So yeah, parallel dev environment this time. Themes next time!

3. Images

Difficult. As others have said, you can multi-upload but they’ll be considered new images. Can you utilise smd_meta_image here? If your image names of the incoming pictures are the same as your existing images, you might be able to temporarily turn off the article mapping/creation feature in the plugin prefs, then simply upload images as before en-masse with the plugin enabled. Assuming the IPTC data remains constant, it should overwrite your existing images and update the chosen image fields from the IPTC content. Untested, but might be worth a shot.

Last edited by Bloke (2021-02-09 13:46:07)

Kjeld · 2021-02-09 14:16:05

colak wrote #328665:

Hi Kjeld,

Some responses to your questions

MLP.

Indeed it will not work. You should create a dev environment and import your db, and then update txp. This, will allow you to keep all the old links (alas not those produced by MLP), although there are other solutions:)

Solution 1

Use a deep URL schema such as /section/category/title. You could have 2 sections one for en and another one for jp. You can then use categories to organise your content. The resulting urls will look something like /en/buildings/ and for individual pages /en/buildings/osaka-prefectural-office-on-enokojima-island.

You can then make a use of one custom_field for its equivalent jp article. All you will need to do is just add the id of the article in Japanese and Link it in your page by using <txp:permlink id=’<txp:custom_field name=“translation” />’>Flag</txp:permlink>.

Solution 2

Use cookies. oui_cookie is an excellent plugin. You can have both languages in the same article and depending on the selection of cookie, this is the language you will see. The possibilities are endless here:)

Solution 3

Tested by Oleg, and makes use of pageless articles.

Old links

I forgot how the alternative language links worked in MLP. If you remind us there may be an htaccess rule but I doubt it as all articles will now be having their own ids.

Themes

As this is the first time you will be using them, I would work in a dev environment hosted either on your computer or a subdomain in your server. Finish the design and the content there, before transferring it to your main domain.

Images

With the later, txp versions you can upload multible images at a time, alas you will need to add the alts manually.

Thank you very much for your detailed explanations, Yiannis. I will study your suggestions carefully, and see what makes most sense for my particular situation.

I have also been thinking about creating two separate sites so that the site’s messages are in the respective languages. But that would mean double uploads of images…

Incidentally, this is the current format of my urls:

https://www.oldphotosjapan.com/en/photos/835/windmill-at-ueno-hirokoji
https://www.oldphotosjapan.com/ja/photos/841/上野広小路の風車

Kjeld · 2021-02-09 14:25:09

jakob wrote #328666:

Interesting! Recently, I’ve been helping quite a few people upgrade from 4.6.2 upwards and for the most part it works quite well depending on the plugins.

1. Replacing MLP: I helped out someone recently with a mini language-prefix url scheme plugin so that they could do /en/… and /de/… and then the rest of the url would be handled as normal. The en or de part is separated out into a variable that can then be output or if_queried on the page.

That’s only part of the puzzle. For sections, you can either set up a set of variables to map en->ja and ja->en matching sections, or you can use a plugin like my jcr_section_custom to store the respective “partner section” with each section in the section edit pane. The site author used a similar principle for articles: a custom field holding the article_id of the respective “partner article” and a custom field denoting the current article’s lang code.

For fixed strings the site author used smd_babel, prefixing the string names with the respective lang code, e.g. en_mystring and ja_mystring.

We also used a modified version of jcr_image_custom to store the caption and alt-tag (or copyright) with each image. Again, those were named by prefixing with the lang code. You can then design your page templates using the lang code variable as a tag-in-tag to output in the respective language. It’s not perfect and depends very much on your site setup, but it worked.

2. Themes: Yes, it’s much simpler now. If you already have your pages and form templates, you can rename what’s called the “default” theme after upgrading and export that to disk. You’re done. If you were using cnk_versioning or something to work on your templates as files, you can use etc_flat in its place. That can replace the old way.

3. Larger images: You’ll need to check what your server can handle but in my experience servers now manage downsizing from larger images much better than before, so you can start with a larger image and then downsize. smd_thumbnail will allow you to make interim thumbnail sizes for things like leveraging srcset.

The new images panel can handle uploading multiple images at a time now, so it’s no longer one by one. Stef/bloke has some helper plugins for dealing with larger galleries too.

Adding new sizes to existing images: If you want to maintain the same image numbers as you have up to now, you may be able to do that with some judicious offline work on your computer. For example:

Set up some smd_thumbnail profiles for the different sizes you need them to be. They are stored in folders named according to the profile inside the images folder, e.g. /images/profile-name/1.jpg. You can leverage this principle to generate different sizes of your existing images on your computer. You might have small, medium, large, huge etc. (but it can be whatever you want). Using your favourite image resizing app, you can create the images to your exact specs in each folder, then upload them via FTP.

If you want to start from a larger image size, you may need to also update the image and thumbnail widths and heights in your txp_image table. One way to do that is to export that table to csv or excel format, then either use some cell formula to recalculate what the new widths and heights should be. Then replace the old w, h, and thumb_w, thumb_h columns with your new ones. The other way is to resize your images first, then use a terminal or command line command to lists the images with their sizes. Copy that and fashion a separate excel file out of those that matches the image names in txp_image. Now use these for your new w, h, and thumb_w, thumb_h columns. Then reimport to your database online.

Thank you very much Jacob for your thoughts on this and your extensive explanations. I will have to read them a few more times. Some of the suggestions are likely beyond my abilities.

smd_thumbnail is a great suggestion. I worked with this plugin previously and it is awesome (as incidentally all of Bloke’s plugins are).

colak · 2021-02-09 14:27:14

Kjeld wrote #328669:

Incidentally, this is the current format of my urls:

https://www.oldphotosjapan.com/en/photos/835/windmill-at-ueno-hirokoji

https://www.oldphotosjapan.com/ja/photos/841/上野広小路の風車

So, the urls are not handled by MLP? If this is the case things are much easier, although you may still need to manually add the other language article id in a custom filed.

Kjeld · 2021-02-09 14:31:17

Bloke wrote #328668:

1. MLP

As stated above, it won’t work. It’s a hack at best. Now, if none of the solutions outlined by colak/jakob are to your tastes, I might be able to kludge MLP to work with 4.8.x. I’ve not looked at the code in years but I’m sure it’ll come flooding back. No guarantees, as things like txplib_db.php (which MLP replaces with its own session-based version) have been updated extensively. So if you can possibly use one of the other approaches then that would be preferable.

2. dev/live

If it wasn’t for the fact you rely on MLP and need to upgrade Txp from a pre-theme environment, I would have encouraged you to use it. But if you upgrade Txp in-situ now, your current site will break. So yeah, parallel dev environment this time. Themes next time!

3. Images

Difficult. As others have said, you can multi-upload but they’ll be considered new images. Can you utilise smd_meta_image here? If your image names of the incoming pictures are the same as your existing images, you might be able to temporarily turn off the article mapping/creation feature in the plugin prefs, then simply upload images as before en-masse with the plugin enabled. Assuming the IPTC data remains constant, it should overwrite your existing images and update the chosen image fields from the IPTC content. Untested, but might be worth a shot.

Thank you for offering to hack MLP. That might cause issues again during the next upgrade, so it is probably better to create a new system now, in order to be set for future upgrades.

Using smd_meta_image to override the current images is a great suggestion. I hadn’t thought of that at all. I am going to test that in a dev environment and see what happens.

Thank you for your advice, Bloke. It is going to take me some time to digest everybody’s suggestions and try out some things. I will post here how things are progressing over the next few weeks.

Kjeld · 2021-02-09 14:39:53

colak wrote #328671:

So, the urls are not handled by MLP? If this is the case things are much easier, although you may still need to manually add the other language article id in a custom filed.

MLP inserts the language markers, but otherwise leaves the URLs alone, I believe.

I have already used up all my custom fields on this site…

I guess I could use glz_custom_fields if it still works with the latest txp version, but I have actually avoided this plugin because of the plans to give the txp core unlimited custom fields. Is there an ETA for that, or is it still more of an intention?

jakob · 2021-02-09 14:44:14

Kjeld wrote #328670:

Thank you very much Jacob for your thoughts on this and your extensive explanations. I will have to read them a few more times. Some of the suggestions are likely beyond my abilities.

smd_thumbnail is a great suggestion. I worked with this plugin previously and it is awesome (as incidentally all of Bloke’s plugins are).

I’m sure I can explain it better if you have more detailed questions. And it may not all be necessary depending on how you have your site setup and how much of MLP you were using.

Given your extensive image catalog and the need to keep article + image IDs intact, you may find that some careful manual offsite preparation of the images and the corresponding txp_image table may be much quicker than re-uploading and making things match. It feels a bit messy and requires working carefully and diligently, but it’s a one-off exercise and from then on you can add new images as required.

This is what the modified jcr_image_custom outputs:

Textpattern CMS support forum

#1 2021-02-09 11:53:30