Comment from Steven: It does this by redirecting the submission of the form to a hidden <iframe> when you click "Attach" (we cannot submit data through Ajax directly because you cannot read file contents from JS for security reasons). Once the file is submitted, the upload-section of the form is updated. Things to note:
* The feature degrades back to the current behaviour without JS.
* If there are errors with the uploaded file (disallowed type, too big, ...), they are displayed at the top of the file attachments fieldset.
* Though the hidden-iframe method sounds dirty, it's quite compact and is 100% implemented in .js files. The drupal.js api makes it a snap to use.
* I included some minor improvements to the Drupal JS API and code.
* I added an API drupal_call_js() to bridge the PHP/JS gap: it takes a function name and arguments, and outputs a <script> tag. The kicker is that it preserves the structure and type of arguments, so e.g. PHP associative arrays end up as objects in JS.
* I also included a progressbar widget that I wrote for drumm's ongoing update.php work. It includes Ajax status updating/monitoring, but it is only used as a pure throbber in this patch. But as the code was already written and is going to be used in the near future, I left that part in. It's pretty small ;). If PHP supports ad-hoc upload info in the future like Ruby on Rails, we can implement that in 5 minutes.
All node revisions were stored in a serialized field in the node table and retrieved for _each_ page view although they are rarely needed. We created a separate revisions table which would be in principle identical to the node table, only that it could have several old copies of the same node. This also allows us to revision-related information, and to provide log entries to non-book pages when a new revision is being created.
TODO:
1. Provide upgrade instructions for node module maintainers!
2. Upgrade modules that implement node types.
3. Provide an upgarde path for revisions. Dependency on the upgrade system.
NOTE: this patch works well, but the improved node edit form still has
some rough edges. It is important that we continue to improve
usability. Give it a try.
There are 5 main functions that modules may now utilize to handle images:
* image_get_info() - this function checks a file. If it exists and is a valid image file, it will return an array containing things like the pixel dimensions of the image, plus the 'type' and common extension.
* image_scale - resizes a given image to fit within a given width / height dimensions, while maintaining aspect ratio (not distorting the image). This function can be used to generate thumbnails, or ensure a maximum resolution, etc.
* image_resize - similar to image_scale (but will not respect aspect ratio - may well distort the image).
* image_rotate - rotate an image by X degrees
* image_crop - crops an image to a given rectangle (defined as top-left x/y coordinates plus a width & height of the rectangle).
Contribution modules will now be able to rely on these base manipulation functions to offer additional functionality (such as image nodes, photo galleries, advanced image manipulation, etc).
1) The different types of search, which used to be radio button options in the search form, are now subtabs of "search" (default "search/node"). This seems better from a UI point of view, but also has another advantage: modules which implement a custom search form (flexinode, project) can add it as a subtab of search. This means that all search forms will be located in the same place, and also without needing an extra api call to search.module.
2) The current code was a bit hackish, as the indexing of comments along with nodes was hardcoded in node.module. Instead, I created a nodeapi operation "update index" which allows modules to add more data for a node that is being indexed. Comments are now indexed using this mechanism and from comment.module, which is a lot cleaner.
3) The search results format was also hardcoded to include "N comments". I replaced this with a nodeapi operation "search result" and moved the comment code to comment.module where it belongs. This op is quite useful, as for example I also modified upload.module to add "N attachments" to a search result if any are present.
- removing file checks for uid #1 to be consistent with the roles/permissions.
- renaming script files to .txt's to prevent accidental execution (we don't allow them by default, but you never know)
Upload.module
- Fixing a bug caused by the PHP5 patches.
Beware: PHP4's array_merge() will silently accept objects and convert them to arrays. We should not depend on this behaviour in the future.
File.inc / file-using modules:
- Removing the constant FILE_SEPARATOR: forward slashes work fine on Windows, and it was being used incorrectly as an URL separator sometimes.
- Adding @ to mkdir and chmod to supress ugly PHP errors. They are already reported with drupal_set_message().
- Fixing default for variable 'file_directory_temp'.
- Clarifying the help tip for 'file_directory_temp' in admin > settings.
- Admin - upload only shows up for 'access administration section' perms
- Users without 'upload files' perm do not see the attachments form (and cannot attach even when sending their own http request)
Note: if a user can edit a node, but not 'upload files', then the attachments are left untouched (and cannot be changed).
This makes sense because people will expect attachments to work everywhere when they enable this module. This also matches comment.module's behaviour, where comments are allowed by default unless turned off.
Dries Buytaert
Steven Wittens