Posts

Hi Nigel,

I deleted a very big access file (more than 10000 posts) and added by typing the 6 standard. Because the IE could not show the page right after the upgrade. And I have also tried alot to fix that calendar.php problem I had. I had to clear log files every day with more than a 1000 posts cause of that issue. Also when I went from admin page to main page – It allways went to a homepage where the html block with stats could not been showed. If I clicked at the menu for homepage it was correct.

So with all these issues I dl my gedcom. Made a completely new installation. Imported my gedcom. Updated all my pages, menues, articles, setup ect. by handtyping. The only tabel I imported was the visitor table. And not from the old installation, cause it was somehow compressed. Only 32 posts. Instead of 1500 or something. I had an old backup before I upgraded to 3.0. (the visitor list even with the small tabel showed the right visitornumbers – so I have no idea where “the most viewed block” got the numbers from – def. not from the visitor tabel)

Well,
This hard work with hand typing was a success. I do not have a spam in my logfiles with calendar.php errors. I do not have the issue from the return from admin page. I do not having problems with IE. Everything works now as it should.

MARK this:
I tested the IE issue. It will not accept the manuel update in the access page. But instead I could from a new installation export the table. Delete it in the main installation and import the new tabel from new installation. That part solved the IE issue.

Some way my version 3.0 upgrade went wrong. You tried your self back then without luck to fix many of the problems. But the above mentioned without luck for both of us.

So in this matter I just want to tell you. The calendar.php issue was not in the gedcom file. But in the installation. Either in the database or in the systemfiles. My guess is the database, since I uploaded the files several times to make sure.

FYI I still have the database file and all the system files if you need them for test. If you do not want them I will delete it all.

Thank you for all your help in this matter from a happy Jamie who learned that hard work feeds the day 😛

Regards, Jamie Jaconelli

admin and owner of a user customized version of kiwitrees (contain 3 family trees)

Jamie

Thanks for that update. I’m very pleased you have finally got everything working better.

Sometimes, when we have had a site running for many years I also find that it can be easier to take it all down and start again. In English we call it “spring cleaning”, so everything is tidy before summer starts.

FYI I still have the database file and all the system files if you need them for test. If you do not want them I will delete it all.

It would be nice to study that and see if the fault could be found. But really I am unlikely to find the time, so best that you delete it all. It seems certain that the issue was unique to your situation, not something all users need to be concerned about.

Nigel
My personal kiwitrees site is www.our-families.info

Okay I delete it!

True I do think most of these errors were unique for my page.
In case other reads this I can inform that my page were upgraded back from webtrees were beta in 2010. So I do think it was the time to “reset” and prolly the reason for my issues were this 5 years old database.

But try to test the issue with the access tabel! It will not accept you handtyping the (standard) rules (Restrict access to the site, using IP addresses and user-agent strings) in case the tabel was cleared or modified! This part is not unique for my page but for all of us. I tried at my historic database too and same result. (this one started with kt2.0)

Regards, Jamie Jaconelli

admin and owner of a user customized version of kiwitrees (contain 3 family trees)

jacoline wrote:

But try to test the issue with the access tabel! It will not accept you hand typing the (standard) rules (Restrict access to the site, using IP addresses and user-agent strings) in case the tabel was cleared or modified! This part is not unique for my page but for all of us. I tried at my historic database too and same result. (this one started with kt2.0)

If I understand you correctly that all works fine for me on any browser (not that it would be browser-affected anyway).

So I’ve probably misunderstood the problem. Can you explain more carefully, referencing each page by its actual (English) page title, preferably with pictures please.

Nigel
My personal kiwitrees site is www.our-families.info

This one: Restrict access to the site, using IP addresses and user-agent strings

In case they were deleted (not all – then no access for anybody) or edited

Regards, Jamie Jaconelli

admin and owner of a user customized version of kiwitrees (contain 3 family trees)

Ah, now I see.

I’ll have a look tomorrow.

Nigel
My personal kiwitrees site is www.our-families.info

