content structure menu in admin interface empty

«

Previous topic

|

|

Next topic

»

Author	Message
Greg McAvoy-Jensen	Thursday 26 June 2008 11:06:13 pm We're using 3.10.0 (recent upgrade from 3.9.4) and on my development installation I can see my admin left content structure menu just fine. But on the same server I have a staging installation, and the menu has no nodes. Same is true on the production (remote) server. PHP is not running as CGI. Apache sites-available entries are identical except for paths and server names/aliases. I've got dynamic set to disabled on both. The two installations use separate databases, but the root node is, of course, 2 on both. contentmenustructure.ini's are identical. Cleared caches --clear-all and --purge for both. No error or warnings get noted. URL alias-related problem? Where do I look next? Many thanks! Granite Horizon, Certified Developer of eZ Publish Web Solutions Provider of the SaaS Solution Granite Horizon In The Cloud \| http://granitehorizon.com/cloud http://granitehorizon.com \| +1 916 647 6350 \| California USA \| @granitegreg Blog: http://granitehorizon.com/blog
Piotrek Karaś	Friday 27 June 2008 2:11:34 am What about .htaccess file entries? -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Greg McAvoy-Jensen	Friday 27 June 2008 7:15:23 am Thank you. Yes, I had forgotten to mention that neither have .htaccess (not necessary if you have access to the /settings/sites-available files, I thought). I had tried: RewriteRule content/treemenu/?$ /index_treemenu.php [L] in the apache2 sites-available entry on the testing server to with no effect (either dynamic disabled or enabled, clearing caches with --clear-all --purge each time). I had also tried adding the .htaccess_root to the testing installation, both with and without dynamic enabled, clearing caches fully both ways--again, it didn't help. Other thoughts? Granite Horizon, Certified Developer of eZ Publish Web Solutions Provider of the SaaS Solution Granite Horizon In The Cloud \| http://granitehorizon.com/cloud http://granitehorizon.com \| +1 916 647 6350 \| California USA \| @granitegreg Blog: http://granitehorizon.com/blog
Greg McAvoy-Jensen	Friday 27 June 2008 7:16:15 am I should have said, "I tried copying .htaccess_root to .htaccess". Granite Horizon, Certified Developer of eZ Publish Web Solutions Provider of the SaaS Solution Granite Horizon In The Cloud \| http://granitehorizon.com/cloud http://granitehorizon.com \| +1 916 647 6350 \| California USA \| @granitegreg Blog: http://granitehorizon.com/blog
Greg McAvoy-Jensen	Friday 27 June 2008 3:13:03 pm It appears the solution was in fact to republish the root node. I had done that, and cleared the cache with: $ bin/php/ezcache.php --clear-all --purge That didn't work, though. But clearing the cache from the admin interface after republishing the root node did fix it. My guess is it's a permission problem, and that I needed to run ezcache.php as root. No errors were reported by ezcache.php, however. Granite Horizon, Certified Developer of eZ Publish Web Solutions Provider of the SaaS Solution Granite Horizon In The Cloud \| http://granitehorizon.com/cloud http://granitehorizon.com \| +1 916 647 6350 \| California USA \| @granitegreg Blog: http://granitehorizon.com/blog
Piotrek Karaś	Saturday 28 June 2008 1:04:48 pm <i>Thank you. Yes, I had forgotten to mention that neither have .htaccess (not necessary if you have access to the /settings/sites-available files, I thought).</i> That's true, but then you can still forget about .htaccess files messing things up, for example. Still, that was my only thought. <i>But clearing the cache from the admin interface after republishing the root node did fix it.</i> Interesting. It's good to know that this could be a potential solution to similar problems.... weird though... Please share if you discover more. Cheers, Piotrek -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu

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 31 2025 01:16:35
Script start
Timing:	Jan 31 2025 01:16:35
Module start 'layout'
Timing:	Jan 31 2025 01:16:35
Module start 'content'
Timing:	Jan 31 2025 01:16:35
Module end 'content'
Timing:	Jan 31 2025 01:16:35
Script end

Main resources:

Total runtime	0.0212 sec
Peak memory usage	4,096.0000 KB
Database Queries	3

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0040	588.2656	151.2266
Module start 'layout'	0.0040	0.0032	739.4922	220.7344
Module start 'content'	0.0072	0.0126	960.2266	1,005.9609
Module end 'content'	0.0199	0.0013	1,966.1875	41.9922
Script end	0.0211		2,008.1797

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0022	10.4002	14	0.0002
Check MTime	0.0010	4.7287	14	0.0001
Mysql Total
Database connection	0.0007	3.1314	1	0.0007
Mysqli_queries	0.0021	10.1209	3	0.0007
Looping result	0.0000	0.0372	1	0.0000
Template Total	0.0010	4.7	1	0.0010
Template load	0.0008	3.6518	1	0.0008
Template processing	0.0002	1.0160	1	0.0002
Override
Cache load	0.0004	2.0782	1	0.0004
General
dbfile	0.0002	1.0487	8	0.0000
String conversion	0.0000	0.0225	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded	Edit	Override
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 1 Number of unique templates used: 1

Time used to render debug report: 0.0001 secs