cash wrote on 40319224-06-08

The problem is that $oldview = get_input('view'); does not return the view parameter when the request goes through the rewrite rule. The request parameters get stripped out and get manually added back in page_handler().

Does anyone know why the rewrite rules do not end with &%{QUERY_STRING}?

Title changed from Simplecache can be set to regenerate and force lastupdate to reset to get_input() does not work in engine/start.php when request uses a page handler by cash on 40319224-06-08

brettp wrote on 40319515-07-13

I don't know why the rewrite rules drop the get params. This creates a bit of overhead on each page load because the request URI is parsed and any get params are extracted, and also creates bugs like this one. Off the top of my head I can't think of any good reasons for doing it in PHP instead of letting the server handle it.

trac user milan wrote on 40319536-07-16

Not sure we're on the same thread here, but I'll go through what I think is wrong steap by step:

1. someone visits http://www.example.com/

2. $oldview is set as 'default' (simplecache_default is not set)

3. cache is cleared and simplecache_default and simplecache_lastupdate is set

4. someone visits http://www.example.com/?view=rss

5. $oldview is set as 'rss' (simplecache_rss may or may not be set)

6. simplecache_rss is less than simplecache_lastupdate (set in 3)

7. cache is cleared and simplecache_rss and simplecache_lastupdate is set

8. someone visits http://www.example.com/

9. $oldview is set as 'default' (simplecache_default has already been set)

10. simplecache_default is less than simplecache_lastupdate (set in 7)

11. cache is cleared and simplecache_default and simplecache_lastupdate is set

... and so on ...

cash wrote on 40319606-04-26

milan - the first issue that needs to be solved is getting get_input() to work in start.php. Otherwise, the viewtype is being set to 'default' for rss views.

cash wrote on 40319670-08-23

milan, the second problem is as you point out - the lastupdate needs to be viewtype specific:

$lastupdate = datalist_get("simplecache_lastupdate_$oldview");
...
datalist_set("simplecache_lastupdate_$oldview", $lastcached);

I guess these are separate but related problems.

cash wrote on 40322475-09-13

To follow up on this, the fix is not as simple as just adding the viewtype to the simplecache_lastupdate parameter in /engine/start.php

When an upgrade is performed or a plugin is enabled, the last update time is cleared and right now the datalist does not let you do something like clear simplecache_lastupdate*

Either datalist needs to support an operation like that or you need to cycle through all viewtypes. Cycling through viewtypes is probably not possible since teh system does not know what viewtypes exist.

brettp wrote on 40322485-01-17

Sometime later this week I plan to save all valid view types upon view discovery to solve a related problem. I think this easier than requiring plugins to register a new view type because we have the data for what view types exist already, and plugins are used to being able to create ad-hoc view types.

cash wrote on 40358392-10-28

Fix to this will wait for Brett to add list of valid viewtypes.

See #2185 for related issue of viewtype not being set correctly due to rewrite rules

Title changed from get_input() does not work in engine/start.php when request uses a page handler to simplecache regenerated incorrectly based on viewtype by cash on 40358392-10-28

cash wrote on 40406819-02-22

Brett - any progress on having a list of valid viewtypes for a system? I've been waiting on that before putting in the final fix for this - or do you want me to handle it?

brettp wrote on 40406953-11-07

Sorry guys...this one totally slipped my mind.

Cash - I had some prototype code for this that I can try to dig up. The basic approach was to pull out the info from $CONFIG->views->locations after all plugins had loaded and save it into $CONFIG somewhere. Core views never end up in there and I was pulled on to other things before I could check why. If you want to handle it, feel free. Else, I'll tackle this over the weekend.

cash wrote on 40407019-07-07

I won't be able to touch this until Tuesday at the earliest.

I came across the issue of core views not being loaded when writing the Elgg developer tools. Since the view system falls back to core views there was never a need to pre-load them. You would need to list /views/ to grab the viewtypes that the core provides.

brettp wrote on 40407026-10-31

Not a difficult compromise then. I'll take care of this over the weekend.

brettp wrote on 40407914-05-16

(In [svn:6274]) Refs #2115: Added elgg_is_valid_view_type(). Currently calculated at each load but will want to cache like view paths.
Cleaned up autoregister_views() and load_plugins() code.
Added spaces between function params in numerous places. C'mon guys...spaces are free.

cash wrote on 40417627-09-24

(In [svn:6305]) Refs #2115 - simplecache is now viewtype sensitive

cash wrote on 40417636-10-27

Still to do:

• the viewtype list for core is not generated on upgrade because it is created in a function registered for the system init event
• elgg_view_regenerate_simplecache() creates all the cache files and then sets the last update to 0 - need to investigate

cash wrote on 40420285-03-29

(In [svn:6319]) Closes #2115 - simplecache is viewtype specific and does not regenerate twice per reset

ewinslow wrote on 40615116-04-04

Brett asked me to reopen this issue based on the following related problem:

It's possible to insert rows into the datalists table simply by visiting ...?view=. doing so will generate 2 rows (on 1.7.2, 1 row on pre-1.7.2).

simplecache_lastcache_
simplecache_lastupdate_

It doesn't matter what is. It could be a valid viewtype like "mobile" or an invalid one such as "". To a security scanner (which is how we found this), the behavior looks like SQL injection.

Would be good if we checked that is a valid viewtype -- if we do already, then the function is broken, according to my tests.

cash wrote on 40615218-01-27

The valid viewtypes are stored in $CONFIG->view_types
This is initialized on the boot system event.

A function could be added to test if a viewtype is valid and have Elgg automatically fallback to default if it is not valid.

And to nitpick, this is a distinct issue from this ticket

trac user milan wrote on 40615267-10-16

That would work, but $CONFIG->view_types isn't defined in Elgg 1.7.x, although it wouldn't be that difficult to back port that from 1.8 to 1.7.2

brettp wrote on 40615904-03-14

They're distinct, yes, but they're not unrelated. I asked Evan to reopen this one because I'm tired and confused it with a private discussion Milan and I had. Either way, I've opened a different ticket specific to this problem: #2406