No rush – just need to know there can be a problem (and it only happend because my table were BIIIIIG and I “cleaned up” and by mistake deleted the one for IE.

Regards, Jamie Jaconelli

admin and owner of a user customized version of kiwitrees (contain 3 family trees)

OK, I’ve had a look. I believe the “site access rules” code is all working exactly as it was designed. However, that does not mean there are no improvements that could be useful.

First, I will explain how it was designed to be used.
————————————————————————-
The page has two parts:
1 – The bottom half
This is a list of all unknown visitors, based on their IP address range and user agent string. ‘Uknown” means they are not included in any of the definitions in the top half.

Apart from producing the list, no action is taken using the bottom half.

To the right of each “unknown” are three ticks under “allow”, “deny”, and “robot”. If you click on any of those ticks, the details of that visitor are copied to the definitions in the top half of the page, using the rule set by the tick you selected.

2 – The top half.
This is the important part. It defines whether specified visitors (by IP address range and user agent string) are allowed access; denied access; or restricted (seen as robots, search engines etc) to only certain pages.

When you first install kiwitrees this section contains six entries. Each has all possible IP addresses (0.0.0.0 to 255.255.255.255) and the user agent strings of all the known legitimate browsers. This ensures everyone [including you] can visit your site using any browser.

When you add new rules (as described for the bottom half) you allow, deny, or confirm as robot other IP addresses / user agent strings.

Any item included in the top half can be edited. This is done by clicking on each of the fields and editing it’s content. (Don’t forget to save).

—————————————————————————————–

So, this is how it was designed, and (for me anyway) all of that is working correctly.

But there are some issues, and I guess one or more of these was where you had a problem:

1. Both the top and bottom sets of data are in the same database table [“_site_access_rules”]. The bottom half all have the rule = unknown; the top half all have the rule = allow, deny, or robot. If you [accidentally or otherwise] delete the entire table or even just the “allow” rule items, then no-one will be able to access your site – not even you!. The only way to fix that is to recreate a new “_site_access_rules” table and insert the default 6 ‘allow’ items manually there. It is not possible to add them in the admin page.
2. The bottom section of “unknown” visitors can become very long, and potentially cause server capacity issues. There is no way, other than directly at the database to delete those items.
3. The three “ticks” right of the items in the bottom half are not a user-friendly way to select and copy items to the top half.

Jamie, can you comment on these issues and confirm if these are the cause of your problem; and what solution you think would work better.

Nigel
My personal kiwitrees site is www.our-families.info

I have no idea – it came with the upgrade. Then I tried to “empty” the table by mysql (since I had more than 10000 posts there) and the one with the arrow did not look excactly like the one showed in the image. I deleted it (by mysql) and retyped it (by mysql) – but it did not work. Then I cleared the table completely and imported a totally new one.

My suggestion could be that we can by kiwitrees clear/reset it for standard. Think about I had rules that were 5 years old (in the bottom) I doubt that all were usefull anymore. And by a clear/reset for standard we will get the latest rules (in the top) Could this be done?

Regards, Jamie Jaconelli

admin and owner of a user customized version of kiwitrees (contain 3 family trees)

I thought about that. But if you clear the table from the database, then you will not be able to access your site, so there will be no way to access the page to do a reset.

I think you have still not understood how the ‘rules’ work.

When you say “Think about I had rules that were 5 years old (in the bottom) I doubt that all were useful any more. I think you did not read my last post. I said, I thought clearly. There are NO rules in the bottom half. I said: “Apart from producing the list, no action is taken using the bottom half.”

To explain further…. In the bottom half there is only a list of the IP details etc for visitors who do not match the ‘rules’ set in the top half. They ALL did and can continue to access your site. They only become “rules” (allow / deny / robot) when you click their ‘tick’ and transfer them to the top half.

I realise it is too late now, but the correct thing to do when you had your problem was:
First – only delete items from the MtSQL table that have a rule = “unknown”. Then the real rules will be untouched.
Second – importing a clean copy of the table (from you backup of course) is the best way of you missed the first .

However, for the next release I have made a couple of changes which should help:
1 – The ‘ticks’ are now bright green colour, so easier to notice
2 – Those ticks now have a proper “pointer” cursor when you point to them so it is more clear that they are ‘clickable’
3 – I have added an option to ‘purge’ (delete) all the entries from the bottom half. this will get rid of all the old entries no longer needed, but leave the rules in the top half untouched.

If I have time I will also add a link to the explanation I wrote in my last post as an FAQ.

Nigel
My personal kiwitrees site is www.our-families.info