Two textpattern instances with one image folder

demoncleaner · 2017-10-25 08:35:06

Hey Destry,

I have lately set up both. A Site with 3 languages using 3 different textpattern installs that share things via the database views. And an additional site of two languages using MLP. That is for the same client using the same templates as a basis. So I have a pretty good compareism here which I´d like to share.

1. The tables view approach:
The first install based on DB views also share the same pages (I refer to different php files in the root of my install). So if any changes are made to the pages or to css it changes for all languages equaly. The (language-)installs themselfes are in their folders /de, /en ect.

A disadvantage in my opinion is, when you use SEO-URLs (which was the main reason for me to use separate installs) you will have difficulties using general internal links.
Let´s say you have a button to your contact page in the footer. That would go to “/contact” but in the german version it would have to go to “/kontakt”. In my case I tried to work around that with some smd_macro and smd_query tricking. Where I used the Description field of the sections as a constant variable which has the same name throughout all languages to be able to refer to each other. Which at the end works fine but… I know that I will get a headache when coming back later to change something.
Furthermore I use arc_meta to do the whole SEO stuff that is needed (and it also made the original description field of textpattern available for my workaround). That works pretty nicely because I can do all SEO with arc_meta for each language. But as you may realize, this is not a very easy approach to get to where I wanted.

That´s the reason why for the next website I decided to choose MLP which I had tried in other sites before and also was not 100% happy.

2. MLP approach
In terms of maintenance and setup I would say it is clearly easier with MLP. For sure if the same person is maintaining the different languages.
~~Even though with textpattern 4.6.2 MLP is not working correctly on some minor things that would help keeping a better overview of your languages and the connected articles~~ (Thanks to spiridon this is solved) I would recommend that for easier texting simultaneously.

If you have any buttons like mentioned above it is easy to just generally point them to “/kontakt” and MLP would do the rest.

When it comes to SEO it is a problem.
I have not found a way to use arc_meta properly for each language and you won´t get SEO URLs for your sections. E.g. it will give you www.domain.com/en/kontakt and www.domain.com/de/kontakt instead of www.domain.com/en/contact and www.domain.com/de/kontakt

Right now in my opinion both approaches are not perfect and I would be super happy if in the future there would be a better way to handle multi-language pages with textpattern.

The tables view is good if you do not mind having different installs and if you see the language version quite separate. When setting up your pages you should make sure that you find a good way to handle internal links that are not part of any article.

MLP is good if you want an easy way to hop between same articles of different languages and quickly do changes. It is not so nice when it comes to SEO.

If anybody has some better ideas to get over the problems in one of the approaches it would be great. Maybe it could be helpful to change the scheme of the URLs in textpattern and just go with /id/title to overcome some problems. But that would mean that menu points would have to lead directly to articles instead of sections. Which I guess will be weird and cause some other problems or difficulties.

Last edited by demoncleaner (2017-10-25 08:59:30)

Destry · 2017-10-25 10:39:43

Wow, where’s the Like button… Thanks, demon! That is a super helpful response to put the two in perspective.

Ultimately I would prefer a single-site solution, as that’s sensibly less redundant. The client hasn’t actually bought the extra domains yet either. We’ve been poking at possible avenues to go down, assuming they even commit to the task.

I know MLP was abandoned for a while and limping along with core changes. And I know Bloke has mused over a possible core handling of multilingual content, or maybe it was a rethink for a new extension, I forget. But we can hardly expect that to happen before themes and custom fields augmentation (both very important).

The URLs is a bugger, for sure. That might be enough for the client to deter tackling (and paying for) this at all. There used to be a plugin that created pseudo URLs over actual ones; i.e. you would see the pseudo URL in the browser address. Maybe there still is such a plugin (I’m a little out of touch these last months), but I don’t know which URL would actually get picked up by the SE.

Also, I thought core now supported Meta fields… Didn’t that kind of obviate arc_meta or is that plugin super extra special in some way? (I’m afflicted with the ‘less is more’ puritanical thought when it comes to plugins.)

Thanks again.

===

Edit: Was just looking at the MLP book (er, thread) and it seems that’s been getting some attention these days. Maybe that’s going to stay the solution for languages after all?

demoncleaner · 2017-10-25 11:20:32

In fact I guess, if with MLP the URL/SEO problems could be solved it might be the easier way to go. Unless the project has some special conditions under which you would want a textpattern install for each language.

