Yann “Bug” Dubois

98 Réponses à “ YD Network-wide Options ”

1. # 1 Mac_Boy dit :
   le 23 April 2010 à 23:09 h

   This is awesome, terrific! Thank you!

2. # 2 Y.Dubois dit :
   le 24 April 2010 à 1:18 h

   Hey, if you liked it, please rate it! Go to http://wordpress.org/extend/plugins/yd-wpmu-sitewide-options/ , log-in an give me as many stars as you like. That won’t cost you a thing. On the other hand, if you want it to cost you something, just click on the “Donate” button at your right, and get ready for a few more terrific plugins coming your way

3. # 3 Stuart L dit :
   le 27 April 2010 à 3:50 h

   This is a super plugin. I think my server (greengrants.ca) does not like it too much. I use the atahualpa 3.4.6 Theme which has about 100 separate options. At first, I checked about 10 options at a time and it kept updating my other blogs (I only have 6 wpmu blogs on this test install). It worked really good. Now I try to check one more option to update a new blog and it reverts to the “General Settings” page with no update to the new option I checked on the YD panel.

   Maybe you can comment your thoughts on this?

   Thanks,

   Stuart

4. # 4 Stuart L dit :
   le 27 April 2010 à 3:51 h

   oops, I mean keepgreengrants.ca (mistake on post above)

5. # 5 Y.Dubois dit :
   le 27 April 2010 à 10:42 h

   @Stuart L
   The latest version of the plugin has a checkbox at the end of the options list that reads “debug”. Please check that to get some more hints as to what goes wrong.
   My thoughts on this is that you’re reaching some limit as of the number of option changes your configuration can deal with before reaching some max execution delay or database timeout.
   The way the plugin works (as you will see in the debug info), you have to multiply the number of blogs you have with the number of sitewide options you select. If you select a few dozen options times 6 blogs, you quickly reach the few hundred figures.
   The way WPMU is built, each option change requires one or two database queries. That can be a problem when you try to cram a hundred or more database updates in one http transaction.
   A client of mine has the same kind of problem on a configuration where we want to replicate just 3 options over 100 wpmu blogs. We’re working on resolving that issue.

6. # 6 Y.Dubois dit :
   le 17 May 2010 à 18:27 h

   @All:
   Version 0.2.0 is just out, with a few bugfixes. It now works on sites with many blogs (fixed memory leak), and option updating is also fixed.

7. # 7 Dean dit :
   le 18 May 2010 à 4:50 h

   Hi. I discovered this plugin the other day and it was working fantastically.

   I just reinstalled WPMU on my website and when I activated your plugin I noticed that there was a new version.

   Now, I can’t get any of the setting from the main blog copies across to the sub blog I created. I’m looking to see where I’ve gone wrong but can’t see anything at the moment.

   Any ideas?

8. # 8 Dean dit :
   le 18 May 2010 à 5:38 h

   Actually, I’ve thought of something that is different with the installations that may cause a difference. When I first installed your plugin it was on a different domain that was the root domain on my host. Mleno.com is an addon domain on the same host.

   Would this make a difference?

   Thanks

9. # 9 Y.Dubois dit :
   le 18 May 2010 à 10:21 h

   @Dean:
   No, the domain makes no difference whatsoever.
   You could get an insight into what’s going wrong by checking the “Show debug messages:” checkbox at the very end of the options list, and then pressing “Update widget options”. (which should, by the way, rather read “update plugin options”).
   This will display a verbose line-by-line status of the settings replication on each blog.
   If you get no luck with the new version of the plugin, you can always revert to the previous version, but the new version is far more reliable once you have more than a few blogs to replicate to.

10. # 10 Dean dit :
    le 19 May 2010 à 7:45 h

    Thanks for your reply.

    Sorry, but where will I see the debug messages.

    I checked my error log and noticed the following after clicking “update widget options”

    Does this mean anything to you?

    [19-May-2010 05:42:20] WordPress database error Table ‘nzwebho1_mm.wp_5_croer_posts’ doesn’t exist for query SELECT SQL_CALC_FOUND_ROWS wp_5_posts.* , wp_5_croer_posts.post_rank IS NULL AS isnull FROM wp_5_posts LEFT JOIN wp_5_croer_posts ON (wp_5_posts.ID = wp_5_croer_posts.post_id AND wp_5_croer_posts.cat_id = 0) WHERE 1=1 AND wp_5_posts.post_type = ‘post’ AND (wp_5_posts.post_status = ‘publish’ OR wp_5_posts.post_status = ‘private’) ORDER BY isnull ASC, wp_5_croer_posts.post_rank ASC, wp_5_posts.post_date DESC LIMIT 0, 10 made by require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts

11. # 11 Y.Dubois dit :
    le 19 May 2010 à 10:04 h

    The error means your database is missing some tables so this is a pretty serious issue, but it has nothing to do with the use of my plugin, which does no direct access to the database. Your WPMU installation is broken, which may explain why the plugin cannot do its work.

    If you check the “Show debug messages:” checkbox and then press “Update widget options” right away as I told you before, the debug messages will show up on the top of the next displayed page on a yellow background.

