difus wrote: [View Post]

you can do one thing

do another fresh install of phpBBXS and test.it isn't so hard.
[create folder in public like test]

Woah... ok, thanks for help.

Vortex wrote: [View Post]

moreteavicar wrote: [View Post]

Oh dear... here goes...
As we have no idea whether or not you have checked the cached template file /cache/tpl_ca_aphrodite.nav_quick_links.php, which would confirm once and for all if there was a caching problem

I did. You said you wouldn't answer again, so I decided not to answer to you, in order not to continue with such attitude that is totally unuseful, IMHO.

The point is to inform everyone here, not just me, of the things you have or have not tried to do.

Yes, this is a support forum - I am trying to help you see sense in providing as much accurate and useful information in order that everyone else here who doesn't have access to your hosting account can diagnose the problem you are having. We can only work on what information you provide.

For example, from your last 2 posts, I don't actually know whether this worked:


If not, you could even try:



and if that still doesn't work (I really don't understand why not, but lets suppose the block variable name is being set by something somewhere else), then try



and replace <!-- BEGIN mg_switch_user_is_admin -->  with <!-- BEGIN switch_show_admin_links -->  and likewise replace the END statements in the quicklinks template file.

Another question- how have you been editing your files? Have you been editing them online, through browser interface, e.g. something like cpanel? Or have you uploaded and overwritten the files?

Quote:

And you can keep trying to report this post to get attention, but MG is very busy. I would suggest you try my other suggestion of using a new switch statement. It will only take you 2 minutes to do.

Of course I will try, but if I didn't have time in these days there is no reason continuing kiddin' me with such attitude and useless boutades...

I thank you for your suggestion, I will try it as soon as possible, but please stop with this behavior. I really don't understand what's your problem man.

I only try to help to resolve this issue, and ask that you give information relating to the problem, yet you respond the way you have. My point about Explorer Destroyer is that if you are blocking people, then you are most likley blocking a member of staff from this site who might be trying to help, however, that doesn't seem to have occured to you. Now please, stop with this defiant and abusive attitude, we are all volunteers working on this project because we enjoy coding, we're not making money here.

And as I said before, the answers to my questions are also helpful for everyone else. MG is only going to ask something similar, because there is nothing that makes sense about the problem you are having.

Indeed if you can answer this as well:

Quote:

Another question- how have you been editing your files? Have you been editing them online, through browser interface, e.g. something like cpanel? Or have you uploaded and overwritten the files?

Because if you have been using a browser interface, it is possible that during saving, a file has become corrupted in places, particularly with rather large files like page_header.php. At least, this has happaned to me in the past.

Vortex wrote: [View Post]

Hi, I put it in here because I think it could be a bug...

In my opinion it's not a bug...

Vortex wrote: [View Post]

So I found it was a caching problem.


