WordPress.org

1. raymer
   Member
   Posted 1 year ago #

   Tim,
   I started trying to use the xspf playlist for the first time and immediately ran into a problem. I am using the widget in a narrow sidebar. The widget works great and my msgs show up in the list but because they appear in the format Blog Title:Message Title I can't see the message titles. My Blog title is long and that uses up the entire width. I tried looking through the xspf php source and couldn't figure out where the list is being generated. I also tried using a filter to modify the blog title (replace it with '') but it didn't work.

   Any advice on how to modify the feed list titles for the widget?

   Thanks,
   Ray

2. ntm
   Member
   Posted 1 year ago #

   Ray,

   all the Feed <item>s, <entry>s and <track>s are being generated in the podpress_feed_functions.php.

   The XSPF items are getting generated in the lines 527 to 553 (trunk version).

   The player seems to take the information from the sub elements of the <track> elements. I believe the only way to keep the player from showing some of these elements, is to remove them from the playlist.

   The player is able to recieve a lot of parameters. Maybe the useid3 parameter is helpful for you.
   By default podPress uses only &autoload=true&autoplay=false&loaded=true. But the widget looks automatically for a /wp-content/plugins/podpress_options/xspf_options/variables/custom variables_1.txt file and take it instead of the default parameters if it exists. The number in the file name is the ID of the blog (for the main blog or a single blog is it 1) . /wp-content/plugins/podpress_options is ajustable via the constants PODPRESS_OPTIONS_DIR and PODPRESS_OPTIONS_URL.

   I see the problem and I think it is a good idea to have some options for these things at the player settings page of podPress. I will look into this too.

   Regards,
   Tim

3. ntm
   Member
   Posted 1 year ago #

   There is an variables_1.txt example file in /podpress/players/xspf_jukebox/skin_and_variables_files_examples.

   It is possible to filter the <track> elements via the hook 'podpress_xspf_trackinformation'. (all incl. <track>...</track>)

4. ntm
   Member
   Posted 1 year ago #

   Ray,

   I have took a further look on the list of parameters and I have discovered that there is the parameter format which is formatting the playlist entries.
   If you put for instance these variables: &autoload=true&autoplay=false&loaded=true&format=-title : -creator
   into the variables_1.txt file then then title of the episodes will be in left of the author/creators name.

   I'm going to add the necessary options to the player settings page of podPress (in the next days).

   Regards,
   Tim

5. raymer
   Member
   Posted 1 year ago #

   Thanks for looking at this Tim.
   I tried variations on the path you gave:
   "...xspf_options/variables/custom variables_1.txt"
   But could not get the widget to load anything from it - not even whenI just changed autoplay to true.

   I saw where to adjust the PODPRESS_OPTIONS_DIR but I think that is correct. I think the problem is that subdirs under the PODPRESS_OPTIONS_DIR and filename for variables_1.txt?
   Is it really supposed to be this:
   /wp-content/plugins/podpress_options/xspf_options/variables/custom variables_1.txt
   (note the space)

   Also I think the documentation in podpress_xspf_config-sample.php might be out of date. It says this:
   

   // If you want to use custom parameters then uncomment the following lines and edit or replace the variables.txt files in the folders /podpress/players/xspf_jukebox/dynamic/ and /podpress/players/xspf_jukebox/dynamic_slim/.
   if ( ! defined('PODPRESS_XSPF_USE_CUSTOM_VARIABLES_1') ) { define('PODPRESS_XSPF_USE_CUSTOM_VARIABLES_1', TRUE); }

   I did renamed the sample file and uncomment the appropriate lines, but those folders do not exist in my install...

   Thanks again for your help. I'm sure it's customizable already but if you are adding options to the next version I'll just wait for that! :-)

   -Ray

6. ntm
   Member
   Posted 1 year ago #

   Is it really supposed to be this:
   /wp-content/plugins/podpress_options/xspf_options/variables/custom variables_1.txt

   No.
   I'm sorry! Yesterday, I was a little bit to hasty. The folder is PODPRESS_OPTIONS_DIR.'/xspf_options/variables' so that the default path is /wp-content/plugins/podpress_options/xspf_options/variables/variables_1.txt .
   I have also forgotten to mention the PODPRESS_XSPF_USE_CUSTOM_VARIABLES_1 setting in the podpress_xspf_config-sample.php file. It is necessary remove the comment sign in front of that line. It is also necessary to copy that file to the /wp-content/plugins/podpress_options folder (PODPRESS_OPTIONS_DIR) and also to rename it to podpress_xspf_config.php.
   If those folder do not exist then you need to create them.

   I have had already done this in my main test blog and it works. But i have had forgotten it.

   The reason for storing the custom config files and skin files outside the podpress/ folder, is to save them from removal by an automatic plugin upgrade. During an automatic upgrade process all old files in a plugin folder are getting deleted before WP unpacks the new files.

   Using these custom config files is only intended as a possibility for technical minded people to customize the XSPF until I implement comparable options at the player settings page. I don't plan to leave it as is.

   Regards,
   Tim