12. # 12 Dean dit :
    le 19 May 2010 à 10:11 h

    Ok, I ticked the debug box and got the following:

    Action: I should now Update widget options.

    1 blogs to update.
    Widget options are updated

13. # 13 Y.Dubois dit :
    le 19 May 2010 à 10:15 h

    How many blogs do you have on your WP MU? My plugin sees only one, so if you have more, the issue is that the missing database table prevents it to account for all your blogs. If you do have only one blog then you have no need for this plugin in the first place

14. # 14 Dean dit :
    le 19 May 2010 à 10:21 h

    I have only one at the moment. Its just a test blog. There will be a lot more in the future

15. # 15 Y.Dubois dit :
    le 19 May 2010 à 10:28 h

    @Dean:
    The plugin needs at least 2 blogs to operate: one “master” / “root” site from which to copy the settings from, and one or more “child” sub-blogs to which the settings are to be copied. As long as you do not have at least 2 active blogs, it won’t do anything, as the debug message indicates now. ie. There’s no point in replicating the options to the master blog itself.
    Please activate a couple of child blogs if you want to test it in a meaningful condition.

16. # 16 Dean dit :
    le 19 May 2010 à 10:38 h

    That’s better. Thanks very much.

    Dean

17. # 17 Y.Dubois dit :
    le 19 May 2010 à 15:40 h

    @Dean:
    In fact it seems that you need at least 2 public child blogs for the plugin to work right now. This is in someway a bug. I will fix this in the next release so that a single child-blog is sufficient (in addition to the main/master blog), and the so that the child-blogs do not have to be “public” to allow options replication. Right now it’s a bit too restrictive. Thank you for pointing me to this problem.

18. # 18 Dean dit :
    le 20 May 2010 à 7:45 h

    Thanks. Its a really useful plugin.

19. # 19 Y.Dubois dit :
    le 27 May 2010 à 11:42 h

    @All
    Version 1.0.0 of the plugin was released on 2010-5-20. It includes a fix for the problem that @Dean has been reporting (you needed 2 child blogs for the plugin to work). It also includes new features:
    - “Autospreading” of settings changes is now an option (can be enabled/disabled in the plugin’s settings)
    - Can now auto-apply default options when new blog is created
    - Can now disable overwriting of existing options when updating from the settings page: this way you can keep you manual settings on some child blogs while retaining the “sitewide default options” feature.

20. # 20 Alex Dominic dit :
    le 14 June 2010 à 11:23 h

    WPMU site, activate the plugin in the main blog, choose which widgets are activated for all blogs. Save settings but the changes do not occur. What? have instructions with photos of the screen? I hope to help!

21. # 21 Y.Dubois dit :
    le 14 June 2010 à 11:47 h

    @Alex Dominic
    The WPMU Sitewide Options plugin will propagate the widget *options* to all your blogs, but it will not activate the widgets themselves on each blog. If you want to activate some widgets on all your blogs, you will probably still have to do it manually. Once the widget is activated, however, when you change some setting in the main blog it will be changed the same way in all your blogs. I don’t know if there is a way to activate the same widgets in all the blogs. Maybe you can do it by propagating some specific WP core options, I did not check into that.

22. # 22 GLerner dit :
    le 22 June 2010 à 20:00 h

    @Dean, I couldn’t get WP3.0 multi-site working (subdomain mode) when it was installed on an add-on domain. I moved my web site from public_html to an add-on domain, and installed WordPress 3 in public_html, and multi-site worked fine.

    Did you get multi-site working for sub-domains, when installed in an add-on domain? When you type nonexistentsubdomain.mydomain.com do you get the page to create nonexistentsubdomain’s blog?

    I have a blog post about how to install WordPress with existing web sites, http://lcblog.lernerconsult.com/2010-wordpress-3-multi-site-installation-existing-web-sites/

23. # 23 GLerner dit :
    le 22 June 2010 à 21:38 h

    I don’t know what most of the settings are, since the parameter names are not what is displayed on the Settings pages.

    Is there a way to display the Plugin name, and the “human readable” name of the setting? Next to the computer parameter name?

    I can’t tell which parameters I care about, or which ones I have changed from the plug-in default values. How about displaying the value of the main blog on this network?

24. # 24 WordPress 3.0 Multi-Site Installation for Existing Web Sites | Lerner Consulting dit :
    le 22 June 2010 à 23:09 h

    [...] Carrington Theme by Crowd Favorite Highlighter powered by RoohIt (for WordPress) Featuring WPMU Sitewide Options plugin by YD [...]

25. # 25 Y.Dubois dit :
    le 22 June 2010 à 23:50 h

    @GLerner
    Right now I don’t see a way to tie options to plugins, as there was historically no standard way of declaring, storing and managing plugin and widget settings. Since the new versions of WP, there is an official recommendation as how to implement plugin settings, and there are some registration hooks. It will however take some time for plugin developers to adopt these new standards (my own plugins don’t yet implement them). Older plugins will probably never comply, so there is no practical way to link plugins and their options, except for parsing each plugin’s code which is also impractical.

    Furthermore, there is no such thing as an official “human readable” title for an option. Developers choose to name their option keys as they like, and can display whatever labels they want in the html of administration forms, without a formal way of tying field labels, field names and the database option keys themselves. So I’m sorry but it looks like a no-go.

    Displaying the “main blog” setting would be easy for settings that are just plain text strings. However, once again, there is no standardized way of storing the setting values inside the option key. It could be strings, serialized arrays or objects, or anything else… many values can be stored in the same options key using an array or object.

    If you have any suggestion as to how main blog settings values could be displayed, I am interested.

