Moving PW is creating problems with TinyMCE images

[dreerr]

Dear PWers,

I'm currently moving a site from my local installation http://domain.local/ to a server subdirectory http://domain.com/temppath/

While moving mostly everything went well. Except one issue, maybe you could help me here: Every Textarea with a picture added to it (through TinyMCE and the Select Image button) is inserted with a full path (of course) like this: 

<img src="/site/assets/files/1/file.jpg">

So the only option for the current content to correct would be to search and replace inside the MySQL db to change "/site/assets/..." to "/temppath/site/assets/..."

Maybe there is a nicer way to do this? And when I'm moving to my final destination from http://domain.com/temppath/ to  http://domain.com/ should I search&replace inside the MySQL again?

Third option would be to redirect the site directory for the time the installation remains in temppath with 

RewriteEngine On
Redirect /site/ /temppath/site/

but then what would be with the content created during the time period of the PW installation inside /temppath/?

So I'm not sure what to do there. In my case it doesn't matter too much, because there are only a couple of sites created, but I'm interested in the best practice here!

All the best, so long, Julian.

[Philipp]

I know the problem you described. Normally, I just fixed the paths by hand in the editor - possible if you only have around 10 images used. My current workflow is to develope a site under a subdomain, for example dev.example.com and later make it example.com . So I'm just avoiding sub-directories. 

Maybe it would be possible to replace all <img src".."> directly with some SQL Queries and a little bit of Regex magic.

[dreerr]

Yes I agree, a subdomain would be the best solution! I replaced it in the SQL query and it worked.

Another question here: Does PW use Serialized PHP Arrays for content saving or is it save to play around with the MySQL directly?

[diogo]

You can use the Page link abstractor module to prevent this from happening http://modules.processwire.com/modules/page-link-abstractor/

[ryan]

Does PW use Serialized PHP Arrays for content saving or is it save to play around with the MySQL directly?

It depends on the field as to how the data is saved. But for textarea/tinymce it is saved exactly as it is presented, meaning just the HTML that TinyMCE provides. It's okay to edit it by other means. 

The way I usually solve the TinyMCE static links issue is to perform a search/replace on the DB dump file after exporting it from dev and before importing to live. I guess it's just become part of my workflow. But I really would like to find a native/built-in solution for this particular issue so that nobody ever needs to think about it. 

[dreerr]

Page Link Abstractor Module, Ryan what didn't you think of? 

I think the best way for me would be the subdomains, also for client testing...

Thanks for the answers!

[Joss]

 But I really would like to find a native/built-in solution for this particular issue so that nobody ever needs to think about it. 

I keep staring at the back end of Joomla to work out how they deal with it, but the only thing I can think of is that they define two base URLs - one for the backend and one for the front end. That way they keep in sync without having to worry about the fact that the admin is in a different directory.

But to be honest that is a guess.

[ryan]

I keep staring at the back end of Joomla to work out how they deal with it, but the only thing I can think of is that they define two base URLs - one for the backend and one for the front end. That way they keep in sync without having to worry about the fact that the admin is in a different directory.

The only way I know to do it is: Replace the static URL in the HTML before it gets saved to DB with a placeholder that gets resolved at runtime, like "{root-url}site/assets/files/123/file.jpg", where the {root-url} portion gets replaced with $config->urls->root at runtime. This is essentially what PageLinkAbstractor does. The only problem with this is that it creates a dependency of the text/html on the Fieldtype. If someone converts it to another field, or exports/imports to another system, etc., then it'll be broken. Maybe that's okay, but not ideal. 

[Joss]

When I look at what is saved in Joomla, it is just the path to the images directory as a relative path - eg: images/storyimage/myimage.png

So, as long as it knows what "relative" means, then it will render the image. It does not matter whether the installation is in a sub-directory or not; it doesn't care as long as it knows what the base URL is.

The {root-url} in your example above, should just be a value in the template that means it always knows where site/ is (rather than /site/, if you see what I mean).

Then, if a similar value is available in the backend, then TinyMCE should save images just as site/assets/ or /site/assets/ (not sure which is best - probably without the first slash)

[ryan]

So, as long as it knows what "relative" means, then it will render the image. It does not matter whether the installation is in a sub-directory or not; it doesn't care as long as it knows what the base URL is.

Does it swap in the actual directory at runtime? Meaning, if you click the "HTML" button in TinyMCE, do you see the correct URL rather than the relative one? Ultimately though, if they are storing a directory that is a placeholder it's the same problem in that the content lacks portability. But it at least sounds more portable. Handling directories for files/images is one thing, because the URL has common elements for all of them. But handling URLs to other pages is another matter. 

[Joss]

No, in the "source" of the editor it shows the relative one - the same as will be used when the data is used on the front page of the site. So if you move your site, none of the internal links to images, media, etc break. Not opening slash. 

You have to remember that with Joomla, the admin is in a fixed directory "administration"

Joomla uses a variable that defines the base url -  JURI::base() - not sure if that comes into play somewhere so that it away knows where it is. This is not something you have to set up at installation or change when moving the site from root to sub or whatever.

When you move a Joomla installation, the only thing you have to change is in the config which is the ab path to the logs and tmp folders - they are outside of the Joomla ecosystem as such. Unlike Wordpress, where you need to change values in the database itself, which is a right pain!

This also applies to any other components - for instance a slideshow that uses images from a directory - it only needs the relative path entered: images/slideshow/

It does make things pretty consistent and you never have a problem finding stuff at least. Pity the rest of the beast is such a Dinosaur!

[Joss]

Okay, sort of worked this out.

Just had a look at the tinyMCE iframe inside one of my Joomla sites and in the head section of the TinyMCE content inside the iFrame is has:

<base href="http://www.dancingbear.co.uk/">

Now, that is missing in the PW TinyMCE iframe.

I assume it is getting it because in the JS for the TinyMCE in the head of the whole page my domain is set up as the base_url parameter.

If I go to the php script that is initiallising the editor, it has this:

document_base_url : \"". JURI::root() ."\"

JURI::root() being the defined root of the installation.

So, that is being set up explicitly for TinyMCE (and whatever else needs that value)

What I don't know, is how the constant is being defined - or rather, how it is working out what the root is. It might be something to do with this:

http://api.joomla.org/__filesource/fsource_Joomla-Platform_Environment_librariesjoomlaenvironmenturi.php.html#a273

Anyway, so possibly with PW, it is a case of creating a constant for the root of the installation that can be used anywhere that is required. Modules, Editors, Templates - whatever.

Then everything can be treated as if it is in the root directory and have relative paths or direct paths without suddenly leaping out of the installation, however htaccess or other things are set.

[ryan]

That's good to know how Joomla is doing it. Thanks for looking into it. Having to rely on a <base> tag is something I'd want to avoid for ProcessWire (on the front-end), but I'm fine if that's how TinyMCE does it in its own iframe. So I will definitely look into document_base_url setting to see what we can learn from it. No doubt we'll still have to do some kind of replacement tactic. But if we can reduce the number of places we need to do it, that's a good thing.