A few ideas to improve the simplytest import module process (given only limited research of the inner workings of yet):
- Add the projects list XML as a Library in the projects makefile so that when building a fresh copy of the simplytest.me platform you will at least have the file ready to go.
- Have the file downloaded and imported during the installation of the simplytest profile
- Have the file downloaded automatically during the import process
That's basically the gist of it. After writing the suggestions I suspect that the second and the third would be the best options, however the first may help with the second to speed up the install process.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | import_processes-1845474-10.patch | 10.75 KB | deciphered |
| #10 | interdiff.txt | 5.94 KB | deciphered |
| #7 | import_processes-1845474-7.patch | 9.93 KB | deciphered |
| #7 | interdiff.txt | 6.49 KB | deciphered |
| #4 | import_processes-1845474-4.patch | 6.6 KB | deciphered |
Comments
Comment #1
decipheredGiven the size of the file it's unlikely the the automated download of 2 and 3 is a reality, ideally update.drupal.org could serve the information in smaller blocks, so that one call could be made to provide all the split up files and then each file could be downloaded inside of a batch so that it wasn't trying to download a 12mb file in one hit.
Perfect world....
In the meantime I think I can make an 'experimental' alternative to download the file with a very hight timeout set, but without the feedback of the file being downloaded it will be a bit of a pain to use.
Comment #2
patrickd commentedYes, I also don't think that the third one is really implementable, it's just too big.
Point 1 and 2 would be a way to go
Comment #3
decipheredActually, I've made some decent progress, while it can't use drupal_http_request (until D8), it is working well enough, still will mark it as experimental, but I'll have a patch hopefully in the next few hours.
Comment #4
decipheredPatch #1:
- Added two additional import methods: Upload and Download
- Reworked the batch operation.
Comment #5
patrickd commentedLooks good!
Importing by file path fails
As the case for this import method is not handled yet
Importing by upload fails, nothing happens.
file_save_upload() should be moved into form validation.
Importing by download, works! :)
Best practice stuff like
- deleting used variables
- checking for curl as requirement,
Comment #6
decipheredHmm, odd that the Import by upload didn't work, as I tested that one locally, could be a permission thing, and yes it absolutely should be in validate, that did occur to me.
Admittedly I didn't test the path based import, shouldn't make assumptions.
Otherwise, yes, the other changes make sense as well.
Comment #7
decipheredUpdated patch:
- Added simply uninstall function.
- Added curl dependency check, will only show download method when curl is available.
- Added import batch to the profile install.
- Added projects data as a Library and added .gitignore to ignore it.
- Improved upload method, no longer using file_save_upload as it was writing a record to the database for the file.
I have this locally in a feature branch, happy to push that to D.o, or just merge it in to master when you're happy with the patch.
Comment #8
patrickd commentedNice!
Some nitpick:
The installation task in simplytest.install always requires the xml downloaded by the makefile.
If it's not available it will just import nothing? Showing the import form in this case, would probably be better here..
'file' => drupal_get_path('module', 'simplytest_import') . '/simplytest_import.module',simplytest_projects_xml_insert_project() is in simplytest_projects - Is this already included?
I think disabling the download method and describing why, instead of completely hiding would be better
#44: [...]tic download (expirimental)[...]
The problem that nothing happens on the upload method is indeed a problem of my configuration - the file is simply too large
ultra nitpick:
"temporary://{$_FILES['files']['name']['upload']}",<-- I don't like this stuffif (!$file = file_unmanaged_copy($_FI[...]<-- I don't like this stufft('[..]<br /><em><strong>Note:</strong>[...].</em>');<-- I don't like this stuffsimplytest_import_batch_operation_process_xml()<-- could use some more commentsBut here's nothing you could not fix within 5mins, or anything too important..
This can be merged into 7.x-1.x
Thanks a lot!! :)
Comment #9
decipheredActually, that first point isn't a nitpick, it's a good solid bug, it should at the least check for the presence of the file before adding the install task.
Agreed on the disabling of the download method, that way at least the user gets to know that that additional method would be usable if they had CURL enabled.
As for the ultra nitpick, it's definitely a style thing, as I do like those things :), but I have no issue respecting your styling when possible, it's just that it won't always come naturally as habits are hard to break.
Though regarding the html tags in the translation string, I was against that for a while until I was proven that it's actually in the Drupal coding standards that they are meant to be included in the translation string. Of course if you're just saying you don't want to have the styling tags at all, that's another matter.
I'll have another crack at finishing up this issue when I finish work for the day (in about 4 hours).
Comment #10
decipheredOk, this time it should be good to go.
Changes include:
- Download radio button will be disabled with a brief description if cURL isn't available.
- If projects.xml isn't in the Libraries directory, don't add the import task in the profile (and a todo note for future import improvements in the profile install UI)
- Style changes.
Note:
Something related to my merge of the 7.x-1.x into my feature branch messed with the generation of the interdiff.txt, so please disregard any of the things in there unrelated to the issue, they aren't in the actual patch itself.
Comment #11
patrickd commentedOh you can ignore most of my ultra nitpick, as long as the code is understandable and documented you can make use of any yoda-condition you want ;-)
One small issue:
Just swapping these lines back solves the problem, after this small change it's ready to go for me
Comment #12
decipheredOopps, that was a completely last minute change for sake of code cleanup and documentation, can't believe I missed that...
Will fix before I commit (after I test properly :-) )
Comment #13
decipheredCommitted.
Follow up task: #1847402: Update README.txt for updated import process.
Comment #14
patrickd commentedcleaning up