6 replies to this topic

[Cris D.]

I am writing a snippet that creates a new etomite page when an etomite (front-end) form is posted. I have modified the save_content_processor.php file to perform the function but I wanted the know if what I am doing may have some adverse side effects on the Etomite database integrity or cache.

The process I'm using is:
1) Validate the user with $_SESSION user role and authenticate_visitor
2) Validate the form data being passed
3) Collect the $_POST variables to populate the $sql's (site_content, document_groups, site_content (parent), keywork xref) in the modified save_content_processor (snippet) file:
4) save/edit data depending on the 'new' or 'edit' var passed
5) then do a $etomite->clearCache() (instead of the syncsite incude: cache_sync.class.processor.php)

Q. Is it necessay to rebuild the cache after a clearCache? or does this happen automatically?

Q. Will this method of generating etomite content pages cause any problems that you can see?

[Dean]

Good Luck (you're going to need it).

If I remember right, there was a thread about this a bit back - you will fall foul of the cache. No one ever successfully got it working.

edit: I've not been able to find the thread (it was a long one), but I did find some info that mentioned $etomite->syncsite() - It rebuilds the cache.

[Cris D.]

I have a unique alias based on the $_SESSION['shortname'] and content is just a snippet call and snippet call parameters relating to the $_SESSION user so I can control the page content from the snippet. The users have no access to the page other than from the form which shows up when they log in. The page is created automatically the first time they register and save their details. This form saves data to a separate table which in turn is called from the snippet and shows up as their content. The docs show up in the manager tree OK and it all seems fine, I just don't know if it is doing something bad that I don't know about.

Quote

edit: I've not been able to find the thread (it was a long one), but I did find some info that mentioned $etomite->syncsite() - It rebuilds the cache.

Thanks for the tip.

[Ralph]

Yet another of the many reasons why a re-write is in order... The code base was never intended to allow fron-end access to back-end components... If you have problems they will most likely be related to the IN_ETOMITE_SYSTEM constant not being set...

[Cris D.]

I think there is still an outstanding issue with the syncsite() API as mentioned in this thread.

When I call the API I am getting incorrect file path to the cache file.

It is at line 105 as per polishprogrammers post and my cache_sync.class.processor.php file (0.6.1.4) does NOT have the

Quote

RALPH: If your file doesn't contain edits with the remarks // Modified 2006-08-24 By: Ralph Dahlgren then you don't have the correct script to begin with...

Quote

RALPH: I still need to check into the issue of the proper file not being in the bundled packages... I have posted the file that should have been in the downloads... The attached file properly handles class instantiation...
Attached File(s)
Attached File cache_sync.class.processor.php ( 6.57K ) Number of downloads: 17

But of course, this file is missing from the thread

I will post this to the bug tracker, but does someone have the correct file?

[Ralph]

I'm not sure if the whole process actually got perfected... I'll try to look into this ASAP...

EDIT:

Try this... Edit the manager/processors/cache_sync.class.processor.php file and change lines 108 and 154 to read $filename = $this->cachePath.'<filename>'; instead of a hard-coded path, using the correct filename for each line... Let me know if this resolves the problem...

[Cris D.]

Ralph, on Mar 17 2008, 11:13 PM, said:

I'm not sure if the whole process actually got perfected... I'll try to look into this ASAP...

EDIT:

Try this... Edit the manager/processors/cache_sync.class.processor.php file and change lines 108 and 154 to read $filename = $this->cachePath.'<filename>'; instead of a hard-coded path, using the correct filename for each line... Let me know if this resolves the problem...

Purrrrrfect. I confirmed that this works in the manager and as a snippet API.