Guys,
In regards to the OxWall 1.2 RC, I agree with a "closed beta". No one wants a beta versions freely flowing and mistakenly being used by unadvised people, creating unnecessary support requests and spreading bug reports about what is in fact a WIP.
However, you guys are missing the point of this thread: the "error" regards to deleted items (not only photos) that are kept as broken links in newsfeeds.
I confess that I was beyond surprised after reading the Addenster answer. He made me feel like if, somehow, the newsfeed was coded all wrong. That's why, before answering his message, I've decided to take a closer look into the source code. This way I could, at least, have the decency to reply him with a potential new idea for (maybe) a usable solution.
As far as I can see, the Newsfeed compile its data once and then save the resultant HTML in a static cache for future usage. It is NOT the "smarty" cache, it is a local specific static HTML, which seems to be created PER USER and not PER SYSTEM. This way, on sites with huge databases and tons of users, the newsfeed won't overload the server and will always perform fast, rebuilding only whatever is new, and attaching it to the specific static cached HTML.
As intelligent this solution might seem, the implementation was not done with the thoughts of "newsfeeds changes" in mind. I believe it is also related to the fact that photos and videos plugins were created after newsfeed plugin. Notwithstanding, the synchronization process requires too many resources, and if the page is rebuilt from scratch every time it is accessed, the server will eventually crash or (if you are lucky enough) slowdown as result of overloading.
With this scenario ahead of me, my goal was to think of a potential solution that wouldn't require the plugins to be completely rewritten and, at same time, that could keep the high performance as its priority. Based on these requirements, here is my conceptual implementation for us to solve such limitations and gain more power:
The plugins should be modified in a way that each plugin keeps small chunks of newsfeeds HTML, organized by users, time and date, and with some internal flags to identify what kind of operation was performed (the chunk can be one data and the flags another, both in the same Row of the same Table in the DB). This way, the plugin itself will be able to modify any chunk of older newsfeed based on users further modifications. I.E.: if an user deletes a photo, the plugin can read from DB the specific chunk of pre-built HTML that refers to that operation, modify it to avoid a broken link and maybe replace the broken thumbnail for one that says "deleted photo", then save the data keeping its referenced date unaltered. After that, the plugin can create a new chunk of HTML for the current transaction (a photo deletion) and add it at the Newsfeed list for current date/time/user. Such operations can be highly customized, and it is not a real challenge to create such "plugin based" data management (as each plugin will handle its data as they best understand it). It is not different than what a LOG does, only more elaborated.
In regard to the Newsfeed plugin, it will be only required to obtain the pre-created chunks of data and build the page on-demand based on the current data and how many feeds are marked to be listed. It is even possible to add a real-time updates using AJAX without requiring users to refresh the page.
In another words: changes on newsfeed contents (plugin based) should be handled and pushed by the plugin itself. It will also allow newer plugins to add data to the Newsfeed without requiring any change on the newsfeed plugin (I don't know how it is done today).
In general, even if such operations add a little bit more processing requirements to the plugins, it shouldn't be noticeable. The performance will probably be good as it is right now, but with a lot more power and options (including the so much desired PRIVACY).
Some other advantages can be obtained with such model:
1) Newsfeed can be programmed to ignore items (per user config), letting users to better customize their pages and preferences;
2) Users should be able to select, in real-time, specific newsfeed types to view or hide (i.e.: only photos, or only videos, or maybe photos and videos together, or yet only profile updates or per use newfeeds, etc);
3) It can be filtered by user, masked by date or range of dates and can even handle external feeds (from Twitter, Facebook, etc).
4) Newsfeeds will be able to reference back to other newsfeed entries. I.e.: A user delete a photo and I want to know when he/she did it. The deleted photo thumbnail can be programmed to jump to the newsfeed that display details of the deletion transaction (for instance);
5) Users can be allowed to delete/hide his newsfeeds related to some dates/operations/plugins from the feed and it will reflects to everyone immediately;
6) Did I mention CUSTOM PRIVACY OPTIONS on the plugin level? :)
I can think of a lot other possibilities and advantages for a Newsfeed plugin when the other plugins actually handle the updated data, especially if we keep it into the DB and use the power of SQL Queries to do the jobs of filtering and combining data for us.
Notwithstanding, we also have the Smarty helping the entire site with a great caching level and the MySQL query caches that can be programmed/used to minimize the amount of simultaneous access to the DB.
Well... This is how I imagine it could be better done. I hope it helps a little bit. :)
Let me know what do you guys think of such implementation model.