I got it working and have been using it for a few days now. It is an application that adds articles to your blog from your desktop.
So far I like it very much and if you have contributors to your blog who are not teckie enough to do articles inside Serendipity this is the answer.
One process it especially helps is that it will automate getting a graphic onto your server to use in an article. [auto ftp] But in so doing it uses the ADD MEDIA area of Serendipity.
What is happening - rather than just adding the graphic and a small thumbnail to the upload directory - it is creating a new directory inside UPLOADS using the name of the article (with a number behind it), and adding two graphics, the one named and the one with the added _thumb. Both are the same size, it does not reduce the _thumb size.
I would much rather have these go directly into the directory as files rather than folders and not have the thumb at all...
Any way of messing with the Serendipity ADD MEDIA area to help with this...
Thanx RJ
Using Windows Live Writer
Just to make sure I understand: you want all the images to be jumbled together in one directory? I usually prefer to keep them separated by category, but keeping them separated by post isn't too bad. At least it avoids the "photo soup" problem I always experience when I look through my digital camera.
We can make that change, although I doubt we'd put it in the repository. (If I'm wrong and a majority of user think it's a cool idea, we'll definitely make the change, of course.) The file to look at is plugins/serendipity_event_xmlrpc/serendipity_xmlrpc.inc.php. On line 678, you should find the metaWeblog_newMediaObject function.
On line 692, you can see where we set $full. The $struct['name'] apparently comes from WLW (we retrieve it on lines 686 - 687)! This implies that WLW has a setting to change where it uploads images; not having a Windows computer, I can't check, I'm afraid.
Anyway. You can remove the directory from $full by changing line 692 to:
The thumbnail is a little harder. If WLW is sending it separately, we'll have to check $struct['name'] for "_thumb" and skip all the processing if it's there, returning a valid XML_RPC response. If Serendipity is creating it, the size might be the same because the original image is already thumbnail size. In that case, it should remain, since that's the image Serendipity uses for thumbnail displays.
We can make that change, although I doubt we'd put it in the repository. (If I'm wrong and a majority of user think it's a cool idea, we'll definitely make the change, of course.) The file to look at is plugins/serendipity_event_xmlrpc/serendipity_xmlrpc.inc.php. On line 678, you should find the metaWeblog_newMediaObject function.
On line 692, you can see where we set $full. The $struct['name'] apparently comes from WLW (we retrieve it on lines 686 - 687)! This implies that WLW has a setting to change where it uploads images; not having a Windows computer, I can't check, I'm afraid.
Anyway. You can remove the directory from $full by changing line 692 to:
Code: Select all
$full = $serendipity['serendipityPath'] . $serendipity['uploadPath'] . basename($struct['name']);Hey, you been busy? I had a hurricane right on top of my ass. Still trying to get things back together here. I dont like Ike. 
Lets see if I can explain this better.
First off this WLW I am finding is better than sliced bread and I am sure more and more poeple are going to find that also true and be moving that direction.
The blog uses lots of graphics, we try to put a graphic in each article and try to do 10 articles a day.
I have two directories for our graphics. One /graphics/ I use with my FTP. My helper needs the Serendipity media stuff and uses /uploads/
In her's there is a graphic and thumb for each, with thumbs sized at 110wide. When she begins using WLW she will no longer have to mess with that ADD MEDIA area at all, so thumbnails will no longer be necessary.
She and I both often look on the server for graphics we may have already uploaded. Much easier to do that in one directory, alphebetical and directories we have been in hundreds of times and pretty much know where thing are.
With WLW it takes the graphic and creates a directory in /graphics/ which is named after the title of the article with an added random number.
Inside the directory it puts two versions of the graphic, one with the orginal name and another with the name and _thumb. They are the same visual AND byte size usually somewhere around 350wide. Though the _thumb is slightly bigger for some reason. Here is an example at
http://rackjite.com/archives/2216-Who-i ... rtoon.html
If you hover the graphic or hit properties you will find it says:
http://rackjite.com/graphics/WhoisUnAme ... _thumb.jpg
Very much of our traffic comes from google images and that is an awful search string that having that _thumb in it makes one think its a thumbnail which it isnt.
I have a thousand images on the server, we will be adding thousands more, I really don't want thousands of directories. And I dont need thumbnails of any sort anymore, real or not.
Bottom line is:
I would like my FTP images to go as they are named directly into my /graphics/ directory with no thumbnails. And be able to have my helper put her's into her /uploads/ directory which she has been doing for a year. That choosing is done in WLW custom FTP.
It woujld be cool to have a few commands in the plug in window.
Like a yes no CREATE THUMBNAILS BOX and a yes no CREATE NEW DIRECTORIES BOX.
wow look how long that all is! gosh...
Thanx
RJ
Lets see if I can explain this better.
First off this WLW I am finding is better than sliced bread and I am sure more and more poeple are going to find that also true and be moving that direction.
The blog uses lots of graphics, we try to put a graphic in each article and try to do 10 articles a day.
I have two directories for our graphics. One /graphics/ I use with my FTP. My helper needs the Serendipity media stuff and uses /uploads/
In her's there is a graphic and thumb for each, with thumbs sized at 110wide. When she begins using WLW she will no longer have to mess with that ADD MEDIA area at all, so thumbnails will no longer be necessary.
She and I both often look on the server for graphics we may have already uploaded. Much easier to do that in one directory, alphebetical and directories we have been in hundreds of times and pretty much know where thing are.
With WLW it takes the graphic and creates a directory in /graphics/ which is named after the title of the article with an added random number.
Inside the directory it puts two versions of the graphic, one with the orginal name and another with the name and _thumb. They are the same visual AND byte size usually somewhere around 350wide. Though the _thumb is slightly bigger for some reason. Here is an example at
http://rackjite.com/archives/2216-Who-i ... rtoon.html
If you hover the graphic or hit properties you will find it says:
http://rackjite.com/graphics/WhoisUnAme ... _thumb.jpg
Very much of our traffic comes from google images and that is an awful search string that having that _thumb in it makes one think its a thumbnail which it isnt.
I have a thousand images on the server, we will be adding thousands more, I really don't want thousands of directories. And I dont need thumbnails of any sort anymore, real or not.
Bottom line is:
I would like my FTP images to go as they are named directly into my /graphics/ directory with no thumbnails. And be able to have my helper put her's into her /uploads/ directory which she has been doing for a year. That choosing is done in WLW custom FTP.
It woujld be cool to have a few commands in the plug in window.
Like a yes no CREATE THUMBNAILS BOX and a yes no CREATE NEW DIRECTORIES BOX.
wow look how long that all is! gosh...
Thanx
RJ
So you do want them all to go in one directory. Is the graphics/ directory your Serendipity media directory? It sorta looks like it is. In that case, the modification I posted earlier will get all your images in the same directory.
The thumbnail is a little harder. Serendipity doesn't seem to be creating the thumbnail; WLW does. And we can't just ignore the thumbnail, either, because WLW is using it in the post, linked to the original.
To get rid of the thumbnail, we'd have to check the filename for "_thumb", exit whenever we found it (hoping we didn't get any false positives), and change any reference to "_thumb" in the entry to remove that string (again, hoping we didn't get any false positives).
Changing the behavior of WLW is the much preferable solution.
The thumbnail is a little harder. Serendipity doesn't seem to be creating the thumbnail; WLW does. And we can't just ignore the thumbnail, either, because WLW is using it in the post, linked to the original.
To get rid of the thumbnail, we'd have to check the filename for "_thumb", exit whenever we found it (hoping we didn't get any false positives), and change any reference to "_thumb" in the entry to remove that string (again, hoping we didn't get any false positives).
Changing the behavior of WLW is the much preferable solution.
I got some Live Writer MS guy and I got the THUMB issue taken care of!
So all I need is to stop it from writing a new directory for each graphic file. Just a reminder, it names the directory after the article title and adds what looks like a random set of 4 or 5 characters...
Like the last graphic I put up was in an article titled
Image Test
and went into a directory called
imagetest_F140
Also for any future updates to the plugin, it would be cool, if with admin 255 rights, I could change the author. This should be done by Live Writer I would think but I doubt that will happen!
Thanx
RJ
So all I need is to stop it from writing a new directory for each graphic file. Just a reminder, it names the directory after the article title and adds what looks like a random set of 4 or 5 characters...
Like the last graphic I put up was in an article titled
Image Test
and went into a directory called
imagetest_F140
Also for any future updates to the plugin, it would be cool, if with admin 255 rights, I could change the author. This should be done by Live Writer I would think but I doubt that will happen!
Thanx
RJ
I went ahead and made the necessary modifications. I tested to make sure the new configuration worked on my sandbox, but since I don't use XML-RPC, I can't do a complete test. Would you try out my updated version and tell me how it works? If it works as expected, I'll commit it for others.
All my blog graphics IN ARITCLES go to
http://rackjite.com/graphics/
ailes.jpg
is the file I want to use in the atricle titled
test
I installed your new version and in the new box put in
/graphics
I also tried
/
default
No matter the url for the graphic is
http://rackjite.com/graphics/test_A443/ailes.jpg
As it was before
To make sure we understand what I would like the URL to the graphic to be is
http://rackjite.com/graphics/ailes.jpg
though... The MS guy at Live Writer Forum is now saying its a matter of FTP code... He said there is a way around that he would look into...
http://rackjite.com/graphics/
ailes.jpg
is the file I want to use in the atricle titled
test
I installed your new version and in the new box put in
/graphics
I also tried
/
default
No matter the url for the graphic is
http://rackjite.com/graphics/test_A443/ailes.jpg
As it was before
To make sure we understand what I would like the URL to the graphic to be is
http://rackjite.com/graphics/ailes.jpg
though... The MS guy at Live Writer Forum is now saying its a matter of FTP code... He said there is a way around that he would look into...
Hmmm. I thought that /graphics would get the job done. Let me see what I did wrong.
...
Just not seeing it. Perhaps the problem is that WLW isn't using the metaWeblog API, and so it's not calling the newMediaObject RPC. That's implied by the guy saying it's an FTP problem; if WLW used the RPC, it wouldn't need to do any FTP.
Of course, you mentioned that earlier, but I missed it. I must be getting sick again, or something.
If WLW is using FTP, there's not much we can do about it. I don't even know if the FTP transfer occurs before or after the article submission, so I can't tell if we could even write some custom function that scans the article to rename images, and simultaneously renames the actual image files.
How did you get WLW to stop setting the thumbnail, anyway?
...
Just not seeing it. Perhaps the problem is that WLW isn't using the metaWeblog API, and so it's not calling the newMediaObject RPC. That's implied by the guy saying it's an FTP problem; if WLW used the RPC, it wouldn't need to do any FTP.
Of course, you mentioned that earlier, but I missed it. I must be getting sick again, or something.
If WLW is using FTP, there's not much we can do about it. I don't even know if the FTP transfer occurs before or after the article submission, so I can't tell if we could even write some custom function that scans the article to rename images, and simultaneously renames the actual image files.
How did you get WLW to stop setting the thumbnail, anyway?
Remote blogging tools that use the metaWeblog "endpoint" can transfer files directly to your server. They use the same method that they use to transfer the blog post: they contact your blog via XML-RPC and hand it the data to be saved along with passwords and so on. Serendipity's XML-RPC plugin saves the media file and passes back the file's link. The tool uses the new link in the post body, then calls XML-RPC again to pass the post up, along with passwords, categories, and so on. Serendipity's XML-RPC plugin saves the new post.
Since I use the Serendipity post editing interface, I don't have any experience with the remote blogging tools. I couldn't tell you which ones do or don't use FTP, as opposed to the XML-RPC transfer method. All I can say is that it's part of the metaWeblog endpoint, and it's implemented in the XML-RPC plugin.
Since I use the Serendipity post editing interface, I don't have any experience with the remote blogging tools. I couldn't tell you which ones do or don't use FTP, as opposed to the XML-RPC transfer method. All I can say is that it's part of the metaWeblog endpoint, and it's implemented in the XML-RPC plugin.