26. # 26 GLerner dit :
    le 24 June 2010 à 1:46 h

    In MySQL, wp3_site.id and wp3_sitemeta.site_id link, so you can display the meta_key with meta_value and the domain. That’s a start.

27. # 27 Y.Dubois dit :
    le 24 June 2010 à 15:32 h

    @GLerner:

    meta_value can be any kind of serialized data, so I still don’t see how it could be displayed (a php var_dump() of the de-serialized value would work, but look ugly). Meta_key is already what’s displayed “as-is”.

    The problem is not linking values to blogs (that’s trivial, as you mentioned), but rather linking meta_key to a specific plugin or admin setting to get some kind of meaningful “human readable” title, as you first suggested. And I still don’t see a simple solution.

28. # 28 matt dit :
    le 24 June 2010 à 18:23 h

    For some reason, i can’t seem to get the settings from my master blog to replicate to new blogs. I have checked the debug option and everything looks ok and i have checked the option to spread options to new blogs (the other 2 i have left unchecked).

    Then when i set up a new blog none of the changes have occurred. I have tried re-activating each of the affected plugins sitewide (using the plugin commander) after having run YD WPMU Sitewide options and THEN making a new blog, but it didn’t seem to work. I’ve also deactivated YD WPMU on the network and then re-activating it after having made the changes.

    I am working on YD WPMU through my main blog plugin interfact (not the wpmu interface) – do you know what the problem may be? I’ve got wpmu 3 installed

29. # 29 GLerner dit :
    le 25 June 2010 à 7:49 h

    Ugly, definitely. Maybe just the 1st nn characters of data, vertical bar separating fields, do the best you can do easily. It would at least give users some idea of what is in the data, some way of judging whether to set the info when creating a new blog, or whether to force updates, or “don’t bother, the default is fine” vs. leave the current settings for other blogs in the network.

30. # 30 GLerner dit :
    le 25 June 2010 à 9:13 h

    How about a different approach…

    I’d probably care most about the variables that are set differently in the main blog than in the other blogs in the network. That might either indicate that this variable should be set differently for each blog (for example, the blog title, or Twitter account), or that I’d just made a change that I might want to copy to other blogs (for example, the permalink structure or time zone).

    Perhaps show the 1st (or most recent?) 5 unique values found (if there are 200 blogs, don’t show 200 different values), as meta-key : subdomain/subfolder : value.

    Like you said, no way to make it pretty, so just pick some sensible, easy way of displaying what you have access to, and go with that. Unless, of course, the add-on developer uses a standard way of communicating the property name and values.

31. # 31 Y.Dubois dit :
    le 25 June 2010 à 17:56 h

    @matt

    In my experience it works if you activate YD WPMU Sitewide Options on your main (admin/first) blog, and if the plugins you are trying to spread the options from are activated network-wide. However I did not have a chance to test this on WP3.0 yet.

    The action for spreading the options to the new blog is triggered when the blog is added. So YD WPMU Sitewide Options needs to be activated and configured before you create the new blog. Ans so should your “master” plugin settings. It cannot detect “new” blogs retroactively (they’re not new anymore), and it cannot propagate “unset” settings.

    If your blog is already created if you check the other two checkboxes and re-save you plugins’ settings, they will be spread to all existing blogs including the new one.

    If someone else can confirm that this features works in WP3.0 it would be a great help. Otherwise you’ll have to wait a bit till I have time to make regression tests of each feature on WP3.

32. # 32 matt dit :
    le 28 June 2010 à 17:56 h

    I’ve tried using this plugin on another site of mine that’s running wpmu 2.92, and it won’t propagate the settings to new blogs either when I add a new blog through /wp-admin/wpmu-blogs.php – when i have all the boxes checked (Overwrite existing blog settings:
    Automatically apply future changes to all blogs:
    Spread options to new blogs:) it updates all the existing blogs. But when I add a new one, it doesn’t seem to work. For the new blogs, the YD sitewide options are blank – and the other options aren’t configured.

    I only really want to apply these new settings to new blogs, but for some reason it doesn’t seem to want to work?

    Do you have any ideas as to why this might be?

33. # 33 matt dit :
    le 29 June 2010 à 0:03 h

    hey yan,

    i see that you’re available for plugin consulting – i’ve got a plugin that i need to modify- i think it’s fairly straightforward for you but if you could email concerning your availability, that’d be great!

    and i need to get your plugin working on my site

    Thanks a lot yan!!

34. # 34 Y.Dubois dit :
    le 29 June 2010 à 0:41 h

    @Matt

    I’ve sent you an e-mail. Thanks for consulting.