7. raymer
   Member
   Posted 1 year ago #

   Tim,
   Thanks for the details. I figured out most of it from your notes in the readmes but for some reason I never tried moving the podpress_xspf_config.php into the PODPRESS_OPTIONS_DIR. I was leaving it in the PODPRESS dir and that was why I couldn't get it to take the variables_1.txt

   Got it passing the custom variables now. Thanks.
   -Ray

8. ntm
   Member
   Posted 1 year ago #

   Ray,

   the current Development Version contains a new option for the XSPF player at the Widgets page. I would be glad if you could test this version and tell me you opinion about it.

   I have also updated the explanation for the custom variables constant in the podpress_xspf_config-sample.php file. Thanks for making me aware of that issue.

   Regards,
   Tim

9. raymer
   Member
   Posted 1 year ago #

   Tim, sorry for the delay. I had a busy weekend. I have upgraded to pp 8.8.10 beta 8 and now my xspf player shows as empty. I renamed all config files and deleted the podpress dir and re-downloaded from svn so it should be fresh. I see the new options in the widget and they look like exactly what I was trying to do with the custom variables so thanks.

   But I refreshed my permalinks and saved the feed settings page in podpress and now the widget playlist is empty.

   Not only that, the default feed mysite.com/feed/podpress doesn't exist either. However the feed that I registered with feedburner is mysite.com/category/messages and that works fine. I registered the feedburner feed with iTunes so I am not too worried that the podpress default feed stopped working but I think that is the only feed that the widget reads by default?

   Anyway, I will probably have more time to look at this at the end of the week but unfortunately the upgrade seemed to have broken my default feed (and widget playlist) for some reason,

   Ray

10. ntm
    Member
    Posted 1 year ago #

    The podcast feed (/feed/podcast) and the XSPF playlist feed (/feed/playlist.xspf) are working but they have not items (and only an empty channel element). The reason for that is probably a different modification which I have made for 8.8.10.
    There is a procedure which should rename the meta_keys of podPress entries in the wp_postmeta table. podPressMedia becomes _podPressMedia and podPressPostSpecific becomes _podPressPostSpecific.
    This renaming has maybe not worked out. The MySQL command is e.g. UPDATE ".$wpdb->prefix."postmeta SET meta_key = '_podPressMedia' WHERE meta_key = 'podPressMedia' where ".$wpdb->prefix." usually is wp_.
    Is it possible that there are special permissions required for such an action?

    Or maybe the update procedure of podPress has not been executed. In this case the option podPress_version in the wp_options table is probably not the same as the version number you can find at the plugins page.
    This update procedure compares every time the plugin is used the version in the db and the version number which the value of the constant which is defined at the beginning of the podpress.php file.
    So this is independent of the method which was used to upgrade the plugin. (see lines 209-225 in podpress.php and lines 24-90 in podpress_upgrade_class.php)

    So maybe change the define('PODPRESS_VERSION', '8.8.10 beta 8'); to define('PODPRESS_VERSION', '8.8.11'); (podpress.php) or reduce the version number in the db to 8.8.9. Afterwards the next reload of a the blog page with a podcast post should start the upgrade process.

    If these meta_keys have still the old names then there are probably also problems with the podcast episodes in the posts at you blog pages.

    I'm sorry that this happened!

    Tim

11. ntm
    Member
    Posted 1 year ago #

    Ray, can you remember the steps during the installation of that beta version? Maybe I can try that too and reproduce the problem.

12. raymer
    Member
    Posted 1 year ago #

    Hi Tim,
    I had some time to look at this today. I noticed that the db had 8.9 in the PodPress_version in wp_options so I set it to 8.8.9 and reloaded my blog. Then the version changed to 8.8.10 beta 8 (which is correct) and the feed started working AND the xspf widget also populated correctly.

    So I guess the update procedure failed for some reason the first time. I suspect maybe I had a version conflict that I didn't notice. I update my plugins with svn directly from the svn.wordpress.org repository. After I deleted the podpress folder and ran svn update a second time maybe the update procedure did not work because it already changed the version to 8.9 to the first time?

    Anyway, its all good now.

    -Ray

13. ntm
    Member
    Posted 1 year ago #

    That are good news and it seems that the upgrade procedure works as expected. The condition which starts the upgrade process is: if the version number from the db (table wp_option -> podPress_version) is lower than the version defined by PODPRESS_VERSION then start the upgrade process.

    I believe that you have tried the experimental version from the repository last year. Dan has given that version the number 8.9.
    Because 8.9 is higher than 8.8.10 beta 8 the upgrade did not start.

    I'm going to extend the condition which compares the version numbers with a rule for 8.9 and I think I need to make big notice at the plugins page that downgrading from 8.8.10 to a previous version (or switching to "experimental") is not a idea.

    Maybe I should remove the "experimental" version from the /tags/ folder to make it more difficult to download this version. It will remain in the /branches/ folder and available via an SVN client but not longer via the Other Versions page.

    Thank you for taking the time. I'm glad that the podcast is working again.

    Tim

Topic Closed

This topic has been closed to new replies.