Ability to add custom image to a podcast, have description and image on categories.

[ariselseng]

Hi again, I seem unable to add an image to a podcast. Is it the intended behaviour to only have it via id3tag?

Also, in my use case I would like the categories to have its own description and image. It could be great for itunes. That way the user could use the different categories as full standalone feeds. Would you accept a pull request for that?

[albertobeta]

hi, the image is just extracted from mp3 and the id3 tag.

In regards to the categories, this could be a future feature in the master branch, but it should be well integrated with the admin area (i.e. the category management should feature a button that allow to upload images associated to each category etc...). I'm planning to completely rewrite the admin area (making an HTML5 dashboard and using asynchronous upload rather than simply posting files via form etc... ) by the end of the year (unless someone wants to help and work hard on it, which would be great). This means that any admin-area feature developed in this transitional period now might need to be rewritten anyway in a few months. If you want to add images to the category one simple option could be adding a few lines of code in the generatePodcastFeed function, where:

• if a category is sent to the function, and if an image file with the same name as the category exists in image/ folder, it will be used in itunes:image rather than the default one This would work and wouldn't require any change to the admin section (you could upload manually images with the same names as the cateogories and they would appear in the feed). Thoughts?

[ariselseng]

That last one was actually around the same idea I had in mind. Just checking if there is an image would be good enough, it would also avoid having to code the admin interface part of it twice.

The most ideal solution would be to have as few disk io operations as possible and having everything defined in categories.xml. There is quite a few includes and lookups in the code, so maybe that could be something to have in mind when making the new admin area. The config file for instance is loaded 20 times on the front page. I am not sure if php caches the file, but if it does then maybe it's not a problem.

Anyways, I think I will do you what suggested and make some code that checks if an image exists. Maybe also make an upload button for image for a podcast entry too. If it that also patched the mp3 file with the image that would be perfect for beginners.

[albertobeta]

I know the code needs to be strongly optimized... Any help in this sense is more than welcome, feel free to fork and pull as much as you want ;) To be honest, adding MySQL would solve most of the problems: I was sticking to the original idea (due to "historical reasons" with the hosting space we had at the time) that PG would have minimal server requirements and would rely on simpe text files... I will improve the architecture and the goal is having a new PG 3 at the end of the year with all the aforementioned improvements. In the meanwhile, again, more than open to contributions from the community. I actually uploaded the source to GitHub precisely for this reason (before I had it on the official SVN on Sourceforge, but nobody - with just a few very small exceptions - ever contributed. I've been working alone on PG for the last 9 years, and mostly during my spare time. Welcome contributors :) )

[ariselseng]

I like the idea of not having to deal with a database. That is actually the reason I looked PG up. There are so many projects that need a sql database without needing it.

Actually, maybe SQLite would be the best of two worlds? I am not sure if SQLite is as supported by web hosts as MySQL though.

In any case, if the all the feeds (for each category) was cached like the main feed, and the html was generated when adding podcasts. There wouldn't be any need for performance in the code. As only the admin would run the PHP.

[albertobeta]

True. And thanks for the feedback, really. It's nice actually to have an entire script without the need of MySQL. SQLlite could be an option, but then it wouldn't be supported by all the hosting providers (e.g. cheap ones). One of the main strength of PG is that it really runs on any webserver today, as long as there is PHP support (just to give you the idea there is still a working and stable version of PG 1.4 that works with PHP4, and you have no idea how many users are still using it. Unbelievable.). The caching of categories feed could be definitely done. The sub feeds were actually an extra feature I added cause it was easy to do so, but not so many people really used categories feed, hence I had not so many requests for improvement. Most of the users prefer to install an instance of PG per folder since it's just a matter of copying all files in a folder and run the 3 steps setup.

[ariselseng]

At work, we are going to have around 4-5 feeds. But we want to have a main feed where you can get everything. Since our audience is so
I also hope to make a simple JSON API for PG so that I can integrate it with our CMS.

As for JSON, I think JSON would better fit the bill as for data storage than XML, especially since you are making a new admin interface with asynchronous upload. Thoughts?

[ariselseng]

I have preliminary support for custom image feeds and title+description in categories.xml in a branch here: https://github.com/cowai/PodcastGenerator/tree/enhancedCategories

Is there a specific reason for the categories to have their titles called description? To not break anything maybe the title should be description and the description to be called something else. Thoughts?

[albertobeta]

Maybe switching to JSON could be a good option in the future. In the category actually "description" is semantically not correct (originally the ID was the title and the description a description, but then many cleaning operation were necessary to the ID, so I used descritpion as title). In future I will move from the word description to title, supporting both at the beginning to ensure retrocompatibility. After a few releases of PG, the "description" could be used as an actual description of the category.