35. # 35 liven dit :
    le 3 July 2010 à 0:54 h

    See one review on this plugin – any chance that you can polish this up so it can be easier to apply??

    Review posted below:

    Not for the faint of heart. The plugin appears to just present database field names from your plugins with checkboxes about whether to propagate each of them site-wide. For example, here are some of the options I have listed (and this is only about 20-30% of the list on a site where I have only 15 plugins installed):

    cron
    current_theme
    dashboard_widget_options
    date_format
    db_upgraded
    db_version
    default_category
    default_comments_page
    default_comment_status
    default_email_category
    default_link_category
    default_pingback_flag
    default_ping_status
    default_post_edit_rows
    default_role
    easy_privacy_acknowlegement
    easy_privacy_CreatePageId
    easy_privacy_email
    easy_privacy_lastupdated
    easy_privacy_pagetitle
    easy_privacy_pageurl
    easy_privacy_section_five
    easy_privacy_section_five_selected
    easy_privacy_section_five_title
    easy_privacy_section_four
    easy_privacy_section_four_selected
    easy_privacy_section_four_title
    easy_privacy_section_one
    easy_privacy_section_one_selected
    easy_privacy_section_one_title
    easy_privacy_section_six
    easy_privacy_section_six_selected
    easy_privacy_section_six_title
    easy_privacy_section_three
    easy_privacy_section_three_selected
    easy_privacy_section_three_title
    easy_privacy_section_two
    easy_privacy_section_two_selected
    easy_privacy_section_two_title
    easy_privacy_sitename
    embed_autourls
    embed_size_h
    embed_size_w
    enable_app
    enable_xmlrpc
    gltr_ban_prevention
    gltr_base_lang
    gltr_cache_expire_time
    gltr_col_num
    gltr_compress_cache
    gltr_conn_interval
    gltr_enable_debug
    gltr_html_bar_tag
    gltr_last_connection_time
    gltr_my_translation_engine
    gltr_preferred_languages
    gltr_sitemap_integration
    gltr_translation_status
    gltr_use_302
    gmt_offset
    gzipcompression
    hack_file

    While some of these are pretty self-explanatory, and some can be grokked, I have no clue what some of them are. gzipcompression? That could apply to at least a few different plugins I have installed. cron? A lot of stuff we do in WP uses cron jobs. So what will be effected if I check that one?

    I like the concept and respect the developer for putting it out, but I think it’s still a bit unpolished/”beta”. His forum does have a thread for support, and he seems to be working on fixing bugs and enhancing it, so that’s encouraging.

    I was able to use it to apply settings for yarpp sitewide, that worked fine. My gut reaction is that the tool was written by a good developer in the way that many coders write tools – the interface makes perfect sense to the person who wrote it but sometimes will have a stiff learning curve for anyone else.

36. # 36 Andrew dit :
    le 5 July 2010 à 16:26 h

    For some reason when I try to update the options page after checking some boxes, it redirects to the “General Options” page without any of the settings being saved.

37. # 37 Y.Dubois dit :
    le 5 July 2010 à 18:07 h

    @Liven

    As was already discussed on this page, there is no way to make the option names “human readable”, so that this plugin will always remain something geeky. This has nothing to do with my interface skills or whatever. It’s just the way existing WP plugins and their options have been developed historically. I’m not sure whoever wrote this review understands exactly what this plugin is for and what it does (otherwise, they would not confuse option names with “database fields”). A new version of the plugin will come out shortly addressing part of the usability issue (Building up on @GLerner’s suggestion that displaying the values of some of these options can help figure out which options relate to which installed plugin).

    People that have a need for this plugin do know what they are searching for, and understand quite well how it works. It’s probably of no use to others. I remain open to any suggestion as how the interface could be further improved. But it will remain a powerful tool to be used by people who understand at least the basic concepts of WP options.

38. # 38 Y.Dubois dit :
    le 5 July 2010 à 18:14 h

    @Andrew

    Which version of the plugin are you using, on which version of WP?
    Do you get any kind of warning or error message (on a yellow or pink background?)
    Did you try checking the “show debug message” checkbox to get more info on what’s happening?
    Looks like the plugin can’t save its settings, but this could happen for many reasons… most of them unconnected to the use of this plugin.

39. # 39 Y.Dubois dit :
    le 6 July 2010 à 0:10 h

    @All

    Version 1.1.0 is just out. Thanks to @Matt for funding this version. The new version has an improved process for automatically spreading options to new blogs (including WordPress core options such as activated plugins, or Akismet API key, etc.). It also includes the German translation kindly provided by @Rian, and some of the options selection interface improvements suggested by @Glerner, above.

    It is fully compatible with WordPress MU 2.9 and WordPress 3.0.

    Enjoy!

40. # 40 Andrew dit :
    le 6 July 2010 à 0:31 h

    Upgraded to see if it helped. Getting alot of :

    “unserialize() expects parameter 1 to be string, array given”

    in the “Value from master blog:” column.

    Also now when I click Update Widget Options it doesn’t redirect me anywhere! I just stay on the page with no sign of Firefox wanting to budge (no loading bar).

