Issue: VaultWiki 4 - Pictures ...

thanks for the change - i can select now a file from the harddrive but it does not load it to the webspace - its still loading but then it stops

i have uploaded here a second pic of the error

Fixed in Alpha 2. Unlike the accesskey for other content types, the accesskey for attachments is not valid for the permissions model, due to possible collisions with "A"rea "P"ermissions. Thus, in order to find the right permissions, the area choosers in the editor/creator must first get an appropriate permissions selector via the accesskey. Once this code change is made, the area chooser appears, so the form can be submitted properly.

but that means that the upload of pictures then allready works ? because wiki content without pictures is not good ..

Unfortunatley is still the same issue as metioned above and documented in the error2.jpg screen that the attachment upload - specially pictures is not working

thats a very important feature - looking forward for a fix to get pictures in the content

thank you

Okay, according to the response headers, the file was being uploaded successfully, but the uploader-form never acknowledged this. It works properly for files that have been designated as image files, since the problem is that the Javascript is looking for a thumbnail when there is none. Additionally, the problem is that image file-types were not properly flagged as images when VaultWiki was installed.

This is all fixed now, but you will have to go through Content > Attachments, and make sure all the appropriate types have "Is this an Image type?" So that thumbnails will be made for those types.

unfortunatley still not working - now i can not change in the wiki-admincp the option "Is this an image type?" -> to yes - it does not save it ... and maybe the result is that the file upload has still the same bug as in the attachments here error2

thanks for your help

Since the fix was mainly Javascript changes, make sure to clear your browser cache. It works fine for me. The only thing is that editor-switch doesn't convert it properly, but I have a feeling that has more to do with the editor-switch not working properly. Due to the code design, I can't debug anything editor-switch-related without permissions to admin plugins. Please add that permission to my user.

mhm i have seen the picture now in the book area - when i click on it there is an error message and the style is broken - i will change the user i though its the same like my user

Warnung: finfo_file(/path_to/attachments/c/8/2/full.vw): failed to open stream: No such file or directory in [path]/vault/core/model/attach/vw.php (Zeile 116)

i have also tried now via creat new - attachment only and not in combination inside a page how it should be the easier way - i get the following error:

Errors


There were some problems with your submission:
Could not find phrase 'vw_invalid_filehash'.

The editor not using the default WYSIWYG state is now fixed. This actually wasn't affecting the attachment button. Something else is happening with that. Until it's resolved, WYSIWYG will be disabled for that BB-Code in future builds. Other BB-Codes will still be WYSIWYG.

For the finfo_file warning, this occurs if the attachments are stored in the database and you try to view the attachment page. It's fixed now so it tries to get the mime type a different way in that case.

As for not being able to set the image-type for the file types, this is now fixed. There was actually a user-input error that it wasn't telling you. You need to enter a max-width and max-height for images.

I'm not getting a vw_invalid_filehash error now. It's possible it was related to one of the other ones. Let me know.

okay great i get it now to upload an image - but there is an interesting issue:

i have uploaded the image "Job" (while the upload process when i click on create now i does not cancel the dialog an show the image outside - first i thought it hasnt upload)

the output of the image is always the pencil image - when i click inside the image it shows the correct one - but not for example when i put it inside a page - then there is the pen again.

This actually had nothing to do with the upload process. The upload process was already successful at this point (unfortunately that didn't keep me from looking in the upload process for an hour). This occurred when the page-id for the attachment was already finalized, the URL was using that instead of the image-hash, only when an existing thumbnail was not being requested, and only when attachments are stored in the database. Instead of displaying the requested image, the wiki_asset.php script was just displaying whatever image it felt like. The malformed query basically had "WHERE 1 = 1" without an order clause, and assuming additonal upload activity, the slave driver cached that one wrong result for a long time before selecting a different (probably also wrong) image.

This is now fixed in the current build.