Coincidently spiridon who takes care about the MLP plugin just fixed a bug today and I thought about some additional feature on MLP. Switching between the different languages of one article in the articles view, if that´s possible, would make maintenance also easier.

So let´s think about a way to handle Metas and URLs in MLP.

You are right that the textpattern core supports meta fields. But unfortunately in the sections we only have the option for different titles not for different descriptions. So either MLP would have to be extended here or you would have to do some kind of tricking (again) so that an article could always provide the sections meta. Which I did but I do not like it (descriptions were provided by fixed articles even article_list).

About arc_meta: That gives you a whole bunch of possibilities to arrange how you want your meta data to appear. I found it very very useful for good SEO.

About the URLs… a plugin for pseudo URLs sounds good. Did not come across that plugin so far.
Or do you mean arc_redirect? I tried it already in that context but was not satisfied. But that could also have been my fault.
If that is solveable – great.

As this goes more into the direction of talking about MLP then about the actual topic, I recommend continuing here.

Destry · 2017-10-25 11:36:42

demoncleaner wrote #307522:

You are right that the textpattern core supports meta fields. But unfortunately in the sections we only have the option for different titles not for different descriptions.

Ah, I see what you mean. A different description for each language. Yeah, that would be necessary.

About the URLs… a plugin for pseudo URLs sounds good. Did not come across that plugin so far. Or do you mean arc_redirect?

The plugin I had in mind was a bit older, I think, by someone long since gone from the community. It didn’t redirect URLs, rather you could create alias URLs for those already existing. This was a solution to a common gripe people had for a while when dealing with limited categories and such. It made your content look like it was organized logically, even if it wasn’t. ;)

Kjeld · 2021-12-07 04:23:11

I have tried, but fear that I don’t have the programming background to implement the suggestions on this thread…

Would it be possible to have a “slave” site (Japanese) access images on a “master” site (English)

that uses smd_thumbnail,
and which uses jcr_image_custom to store Japanese language captions for images?

If the answers are ‘yes’, can this be done with a plugin?

jakob · 2021-12-07 10:48:23

Apologies for the tardy reply – am just back out of quarantine and there was much to catch up on.

I’ve never tried what DragonDz has suggested but agree it sounds like a compelling solution to your situation. If the Japanese site uses a second txp_image table that is essentially a symlinked view of the English site’s txp_image table, then in effect both sites can edit the data in the txp_image table (if I’ve understood it correctly).

jcr_image_custom just adds further columns to the txp_image table, so as long as you have the plugin installed on both, it should work fine. You just need to take care when activating not to overwrite any existing data. You might need to either first install on both, do the same initial setup (e.g. custom_field names in the prefs), then symlink the tables afterwards, or on your second site, you comment out the table installation routine in the plugin. The remaining functions for the admin-side edit pane and display on the page should then work from both sides in the same way the image edit pane would.

smd_thumbnail has its own table. Either you do the same symlinked view of the smd_thumbnail, or if you think your site will remain the same after setting up smd_thumbnail, you install it on both sites with identical settings. As one rarely alters the smd_thumbnail settings after the initial setup, the rest of your code should work on both sites.

Kjeld · 2021-12-07 11:14:01

jakob wrote #332109:

Apologies for the tardy reply – am just back out of quarantine and there was much to catch up on.

I’ve never tried what DragonDz has suggested but agree it sounds like a compelling solution to your situation. If the Japanese site uses a second txp_image table that is essentially a symlinked view of the English site’s txp_image table, then in effect both sites can edit the data in the txp_image table (if I’ve understood it correctly).

jcr_image_custom just adds further columns to the txp_image table, so as long as you have the plugin installed on both, it should work fine. You just need to take care when activating not to overwrite any existing data. You might need to either first install on both, do the same initial setup (e.g. custom_field names in the prefs), then symlink the tables afterwards, or on your second site, you comment out the table installation routine in the plugin. The remaining functions for the admin-side edit pane and display on the page should then work from both sides in the same way the image edit pane would.

smd_thumbnail has its own table. Either you do the same symlinked view of the smd_thumbnail, or if you think your site will remain the same after setting up smd_thumbnail, you install it on both sites with identical settings. As one rarely alters the smd_thumbnail settings after the initial setup, the rest of your code should work on both sites.

Thank you for the additional information. Glad to hear that you came out of quarantaine safe!