41. # 41 Andrew dit :
    le 6 July 2010 à 0:34 h

    Full error:

    “unserialize() expects parameter 1 to be string, array given in /home/weaponso/public_html/wp-content/plugins/yd-wpmu-sitewide-options/yd-wpmu-sitewide-options.php on line 298″

    Is this a new feature? The options being updated and sent out without the page being refreshed? Or is this an actual problem?

42. # 42 Andrew dit :
    le 6 July 2010 à 0:42 h

    And one last thing sorry…
    Reset Widget Options button does work.

43. # 43 Y.Dubois dit :
    le 6 July 2010 à 3:26 h

    @Andrew
    You still did not tell me which version of WordPress you are using? I just committed version 1.1.1 of the plugin to solve your issue with the warning from the “unserialize” function. Also, I don’t understand if the Reset button works or not. Could you please be more specific about that?
    Thanks.

44. # 44 Andrew dit :
    le 6 July 2010 à 8:04 h

    I am using WordPress 3.0.
    I said the Reset button works because the Submit button doesn’t. It doesn’t lead me or redirect me to an updated version of the options page or anything.

45. # 45 Jason dit :
    le 6 July 2010 à 19:32 h

    Hi.

    We are trying to get the standard wp custom header setting in 3.0 applied throughout our other sites, and new sites. Your plugin is great for tons of the settings we need applied, but we can’t figure out the header setting.

    Thanks,
    Jason

46. # 46 Andrew dit :
    le 7 July 2010 à 4:33 h

    Bug: Table width of the options is way too wide, cant click anything in the right sidebar (ie. donations).

47. # 47 Y.Dubois dit :
    le 14 July 2010 à 19:05 h

    @Jason:

    The setting you are searching for is stored as serial data in an option key named “mods_Twenty Ten”. That option key is only created when you modify the default settings from your blog in the header settings page.

48. # 48 Y.Dubois dit :
    le 14 July 2010 à 19:17 h

    @Andrew:

    Which version of Firefox are you using, on which OS? I cannot reproduce the problems you are pointing to, so it’s hard for me to fix them. I thoroughly tested the pages on WordPress 3.0 with Firefox 3.6.6 and Chromium 5.0 on Ubuntu Linux, but I don’t get the same problems. The pages are rendering fine and the submit buttons do work. Some of my clients using this plugin are running on Windows/IE and did not report any rendering problem either.

49. # 49 Andrew dit :
    le 15 July 2010 à 4:44 h

    I am right now using Firefox 4.0 Beta 1 on Windows 7 64 Bit, and I have tried with Safari, Chrome, Opera and IE and none of the browsers have the submit button working. The pages are rendering fine now, just some serial data going crazy so I deleted some entries in the wp_options table, but submit button doesn’t work but the reset options button does.

50. # 50 Y.Dubois dit :
    le 15 July 2010 à 18:08 h

    @Andrew:

    I just released version 3.0.1 of the plugin in the WordPress.org repository. I made sure the administration page XHTML fully validates with the W3C standards. This should fix any browser-specific incompatibility you encountered. I hope the buttons will work for you now.

    @All:

    Version 3.0.1 is a major milestone release with a lot of small visual bugfixes, a better option selection interface and an improved WordPress 3.0 compatibility. Thanks to all for reporting bugs and suggesting features. The plugin also now changes name to adopt WordPress 3.0-compatible vocabulary and concepts. Upgrade the usual way automatically or manually.

51. # 51 Asshu dit :
    le 19 July 2010 à 14:16 h

    Sir ,
    I am ready to translate the plugin into two Indian languages .

    Thanks !

52. # 52 J dit :
    le 20 July 2010 à 2:56 h

    When I submit the new 3.0.1 form in wordpress 3 trying to copy over More Fields plugin settings, I submit and get a blank page (probably suppressed PHP error). Any thoughts on what this is?

53. # 53 GLerner dit :
    le 20 July 2010 à 3:00 h

    Is there a way to tell what settings would be transferred simply by the WordPress “Update” in SuperAdmin, without this plugin at all? Then use this plugin for the few fields that I need it for?

    It there some way for the plug-in to automatically create a random-name new site, read its settings, and color those settings that are automatically set differently? (Then give updated results when run again).

    Every bit you do is helpful, this “which settings do I need to change on all my sites” is an administrative hassle. Thank you!

54. # 54 J dit :
    le 20 July 2010 à 3:21 h

    Anyone else having a blank-page issue when they submit this plugin? (I’m only trying to propagate the settings for the More Fields plugin, a very popular plugin for wordpress workers)

55. # 55 Y.Dubois dit :
    le 20 July 2010 à 10:32 h

    @J

    Please check the “Show debug messages” checkbox; it should tell you more about what is going wrong.
    How many sites do you have? How many options are you trying to propagate?

56. # 56 Y.Dubois dit :
    le 20 July 2010 à 10:37 h

    @GLerner

    In a future version I might create a database of “known options” (ie WP core settings, widely used plugins settings, etc. with their human readable field names) I am still researching on the best way to build such a database (it would be community contributed) and implement it. Core setting options could then be marked to indicate which ones are propagated by WP and which ones are not. But that’s for the future, because right now I have no time to spend on this plugin.

57. # 57 Y.Dubois dit :
    le 20 July 2010 à 10:38 h

    @Asshu:

    Thanks for your translation proposal. I have answered to you by private e-mail.

