I've never done a static page because there is really very little reason to, but I'll test it out and see what there is to see.

By looking at my back office under "Blog settings->blog->advanced" it seems to be telling me I need a stub file AND a source file to generate static pages. [url=http://manual.b2evolution.net/Install_b2evolution]Per the manual[/url] I know I will also need to chmod my blog's root directory to 777 to generate static pages, but that means doing that to my actual root directory. For some reason I'm not comfortable with that...

Anyway I'll give it a test on a secret hidden installation I have and let you know what happens.

I think it's a bug. Will report back when I learn more.

You need to create a new file first, give it 666 permissions and then generate a static page.

This is how it works

Source - summary.php
Destination - new.html
Save
Generate now

No errors, because I previously created new.html with 666 perms.

Nope. It's a bug. There is no reason for it to warn you that you are leaving a page without saving the changes when clicking "generate static page" IS saving the changes, and it simply doesn't create or over-write an existing file.

It is also the second most unimportant bug ever found because, really, static pages are just plain silly. Until you get slash-dotted and your server is crashing under the load ;)

I'll move this to the bugs forum for future reference.

Static pages are - very occasionally - useful, to me at least. There are a few things that just can't be integrated into a dynamic blog page (some custom Google maps if you want them to display consistently in all browsers is the one I'm wrestling with right now) or are not worth the trouble of rewriting the whole skin just for one unchanging page. A custom solution is sometimes necessary, and a static page to start work on saves a lot of hand-coding. Believe me, I know. :)

Interesting application for a static page that I never thought of. I've done googlemaps in blogs and yeah it's kinda tricky. Good idea.

Yeah, I've done it, hooray! Thanks for advice from this forum which did the trick.

You're not wrong about google maps. Usually fine in non-IE browsers, but for compatibility it all seems to come down to the exact order that IE loads stuff - impossible to control in a dynamic page. The static page was indeed the way to get there. I'd say that getting a IE6-compatible custom google map to display within a b2evo post would be more-or-less impossible with the present architecture, although I'd be delighted to be proven wrong.

gory details of the process available if anyone is interested.

What was your problem with IE6 ? ...... *gets popcorn* .... and this had better be a damn good story after all the hype :|

¥

It seemed like a big deal to me, but of course you guys chew up such problems with your cornflakes, I know (or possibly your popcorn).

