Thread

I created an XML sitemap. The file is set to filetype XML in the prefs for this file. When I try to view it in a browser, I get this error:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 36887 bytes) in /www/eh14227/broadway/expressionengine/libraries/Template.php on line 231

To test it in the most simple way, I took all EE tags out of the template in case I had something wrong, leaving just a bit of static code there:

<?xml version="1.0" encoding="UTF-8"?>

<urlset >

<url>
<loc>http://www.mysite.com/</loc>
<changefreq>yearly</changefreq>
0.6</priority>
</url>

</urlset>

As you can see there is nothing here that should exceed any memory limits. When I take this same template and put it in my public folder to see as a static page, it works fine. What can possibly be wrong here?

Did you set the type of page to XML? I took your code, removed the space between urlset and the closing > character.. it displays OK on my EH site.

That’s funny what I had pasted into the opening urlset tag was actually:

<urlset xmlns="http://www.google.com/schemas/sitemap/0.84">

I had to put the greater than/less than chars into HTML entities to get the whole tag to show here.

Yes, this XML template was set to file type XML in the template prefs.

Now my entire site won’t load at all. Not the control panel, not the front end. Nothing. Sigh. One of those days.

OK, now I can see my site again and get into my CP. No idea what was wrong there, it freaked out after I tried to see that sitemap XML file in the browser.

I double checked that this template is set to XML type. It has a different symbol next to it than the HTML template does, like an RSS symbol.

This is mighty strange. I am desperate to get this problem fixed, if anyone has any insight?

More to report: I switched the template type to “web page” and it renders this:
http://www.mysite.com/ yearly 0.6

So, I went to view my “real” sitemap, the one that has EE tags, and I think the whole problem is that I put “.xml” at the end of the URL. I should not have done that I guess. Is that the cause of all this madness?

good url:
http://weinraub.ehclients.com/home/sitemap

with .xml at the end havoc ensues.

You shouldn’t need to have .xlm in the url. Have you seen the third party add-on on Devot-ee.com for sitemaps?

Hi Sue!
Right, I understand that I don’t need “.xml” at the end of my url, but would you expect that putting it in would have caused such havoc?

I will check out the plugin, but I’ve actually got my process of writing the XML down pretty well.

Thanks, Rory

Are you using mod_rewrite in any way? In your original example you were simply running out of memory, it seems.

hmmm. not sure what mod rewrite even is. is that an .htaccss thing? this is what i have in htaccess:

# Remove index.php from URLs using include method

RewriteEngine on 
RewriteCond $1 ^(weblog|member|search|Forum_Name|temp|home|about|lawyers|practice_areas|cases_of_interest|contact|page_not_found|P[0-9]{2,8}) [NC] 
RewriteRule ^(.*)$ /index.php/$1 [L]

Does that shed any light?

As Ingmar said, it seems like you’re running out of memory. EngineHosting allows for 64M of memory allocated for PHP.

What EE code are you using to create this site map? Could there be too many entries?

Hi Sue & Ingmar,
The code that was causing the memory error was simply the single entry, purely static (no EE tags) sample I put into my first post in this thread (well, EE ate a little of the code, like the urlset tag, but you get the idea), but viewed with an unnecessary “.xml” at the end of the URL. When I viewed it without “.xml” at the end, things were fine, then I proceeded to put in my EE tags to make the real sitemap.

I am pretty sure at this point that the error was just having put “.xml” at the end of the URL when viewing it. My question at this point is just academic: I wonder why this extra “.xml” in the URL causes and EE template to do this memory error, followed by some time afterwards where the system was unavailable? Seems like an extreme reaction? Or was something else going on here that I am not accounting for? Could the extra “.xml” alone have caused all this craziness?

I am pretty sure at this point that the error was just having put “.xml” at the end of the URL when viewing it.

I’m unable to reproduce it, but I won’t rule out. It might have been a rewriting issue, perhaps, or some other server side issue. If it’s working as intended now I wouldn’t worry too much about it.