58. # 58 Asshu dit :
    le 20 July 2010 à 11:50 h

    @Y.Dubois
    Yeah ! I checked it sir ! I will be on this work in a few days.

59. # 59 mscappa dit :
    le 20 July 2010 à 14:06 h

    I am using the p2 theme and it seems that your plugin is not carrying over my mod’s to all new sites created. Primarily with the theme admin functions like, the header image and others. I need to force the update in order for my modifications to carry over to their sites, each time. Otherwise they’re given a half-baked theme on their initial install.

    Is this plugin intended to create these new mod’s for all new users of multisite, WITHOUT having to update them each time?

60. # 60 Y.Dubois dit :
    le 20 July 2010 à 17:21 h

    @Mscappa:
    Yes, the plugin does carry options to new sites automatically if you check the “Spread options to new blogs:” checkbox in the admin panel. Please make sure that checkbox is ticked to enable this feature.
    Also, be sure to have the options you want to carry over checked, and set as you like in your main “number one” site.

61. # 61 mscappa dit :
    le 20 July 2010 à 17:26 h

    Thanks for your response! I have the spread button checked as well as the theme “mods” checked in my list. Running debug shows all processes are being carried out. However, the “mods” are not being carried out with new site installs. It only works when I update the plugin, not when users are creating a new site.

    Is there another button that should be checked?

62. # 62 Y.Dubois dit :
    le 20 July 2010 à 17:51 h

    @Mscappa:
    Are you using the latest vesion (v.3.0.1) of the plugin?
    I quickly took a look to the p2 theme. It is a very complex theme which defines a lot of proprietary functions. Something might reset the settings the first time a new blog is created and overwrite the options set by the Network-Wide Options plugin. This needs to be checked. Maybe you can uncomment the debug code at lines 609-616 of the plugin to understand what happens.

63. # 63 J dit :
    le 20 July 2010 à 19:41 h

    @Y.Dubois

    I have one main blog and one sub blog for testing. It’s when I submit the form with any values that the form fails, so I can’t even set the debug messages. When I go into the code and manually set $d to true, nothing shows up either. It’s symptomatic of some PHP failure. When setting error_reporting(E_NOTICE), there’s a horde of offset notices, however not sure how these impact the plugin or my problem in particular.

    I’m using WPMU upgraded to 3.0 through official channels, and nothing too crazy plugin-wise (More fields, cache (disabled for development), NextGen Gallery). I have php safe mode on, as well.

    Thanks

64. # 64 J dit :
    le 20 July 2010 à 19:43 h

    Also, found a bug where a setting reads ‘autospread’ but you reference the argument as ‘autospreading’. Also finished one of your items on the todo. I’d be happy to provide some updated code to you after we get my blank screen issue hammered out.

65. # 65 mscappa dit :
    le 20 July 2010 à 21:19 h

    yes, i am using the latest version of the plugin and on wp 3.0 using multisite. I just hard coded the custom theme changes I needed which works.

    Great concept for a plugin, but it just doesn’t work with P2 theme. Are you aware of any other themes that it’s not working with? Perhaps you should post on your plug-in page so that others with P2 theme don’t waste their time trying to get it to work?

66. # 66 Y.Dubois dit :
    le 20 July 2010 à 21:54 h

    @J:
    Thanks for noticing the autospread/autospreading typo. However, this has no harmful consequence.

    You should first try de-activating all other plugin and check if it works that way. If it still does not work, maybe check without php safe mode (which is obsolete anyways if you run a recent version of PHP).

    If it works without the other plugins, then re-activate the plugins one by one to find which one is conflicting.

    You should also check your web server’s log files: maybe the fatal PHP error can be found there.

67. # 67 Y.Dubois dit :
    le 20 July 2010 à 21:56 h

    @Mscappa:
    It is not conceivable to test a WordPress plugin against all existing third-party themes and plugins, so I am not aware of any incompatibility; it is only users like you that can report incompatibilities, as you have just done. You are the first one to report such a problem.

68. # 68 J dit :
    le 20 July 2010 à 22:11 h

    Found some other bugs. There’s some constant named ARRAY_A in your code which doesn’t do anything.

    Also, I fixed my issue by making the form submit as POST instead of GET. This especially helps if there’s a number of options you want to change, as GET string has a character limit while POST’s is much more generous.

    HTH,

    J

69. # 69 Y.Dubois dit :
    le 20 July 2010 à 22:20 h

    @J:
    I sent you a private e-mail; if you want to send over some updated code. I’ll be happy to include it in the next release of the plugin. ARRAY_A is a core WordPress constant used by the wpdb class. If you are using a debugging software, you should make sure all dependencies are loaded and analyzed (which is very difficult to achieve with WordPress).

    The GET/POST character limit is server-specific. You might have some security package (such as mod_security under Apache) that restricts the use of some characters in URL GET strings on your specific hosting configuration and could explain the blank pages. I might switch to POSTing the forms in future releases, but there might be some backward-compatibility issues to consider.

70. # 70 Asshu dit :
    le 23 July 2010 à 9:29 h

    Do you mind If I ask for support via email?