So, caching THAT block in portal (I suppose in forum index it's not cached?) causes a very "funny" thing... If I empty the cache I can see what follows:

- Empty cache, an admin logins and load the portal, even guests can see all links.

- Empty cache, a user (even guest) without admin privileges load the portal, admin doesn't see the links as if he wasn't admin.


In a few words first to come decides...

Yes right... if you are caching the block you are caching the output, not the source... so the switch are OBVIOUSLY missed... otherwise no reason to cache.

Vortex wrote: [View Post]

Ok then... I solved for now disabling caching system, but this obviously causes my portal index to generate more than FIFTY queries... and I cannot effort such amount.

Another solution could be totally remove the links... but I'd like to solve it less brutally...

I totally disagree on this... if you take a look at the code in nav_quick_links.tpl you will immediately notice that there is no SQL in that file... so there is no need to cache it... try to believe, the number of SQL shouldn't increase if you cache or not that block.

All the switches are checked once in the PHP pages (most of them in page_header.php), so all switches in a TPL are parsed really really fast.

My advice is to avoid caching all blocks which do not involve SQL, because it's quite useless... take a look at the home page here... sometimes it's loaded in less than one second... and this site is on Aruba on a shared server...

Vortex wrote: [View Post]

I think this could be a big security problem... ALMighty Gorgon, are you there?  

I don't think security is a problem for this case... can you explain this to me?

Even if some links are visible, it doesn't mean users may access them.

____________
Luca
SEARCH is the quickest way to get support.
Icy Phoenix ColorizeIt - CustomIcy - HON

Mighty Gorgon wrote: [View Post]

In my opinion it's not a bug...

Ok sorry my fault In this case moderators please move this to the right section.

Quote:

Yes right... if you are caching the block you are caching the output, not the source... so the switch are OBVIOUSLY missed... otherwise no reason to cache.

Ok, I understand.

Quote:

I totally disagree on this... if you take a look at the code in nav_quick_links.tpl you will immediately notice that there is no SQL in that file... so there is no need to cache it... try to believe, the number of SQL shouldn't increase if you cache or not that block.

Ok, I believe you but my site really reached more than 50 queries... did I mistake in disabling caching? I did that setting "no" to Configuration ---> DB ---> Caching of the board's Configuration. Probably this disables ALL cachable things in Portal, so it's quite normal it reached that amount of queries, am I wrong?

Yes I am.

Now I tried (in ACP) Portal ---> Blocks Management ---> 3 Columns ---> Edit (Nav Links of course) ---> Cache set to "no" and it worked... it was SO easy... I said by myself it was a caching problem and I didn't check that section -.-' too busy looking at the code I suppose  


(actually, nobody changed anything in that part configuration since site opened. It all worked fine till a week ago. Still I don't understand what really happened)

Quote:

All the switches are checked once in the PHP pages (most of them in page_header.php), so all switches in a TPL are parsed really really fast.

My advice is to avoid caching all blocks which do not involve SQL, because it's quite useless... take a look at the home page here... sometimes it's loaded in less than one second... and this site is on Aruba on a shared server...

Thanks for suggestions... I have a quick question about this: how are counted those huge numbers that define cache duration?

Quote:

I don't think security is a problem for this case... can you explain this to me?

No I can't, I was totally wrong  

Quote:

Even if some links are visible, it doesn't mean users may access them.

I know, but knowing that my users can't be attracted by that strange "ACP" links lets me feel safer...  


I'd like to apologize to other users and with MG for the unpleasant attitudes and misunderstandings with moreteavicar, hope it will never happen again here. Thanks to all guys, see you soon

No Problem Vortex

And now I should apologise! I realise now I made a mistake here - I thought mine was also cached, because I always see tpl_ca_aphrodite.nav_quick_links.php in cache - but this is misleading, I just checked the block file, and it was set to no caching. The cache file gets ignored if the portal block is set to no caching, and even with caching set to "no", a cache file still gets created (even if you clear cache, it will reappear), but it is always ignored! I honestly thought that there was something else setting the switch statement

Now I see this is actually the way the code works for the portal caching system. Its pretty counter-intuitive! If you or anyone is interested:

Relevent file: /includes/functions_portal.php

All block files are cached, regardless of individual settings:

The if statement above only checks if site caching is enabled, and does not check individual blocks. And then for displaying, we see what is going on at line 225:

This only pulls a block file from the cache directory if $block_info (pulled from BLOCK_TABLE, which is really phpbb_block in the SQL database) has cache set. Otherwise, following this section, the blockfile is generated, and cache ignored!

Very nice...



Can you tell me about the cache duration value? how is it counted?

The cache file timings are counted in includes/lite.php

You can see in /includes/functions_portal.php the use of funtions like get and save. These are defined in includes/lite.php. This file is a bit more like a classes file, containing a list of functions that work out how to get/save the file, and what the age of the file is. In simplest form, save() writes the time a cache file is generated to the file. When get() is used, it checks the saved generated time against the current time. If saved time > current time -cache duration, (on line 224, "_refreshTime" is really current time -cache duration) the cache file is used, if not, the function returns false. In this event, save() is called by /includes/functions_portal.php, from the section beginning on line 171 (The initial steps recreates the block from SQL, then save is called on line 207). What really matters is the "existence" of $block_info - if this can't returned from a cache file, then it is created from SQL. Just like in Physics we have conservation of Energy and momentum - in IMPortal you have conservation of $block_info!