Dynamic Image Paths and TinyMCE
Permalink
I recently moved my concrete5's installation to another directory, updated config/site.php and almost everything works.
I noticed broken images across my site which were inserted into Content blocks with TinyMCE and the File Manager. It was my understanding that the image paths would be linked based on ID, and it does at first.
Edit Page -> Insert Content Block -> add image -> Update -> Publish
This is what show up in the database:
<img src="{CCM:FID_12}" alt="father.gif" width="188" height="235" />
Re-Edit the same Content Block -> Don't change anything -> Update -> Publish
The previous ID based path is replaced in the database with the following:
<img src="/library/files/9312/4293/5814/father.gif" alt="father.gif" width="188" height="235" />
I searched around the forums and couldn't find anything relevant. Is there a setting in TinyMCE that I'm missing? Or something else perhaps?
I'm running 5.3.1.1
Thanks in advance
-Dave
I noticed broken images across my site which were inserted into Content blocks with TinyMCE and the File Manager. It was my understanding that the image paths would be linked based on ID, and it does at first.
Edit Page -> Insert Content Block -> add image -> Update -> Publish
This is what show up in the database:
<img src="{CCM:FID_12}" alt="father.gif" width="188" height="235" />
Re-Edit the same Content Block -> Don't change anything -> Update -> Publish
The previous ID based path is replaced in the database with the following:
<img src="/library/files/9312/4293/5814/father.gif" alt="father.gif" width="188" height="235" />
I searched around the forums and couldn't find anything relevant. Is there a setting in TinyMCE that I'm missing? Or something else perhaps?
I'm running 5.3.1.1
Thanks in advance
-Dave
Thanks Scott,
My cache is disabled and dumped and I'm still producing the problem. My dir_rel is nested one step below root "/library"
-Dave
My cache is disabled and dumped and I'm still producing the problem. My dir_rel is nested one step below root "/library"
-Dave
Try a totally new file, if you can link to that fine and the CCM:FID is written to the db fine and reparsed back into a file system path then go ahead and go to the dashboard and go to asset manager, click show 500(or whatever is applicable) select all, then the dropdown above has "rescan". Hit that and it'll rescan the files, maybe fixing the paths where it think it lies etc.
Please post back.
Please post back.
Scott,
I added a new file, then rescanned all of them. I then went to edit the Content block and it did the same thing.
-Dave
I added a new file, then rescanned all of them. I then went to edit the Content block and it did the same thing.
-Dave
See if you can replicate this with a fresh install on the server or with a 14 day demo, then we know it has to be in the config.php and the dir_rel and dir_base otherwise it could be some wonky server issue. There is no ambiguity in code, it either works or it doesn't :(
I have moved a bunch of sites from local to active on getconcrete5 and my own personal vps so I know this stuff works, and we have taken some sites from hosted (ie the ip address + /~whatever to the actual domain with no issues, so it almost has to be a fringe weird case and I truly hope you can narrow down where the issue is.
I have moved a bunch of sites from local to active on getconcrete5 and my own personal vps so I know this stuff works, and we have taken some sites from hosted (ie the ip address + /~whatever to the actual domain with no issues, so it almost has to be a fringe weird case and I truly hope you can narrow down where the issue is.
Scott,
I installed a fresh copy of 5.3.1.1 and the preg_replace is still failing. Here's what's in the database:
First Update:
<h1><img src="{CCM:FID_6}" alt="MilesAndMaggie.jpg" width="391" height="604" /><br /></h1>
Second Update:
<h1><img src="/concrete5/files/2412/4394/9326/MilesAndMaggie.jpg" alt="MilesAndMaggie.jpg" width="391" height="604" /><br /></h1>
I'm running:
PHP Version 5.2.9
MySQL 5.0.45
httpd-2.2.11
Linux version 2.6.18-128.el5PAE (mockbuild@hs20-bc1-5.build.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Wed Dec 17 12:02:33 EST 2008
-Dave
I installed a fresh copy of 5.3.1.1 and the preg_replace is still failing. Here's what's in the database:
First Update:
<h1><img src="{CCM:FID_6}" alt="MilesAndMaggie.jpg" width="391" height="604" /><br /></h1>
Second Update:
<h1><img src="/concrete5/files/2412/4394/9326/MilesAndMaggie.jpg" alt="MilesAndMaggie.jpg" width="391" height="604" /><br /></h1>
I'm running:
PHP Version 5.2.9
MySQL 5.0.45
httpd-2.2.11
Linux version 2.6.18-128.el5PAE (mockbuild@hs20-bc1-5.build.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Wed Dec 17 12:02:33 EST 2008
-Dave
Scott,
I also tried a fresh install of 5.3.1.1 on a different server with the same results.
-Dave
I also tried a fresh install of 5.3.1.1 on a different server with the same results.
-Dave
posting to bugs.
How can I find out when this bug will be fixed?
coming weeks.
If you'd like, you can download concrete5 from subversion and manually copy over the content/ block (although I'm not positive that this won't create additional problems) but I believe the issue has been addressed and the official full release will be available soon.
Where can you download a subversion?
I looked in help, but no luck or I missed it.
I like to download it and see if I need to adjust my custom blocks for the next release.
I looked in help, but no luck or I missed it.
I like to download it and see if I need to adjust my custom blocks for the next release.
I would really like to help there, but not right now. I'm not even sure if I will use concrete after this week (end of project), but if I do and stay active I will join in, because beta's are really helpful
The replace is actually being handled in the content block controller.. and I have found it to work reliably.
The issue could be that your dir_base and dir_rel aren't 100% perfect and the match isn't happening based on the config values and it is simply not triggering the preg_match and inserting verbatim.