71. # 71 Asshu dit :
    le 23 July 2010 à 10:43 h

    Hello !
    I am getting this error when trying to set the Network wide rules using “YD Network-wide Options ” plugin.

    “Request-URI Too Large

    The requested URL’s length exceeds the capacity limit for this server.”

    Does any one have such errors? Could you please help me to get over from this problem?

    Thank you !

72. # 72 Y.Dubois dit :
    le 23 July 2010 à 11:36 h

    @Asshu

    1> I don’t offer free support by e-mail. We can however arrange for professional support / private consulting for a fee or in exchange for “donations”. I only do free public support on this page, when time allows, so that everyone can benefit from the answers.

    2> You seem to be encountering the same kind of GET-request length limitation as @J. I am considering converting form submission to the POST protocol in the next version, which would fix this problem. In the meantime, maybe @J can give you his code (he did not send it to me yet).

73. # 73 Asshu dit :
    le 28 July 2010 à 14:02 h

    @J
    I am getting this error :“Request-URI Too Large

    The requested URL’s length exceeds the capacity limit for this server.”.could you help me to resolve this.
    I also asked this at http://wordpress.org/support/topic/i-am-getting-an-error-when-trying-to-set-the-network-wide-rules?replies=3 .
    Could you help me to resolve this?

74. # 74 Asshu dit :
    le 31 July 2010 à 18:01 h

    @Y.Dubois

    I hope the problem would be solved in next version and it would be soon.

75. # 75 Asshu dit :
    le 3 August 2010 à 10:48 h

    @Y.Dubois

    I w’d like to know if the issue is fixed?
    http://wordpress.org/support/topic/i-am-getting-an-error-when-trying-to-set-the-network-wide-rules?replies=3 .

76. # 76 Y.Dubois dit :
    le 3 August 2010 à 12:41 h

    @Asshu

    this issue will be resolved in the next version of the plugin, but I cannot work on it in the next 2 weeks. So hang on a bit, or re-configure your web server settings as explained in the forum thread.

77. # 77 Asshu dit :
    le 17 August 2010 à 1:22 h

    Thanks for your reply !
    I will be waiting .

78. # 78 J dit :
    le 17 August 2010 à 20:44 h

    I have a version of this plugin which POSTs the entries. this will eliminate the URL too large bug.
    @Y.Dubois I never received that email from you. Let me know if you still need this version of the plugin which seems to work ok.

79. # 79 Y.Dubois dit :
    le 17 August 2010 à 20:47 h

    @J Yes, please! I will make it available as an alternative version for all, before including necessary changes to make it an option in a future release.

    You can find my e-mail address at the beginning of the main plugin file.

    Thanks.

80. # 80 mercedes dit :
    le 22 August 2010 à 8:49 h

    im kinda lost on how to use the settings ….is there anywhere that i can learn to know whats what?

81. # 81 Johan dit :
    le 22 August 2010 à 14:01 h

    Hi,

    Can you explain how can I do the following. I have 4 sites which should use 1 blog.
    Should I go to the backend of every site and configure YD Netword-wide options? Which options should be checked?

82. # 82 Melo dit :
    le 23 August 2010 à 20:57 h

    Bonjour,

    J’ai crée une plateforme multiblogs, et j’aimerais que les sous blogs gardent le même header et surtout la même sidebar que le blog principal, mais je ne sais pas quel parametres cocher.
    J’ai essayer différentes combinaisons mais rien a faire…

    Merci

83. # 83 Y.Dubois dit :
    le 23 August 2010 à 21:12 h

    @Melo :

    Peux-tu préciser la version de WordPress et le thème utilisé ?

84. # 84 Y.Dubois dit :
    le 23 August 2010 à 21:14 h

    @Mercedes: the settings depend on what plugins are installed on your system. There is no way and no place to know all possibly available settings. Just ask here, and maybe someone can help you for a particular setting or plugin.

85. # 85 Y.Dubois dit :
    le 23 August 2010 à 21:16 h

    @Johan

    Please read the installation instruction as explained in the doc. The plugin need only be installed on your ‘root’ blog to propagate chosen settings to all your sites. The options to be checked depend on what settings you want to propagate (or share) between all your blogs.

86. # 86 mercedes dit :
    le 24 August 2010 à 2:33 h

    so basically the setting make the plugins work on all of my sites……what if i want all the plugins to workon all my sites i only have 2 right now….does the theme have to be the same….am i right on how it works?

87. # 87 basim dit :
    le 24 August 2010 à 19:21 h

    hello
    I actually think I don’t understand what your plugin doing but
    what I get you can from it decide to active some plugin or all for some blog sites or all ?

    my question is can this plugin if I make new blog add X of categories and X of pages automatically for any new blog ?
    X = 1,2,3……..etc

    thank you so much

88. # 88 ovidiu dit :
    le 25 August 2010 à 4:35 h

    no sure if you follow the wordpress forums but I posted there http://wordpress.org/support/topic/plugin-yd-wpmu-site-wide-options-amazing-plugin

