moving up the directory tree

Author Message

David Barber

Tuesday 08 August 2006 2:00:04 pm

Hi all,

We have a setup here where I built some websites on the dev server, using the address

http://dev.example.com/newsite1/

but going into production, the site will be

http://newsite1.example.com/

I've worked out that if I don't change the Site URL in design -> Look and Feel, as well as in site.ini, I'll lose the CSS and the whole thing fails to render. But even with the changes in site.ini

[SiteSettings]
SiteURL=http://newsite1.example.com/

and the changes in look and feel, I still seem to get the trailing /newsite1/ on all the links. I've cleared the cache repeatedly, using both the shell script and the GUI. Can anyone suggest somewhere else I should be looking?

Thanks,
David

Kristof Coomans

Tuesday 08 August 2006 10:25:48 pm

Hello David

The SiteURL setting is (only) used to insert full URL's in e-mail templates. You will need to modify these settings to base the site access selection on the host name:
http://ez.no/doc/ez_publish/technical_manual/3_8/reference/configuration_files/site_ini/siteaccesssettings/matchorder
http://ez.no/doc/ez_publish/technical_manual/3_8/reference/configuration_files/site_ini/siteaccesssettings/hostmatchtype

Good luck!

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

David Barber

Wednesday 09 August 2006 1:27:01 pm

Hi, and thanks for your reply.

I'm not actually having a problem with the siteaccess. Rather, the site is by default linking to a directory tree which no longer exists. For example, if I go to my site and I click on the 'mission' tab, rather than pointing me to

http://www.example.org/index.php/mysite/mission

the link is pointing at

http://www.example.org/38www.example.org/index.php/orpheus/mission

because originally I had been developing the site on my development server as

http://dev.example.org/38www.example.org/

(and the 38 was, of course, because it was now running ez3.8). So whereas before the root of the ezpublish install was -not- the root directory of my website, now it is. But the links have not updated to reflect that new reality - they still think all my content is one directory down, as it was on the dev server. Naturally, on my production server this directory does not exist, and so I get a 404.

Is this clearer? The siteaccess is being chosen correctly, but the ezpublish install is generating wrong links for all subcontent, based on the old directory tree.

Kristof Coomans

Wednesday 09 August 2006 10:19:23 pm

Then you probably only need to clear some caches. Clear them all to be sure.

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

David Barber

Thursday 10 August 2006 6:35:44 am

Hi all,

Having verified, now repeatedly, that clearing the cache is not the solution, does anyone have any ideas for other places where directory tree information might be stored? Alternately, is this a bug with the product, and one of the caches is being cleared neither by script nor by the friendly 'clear cache' button? Any thoughts?

Thanks,
David

Martin Ulrich

Thursday 10 August 2006 6:56:00 am

some references:

what kind of directory is it? ez-Menu?

did you check all files carefully ?

settings\override\site.ini
settings\siteacces\my_access\site.ini
settings\siteacces\my_access_admin\site.ini

does the installation on former server run in virtualhostmode?

are you able got to admins site? is the correct database connected?

_______________________

http://artenic.de ARTENIC - Publishing mit allen Mitteln!

David Barber

Thursday 10 August 2006 7:06:29 am

Hello,

OK - found the answer. Thanks to Kristof's comments about the cache, I decided to see if it was a problem with the cache clearing processes. I first ran the script, with a --clear-all, then I ran it from the admin interface, again, clear all. None of this worked.

I then went to var/mysite/cache and did a rm -rf *. This solved the problem.

I would consider this a bug. Does anyone have an explanation for why neither the script nor the admin interface would clear the cache adequately?

Thanks,
David

Kristof Coomans

Thursday 10 August 2006 9:14:22 am

Does the user your webserver is running as has write permissions on the cache dir?

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

David Barber

Thursday 10 August 2006 1:15:33 pm

Hi,

Yes, the user I log in as is the user that runs everything on the box, more or less. So when I cleared the cache, it should have had the same permissions as when I went in on the command line. Additionally, of course, the clearcache.sh was run as that user as well.

Thanks,
David

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.

eZ debug

Timing: Jan 18 2025 10:16:21
Script start
Timing: Jan 18 2025 10:16:21
Module start 'layout'
Timing: Jan 18 2025 10:16:21
Module start 'content'
Timing: Jan 18 2025 10:16:22
Module end 'content'
Timing: Jan 18 2025 10:16:22
Script end

Main resources:

Total runtime0.7904 sec
Peak memory usage4,096.0000 KB
Database Queries77

Timing points:

CheckpointStart (sec)Duration (sec)Memory at start (KB)Memory used (KB)
Script start 0.00000.0058 588.0313152.6406
Module start 'layout' 0.00580.0033 740.671939.4766
Module start 'content' 0.00910.7787 780.1484651.9063
Module end 'content' 0.78780.0026 1,432.054720.1484
Script end 0.7904  1,452.2031 

Time accumulators:

 Accumulator Duration (sec) Duration (%) Count Average (sec)
Ini load
Load cache0.00390.4980160.0002
Check MTime0.00140.1715160.0001
Mysql Total
Database connection0.00100.129210.0010
Mysqli_queries0.715990.5768770.0093
Looping result0.00070.0846750.0000
Template Total0.756395.720.3782
Template load0.00240.297620.0012
Template processing0.754095.385320.3770
Template load and register function0.00010.014410.0001
states
state_id_array0.00130.169410.0013
state_identifier_array0.00140.176620.0007
Override
Cache load0.00210.2615620.0000
Sytem overhead
Fetch class attribute can translate value0.00070.084530.0002
Fetch class attribute name0.00150.1951100.0002
XML
Image XML parsing0.00080.097730.0003
class_abstraction
Instantiating content class attribute0.00000.0036120.0000
General
dbfile0.00150.1864160.0001
String conversion0.00000.000940.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

UsageRequested templateTemplateTemplate loadedEditOverride
1node/view/full.tplfull/forum_topic.tplextension/sevenx/design/simple/override/templates/full/forum_topic.tplEdit templateOverride template
9content/datatype/view/ezxmltext.tpl<No override>extension/community_design/design/suncana/templates/content/datatype/view/ezxmltext.tplEdit templateOverride template
21content/datatype/view/ezxmltags/paragraph.tpl<No override>extension/ezwebin/design/ezwebin/templates/content/datatype/view/ezxmltags/paragraph.tplEdit templateOverride template
6content/datatype/view/ezxmltags/literal.tpl<No override>extension/community/design/standard/templates/content/datatype/view/ezxmltags/literal.tplEdit templateOverride template
6content/datatype/view/ezxmltags/line.tpl<No override>design/standard/templates/content/datatype/view/ezxmltags/line.tplEdit templateOverride template
3content/datatype/view/ezimage.tpl<No override>extension/sevenx/design/simple/templates/content/datatype/view/ezimage.tplEdit templateOverride template
1print_pagelayout.tpl<No override>extension/community/design/community/templates/print_pagelayout.tplEdit templateOverride template
 Number of times templates used: 47
 Number of unique templates used: 7

Time used to render debug report: 0.0001 secs