Good to know that jcr_image_custom will work.

Although I understand the theoretical part of this thread, I fear that I don’t understand the practical side…

What do I need to do (step by step) to get this working on my sites?
(I guess I need to ask DragonDz?)

Kjeld · 2021-12-08 11:44:08

TWO INSTALLATIONS, ONE IMAGE FOLDER

I have been reading DragonDz’s explanations again and again.

Is the following understanding of the needed steps correct?

Two installations share the same DB: one for English (master), one for Japanese (slave)
The English installation has no prefix
The Japanese installation uses the prefix ja_
Rename (or delete) the ja_txp_image table
Rename (or delete) the ja_smd_thumbnail table
In phpMyAdmin, select the DB, and then SQL
Type CREATE VIEW ja_txp_image AS SELECT * FROM txp_image and hit “Go”
Type CREATE VIEW ja_smd_thumbnail AS SELECT * FROM smd_thumbnail and hit “Go”
Go to the txp admin > Preferences > Admin of the Japanese site and change the relative path in Image directory to that of the English installation

a) Is this it? Am I missing or misinterpreting something?
b) Is there anything that can go wrong?

Bloke · 2021-12-08 11:57:21

Kjeld wrote #332129:

Is there anything that can go wrong?

Should work fine as long as your MySQL user has CREATE VIEW permissions.

You might have some fun if two people are editing the same image on two installations, but to be fair you’d probably have the same issue if two users were editing the same image on a single installation!

EDIT: and, as jakob says, you must have the plugins installed on both sites.

Last edited by Bloke (2021-12-08 11:59:15)

Kjeld · 2021-12-08 12:48:39

Bloke wrote #332130:

Should work fine as long as your MySQL user has CREATE VIEW permissions.

You might have some fun if two people are editing the same image on two installations, but to be fair you’d probably have the same issue if two users were editing the same image on a single installation!

EDIT: and, as jakob says, you must have the plugins installed on both sites.

Oh, so I finally figured out how I have to do this! Without a background in SQL I had no idea what the CREATE VIEW thing was about…

Thanks, Bloke! (And good to hear from you again)

Kjeld · 2021-12-09 02:06:51

Alas, I use MediaTemple Grid, and I just found out that they don’t allow the CREATE VIEW command…

Any suggestions for an alternative solution to share the same image folder?

Bloke · 2021-12-09 10:09:25

That’s a bind. Not sure if there’s any equivalent to CREATE VIEW. There’s CREATE TEMPORARY TABLE which can be used in a similar sort of way to make a ‘copy’ of another database on-the-fly but that’s more invasive as it needs to be done every session. Wouldn’t advocate that.

I wonder if there’s any way you could host a dedicated ‘image only’ Textpattern and use rah_swap to fetch stuff from it in your templates. So you could set up a shortcode maybe as a wrapper for <txp:images> which first connected to the images database. I’m not convinced that would work very well and it would require some additional plugin support for the Images panel (and Write panel if you use com_article_image or an equivalent plugin to help with adding pics to articles).

Can’t think of anything else off the top of my head, sorry.

Textpattern CMS

Textpattern CMS support forum

#37 2017-10-25 08:35:06

Re: Two textpattern instances with one image folder

#38 2017-10-25 10:39:43

Re: Two textpattern instances with one image folder

#39 2017-10-25 11:20:32

Re: Two textpattern instances with one image folder

#40 2017-10-25 11:36:42

Re: Two textpattern instances with one image folder

demoncleaner wrote #307522:

#41 2021-12-07 04:23:11

Re: Two textpattern instances with one image folder

#42 2021-12-07 10:48:23

Re: Two textpattern instances with one image folder

#43 2021-12-07 11:14:01

Re: Two textpattern instances with one image folder

jakob wrote #332109:

#44 2021-12-08 11:44:08

Re: Two textpattern instances with one image folder

TWO INSTALLATIONS, ONE IMAGE FOLDER

#45 2021-12-08 11:57:21

Re: Two textpattern instances with one image folder

Kjeld wrote #332129:

#46 2021-12-08 12:48:39

Re: Two textpattern instances with one image folder

Bloke wrote #332130:

#47 2021-12-09 02:06:51

Re: Two textpattern instances with one image folder

#48 2021-12-09 10:09:25

Re: Two textpattern instances with one image folder

Board footer