89. # 89 Y.Dubois dit :
    le 25 August 2010 à 11:02 h

    @Ovidiu:
    I officially do not follow the WordPress forums (no time to keep an eye here and there), so I prefer that all the questions are kept in the same place, so that everyone can benefit from the answers or give community support. And that place is here, as clearly indicated in the faq and plugin doc. If you please do not mind to copy/paste your question, I’ll be glad to answer it here.

90. # 90 Y.Dubois dit :
    le 25 August 2010 à 11:05 h

    @Basim: my plugin does not deal with categories nor content, those are completely separate concepts from options. My plugin does not activate other plugins on other blogs (use network-wide activation in WP for that, or maybe the Plugin Commander extension). My plugin only propagates other plugin SETTINGS or WordPress core SETTINGS (aka “options”).

91. # 91 Y.Dubois dit :
    le 25 August 2010 à 11:09 h

    @Mercedes: my plugin does not decide which plugin are activated on which sites. You can do that manually, or network-wide using WordPress. It can however synchronize the WIDGET settings on all sites: the same widgets can be automatically activated on all the sites. It would then be better to have the same theme everywhere but that is no formal requirements. You can have different themes on all your sites if you wish, themes are not directly connected to options. However, my plugin can propagate the same theme and same theme settings to all your sites if you wish.

92. # 92 ovidiu dit :
    le 25 August 2010 à 11:46 h

    I can gladly comply I haven’t done so straight away as some people hate double-postings. Besides, I have some “pre-sales” questions so I haven’t installed yet.

    I was wondering how this works, I mean lets say I replicate my akismet settings across all blogs, so that one API key works for all of them (I know you are not allowed) but will each blog admin still see the plugin options? If so he can change the settings there…

    Is there an option to hide certain options/settings if they get propagated across all blogs to prevent users from changing them?

    btw can I use the plugin to copy settings from any blog I chose or does it have ot run on the main blog? I’d love to create a new clean blog as a template blog without messing with the main blog…

93. # 93 Y.Dubois dit :
    le 25 August 2010 à 17:30 h

    @Ovidiu:

    1 – yes, you can replicate an Akismet key accross all blogs. This has been tested and technically works perfectly (whether officially allowed or not, that’s another issue).

    2 – The ability to show or hide specific plugin admin pages is not included in my plugin. This is dependent on specific third-party plugin implementations. Although it seems to me that such a “plugin settings hiding” plugin would be quite possible to develop, I would need some initial fundings to create it. So to answer your question, yes, each blog admin can mess up with the settings of their own blogs as it is. However, you can enforce the “autospreading” of the options in such a way that by re-setting that option on the main blog you will automatically overwrite any local setting of the same option. This policy can be enabled/disabled to your liking.

    3 – It would be rather simple to implement some extension to my plugin that would prevent sub-blog admins to change a “propagated setting” (ie they would still see it and be able to TRY to change it, but that just would not happen because the master setting would stay sticky anyway)

    4 – Regular users usually can’t change settings, only admins can (again, this depends on actual third-party plugin implementations) — which means that by carefully tailoring the rights you give to sub-blog users, it is possible to block them from modifying any option in the first place.

    5 – As it is, the plugin is designed to copy the master settings from the main blog only (this was the original spec from my client). However, it is quite easy to modify this to be able to change the master blog to any blog (this is indeed already a considered feature for a future version).

94. # 94 ovidiu dit :
    le 25 August 2010 à 17:36 h

    thanks a lot for the detailed answers. I will go ahead and give it a test run on a local installation. I asked all these questions to figure out the possible differences between you plugin and this one: http://premium.wpmudev.org/project/new-blog-template

    I know the other plugin is a paid plugin but I am a registered member so its really only about the different options.

95. # 95 Y.Dubois dit :
    le 25 August 2010 à 17:50 h

    @Ovidiu:
    From what I can tell, my plugin can probably do everything that new-blog-template does (except right now it only uses the master blog as a template); but in addition to that, it will maintain the master blog settings over time: if you change them, they can be automagically replicated on all sub-blogs. This is what it was meant for in the first place: it propagates any option change in real time to all sub-blogs. Only later on did it become a “free” competitor to the plugin you mentioned, when features were specifically added to automatically spread master options to new blogs, and to optionally disable the settings overwrite on existing blogs.

    I am not a member, so I could not test that other plugin thoroughly and can’t tell you in detail what the other differences would be.

96. # 96 ovidiu dit :
    le 25 August 2010 à 17:55 h

    thx a lot will give both a try.

97. # 97 ovidiu dit :
    le 26 August 2010 à 11:43 h

    would it be a lot of work to change the plugin so that I can i.e. set up a blog called template.mydomain.com and use that one as the general template blog? I really don’t want the master blog to be used as a template blog as it is set up pretty uniquely and I wouldn’t want other blogs to be modeled after it….

98. # 98 marikamitsos dit :
    le 26 August 2010 à 18:22 h

    Hello Dubois,
    Following up ovidiu’s suggestions….
    Having different general blogs like “basic subscribers blog”, “basic students blog”, “basic teachers blog” and having them applied on different groups would be amazing.
    Of cource that would mean that the other groups + the main blog (or whichever one chooses not to) should remain untouched.
    Just a thought….
    Thank you so much for the plugin and all the work

Envoyez votre réponse