But as you asked. I noticed that over 50% of my visitors were still using IE6, the benighted souls. So when I started playing with google maps I was anxious that anything I actually used live would work in that dismal old crock as well as modern browsers. I managed a few static pages in my old 1.8 installation which I did basically by hand. They kind of worked but not very well, and not at all in IE6. I used [url=http://www.quirksmode.org/css/condcom.html]conditional comments[/url] to exhort my visitors to upgrade, which gave me a smug feeling but didn't really help the visitor experience.

I also found that basic google maps where you just copy the link from a plain Google maps page, for example to show a single location, are pretty forgiving. However once you start writing your own javascripts to customise the maps, for example to add custom markers or (like me) upload about 150 markers, things are different. This can slow things down, and as this is where IE starts to get fussy about what it will and will not display. Typical problems include elements of the Google map breaking out of their div such as the logo, zoom bar and other buttons being spread all over the page, and/or the main map image not showing, or the custom script not running. IE6 is particularly vulnerable to this, but IE7 is not immune either. FF always plays nicely.

When 2.3 came along I started a new non-production blog to work it all out before I went live. I created static pages (with a lot of advice from those on this forum, ta) and tried all sorts of stuff, testing in FF, IE7 and IE6 (using [url=http://blogs.msdn.com/ie/archive/2006/11/30/ie6-and-ie7-running-on-a-single-machine.aspx]a virtual machine running IE6[/url], very handy indeed and worth the effort if you're serious about compatibility).

I explored the IE/google maps issue and found that loads of folk had had the same problem, and had found a load of different solutions, or none. Google it and you'll find them. I'd caution that none of their solutions seemed to be definitive and nor is mine. YMMV.

I came to the conclusion that there was no way I could get the javascript to load exactly where and when I wanted it on the page whilst using b2evo dynamic pages. Someone else probably could, but not me. I was also anxious to avoid a solution where every b2evo generated page had to load a google maps script, or make some test to see if such a script was needed, because to make a single page on the whole blog display this was an excessive overhead. I made a static page and had it display outside the blog but with the same layout. First I made the page [url=http://validator.w3.org/check?uri=http%3A%2F%2Fmattandcat.co.uk%2Freviews%2Fstatic%2Fmap.html&charset=%28detect+automatically%29&doctype=Inline&group=0]W3C compliant[/url]. Then I started testing the map until I had one that worked in all 3 browsers I was targeting.

So to cut a very long story short this was my final answer. [url=http://mattandcat.co.uk/reviews/static/map.html]You can see it online here[/url]. Certainly the formatting is not great but the key thing is that the map and the custom script displays in FF, IE6 and IE7.

There are two key things to note: first, in my experience the javascript has to be inline. No way can it be a separate file. Presumably this makes the parsing process quicker, but even though I prefer such big scripts to be safely hidden away in a *.js file in this case the script has to be in with the html. You can still see my old external script commented out at the bottom of the file.
Second, the solution I used involved enclosing the entire script in a function (in my case it was load_map() ). This allows the script to be called from the page exactly when it is needed and not before. There were several suggested solutions I googled along these lines and this was the one that worked for me. I tried a few and some did not work, so for anyone wrestling with this problem I'd suggest they try a few different ways to get this function trick to work - I found one in the end.

filthio wrote:

So to cut a very long story short

Any chance of the full version? :|

¥

*edit*
[offtopic]you might like to check [url=http://naturenet.net/blogs/index.php/eating]the skin[/url] with js disabled in FF2.whatever.summat, a similar thing happens on your testbed but there's also a horiz overflow ( with or without js )[/offtopic]

[ontopic]*gets more popcorn*[/ontopic]

Don't get all that popcorn on the floor now, I need to hoover under there.

That version on naturenet.net is going - that's the old server, running b2evo 1.8 and still live right now. Any day now I'm going to mod_rewrite that one out of existence in favour of the new one. So I'm not bothering to fix it - try running it through W3C validator to see a few more reasons why not! But thanks for the point about non-js testing - that's possibly next on my list for the new site.

Re the google maps there's no more story to tell, as such, as all I left out was the joys of iterative testing, and swearing. To me, that's not really news. But if you want to ask questions, feel free.

"¥åßßå" wrote:

filthio wrote:

[url=http://naturenet.net/blogs/index.php/eating]the skin[/url]

whose blog is [url=http://naturenet.net/blogs/index.php/eating]this[/url] ?

i d like to know how they have handled the

background-attachment:fixed

problem in ie ;) .cheers

Guilty: it's mine. Feel free to send me PM or email via that blog. Do you mean there still is a problem (coz I thought I'd fixed that)?

I have been reading your thread as I have the same problem with static pages, but I would like to remove the "Create Static Page" link not to show up anywhere since it is pretty much useless. How can I do this without adverse effects?

Why would you need to do that? ordinary users will never see that link. Anyone who can see that link is in your admin area anyway. If you can't trust people in there you've got a lot worse a problem than static pages being created.

oops sorry for the double post

cyberghetto wrote:

filthio wrote:

Why would you need to do that? ordinary users will never see that link. Anyone who can see that link is in your admin area anyway. If you can't trust people in there you've got a lot worse a problem than static pages being created.

Please excuse my ignorance as I am new to b2evolution... I use wordpress for my own personal blog (but it does not lend itself easily to multi blogs) so I am not totally stupid.

I am not speaking of an ordinary user on a blog...

I am generating a blog for every new user automatically when they register, through a plugin called "userblog". They are the owner of the blog not just a user. There admin access is restricted in group settings (system admin) and only have view permissions on senstive tabs (and this is only because when set on no access there is a error message displayed - when set to view only there is no error message) this has to do with the plugin not b2evolution, the solution was to change permissions to view only...

Since this particular problem has nothing to do with the plugin but a core issue in b2evoution I thought I could work around it.. I just don't want to have to explain to every user (blog owner) on my website that the "create static page" link is useless to them nor do I want the hassle of creating a source file and chomoding for every blog. I would rather hide the link or change the message from "You haven't defined a source file for this blog!"
to say "you do not have permissions to define a source file for this blog! "

Is this not a simple thing to do?

Again I appoligize if I am way off base here - just changing the message will be enough. To the novice such a message may indicate that things are not working right and that is not the case here.

I see what you are doing - that makes sense. What version are you using, and is there a link we can look at?

filthio wrote:

I see what you are doing - that makes sense. What version are you using, and is there a link we can look at?

http://cyberghetto.org/www/

http://cyberghetto.org/www/index.php?blog=8

http://cyberghetto.org/www/admin.php

blog name = test
login = test
password = testing

I checked the current source (B2evoHEAD) and the permission for generating static links is at the Blog owner and at the admin without any way to change that.
I will make a note in the 2.4 bug section, so it gets reviewed.

For your situation there's an easy hack.
Crack open /inc/users/model/_user.class.php and change lines 593-604 so it looks like:

			case 'blog_properties':
			case 'blog_cats':

				// Blog permission to edit its properties...
				if( $this->check_perm_blogowner( $perm_target_ID ) )
				{	// Owner can do *almost* anything:
					$perm = true;
					break;
				}
				/* continue */
			case 'blog_genstatic':				
			case 'blog_admin': // This is what the owner does not have access to!

The change is moving the line

			case 'blog_genstatic':	

a few lines down.

(not checked)
Good luck