attachments in WordPress Multisite

Since the warning is issued in a core file and not within the plugin, there might be some sort of incompatibility I’m not aware of, but it might come down to the implementation. Did you make the additional updates to your theme files to accommodate version 3?

Hello,
great addon, but I think the release of this totally rewritten code probably has been done a little to fast. However, I also deal with this problems, also a multisite.

The issue in the github bugtracker brings me the solution to prevent the query.php errors. (https://github.com/jchristopher/attachments/issues/32) To my opinion there is no need, to search for old attachments 1.x and attachments pro meta fields in the constructor, because you want the plugin to be a tool for developers and they will migrate when updating.

As a quick workaround everybody who has not made use of attachments pro in the past can manually set this value in wordpress’ database to prevent these query.php 1702 errors:

INSERT INTO wordpress.wp_options ( option_id, option_name, option_value, autoload )
VALUES ( NULL , 'attachments_pro_migrated', '1', 'no' )

If migration has not occured you can add this line after line 237 in class.migrate.attachments.php:
add_option( 'attachments_pro_migrated', true, '', 'no' );

For me this does work, I just comment here, because I hope this will help make it work for multisite out of the box in next version.

Hi Sebastian, I’ll have this issue resolved in the next version. I wouldn’t recommend anyone execute the above SQL.

This Warning has been suppressed in version 3.3.3, thanks for the help guys!

Hello,
I’ve updated plugin to 3.3.3 version but still querry.php warning appears, also tried SQL solution but it didn’t help either.
I use multisite maybe this is the cause.
I appreciate any help.

Ok, I also updated my multisite. Unfortunately it still causes the error in query.php. But for me the SQL insert still keep working as temporary fix.

@grzegorz.poplawski: Maybe you are using another table prefix like me (I am using ‘wp_’ in the example), so that the value can not be inserted properly? Otherwise, please verify first, that the error really is related to the source code as mentioned in the bugtracker by ‘thezuberat’.

Greets

I’ve done insert firstly to wp_options (warning stays), then to wp_2_options and both extecuted properly (checked table).
On my template and when i change it to pure Twenty Twelve warning still appears.

Very strange, in my testing everything was resolved but I’ll see what I can do to potentially recreate the issue again on my end.

I get the following on a new install of multisite if I network activate Attachments 3.3.3. No other plug-ins running:

Warning: Invalid argument supplied for foreach() in /home/xxxxxx/public_html/wp-includes/query.php on line 1702

Warning: Invalid argument supplied for foreach() in /home/xxxxxx/public_html/wp-includes/query.php on line 1702

Warning: Cannot modify header information - headers already sent by (output started at /home/xxxxxx/public_html/wp-includes/query.php:1702) in /home/xxxxxx/public_html/wp-includes/option.php on line 568

Warning: Cannot modify header information - headers already sent by (output started at /home/xxxxxx/public_html/wp-includes/query.php:1702) in /home/xxxxxx/public_html/wp-includes/option.php on line 569

Hey Jonathan,

great work, version 3.4 really fixes the query.php line 1702 bug. Just to complete this thread here, I want to provide the “undo” SQL query, if somebody used my workaround in the meantime.

Anybody out there, please do only use this, if you familar with mysql database syntax and know what you are doing, maybe have a look at the source code of attachments plugin before. Not that the “attachments_pro_migrated” normally is migration flag for setups, that used attachments 1.x pro plugins.

Probably table name “wp_options” has to be adjusted to the specific prefix and blog-id:

Main site, table prefix “wp_”:

DELETE FROM wordpress.wp_options
WHERE option_name = 'attachments_pro_migrated';

First subsite (blog id = 2):

DELETE FROM wordpress.wp_2_options
WHERE option_name = 'attachments_pro_migrated';

Nice work Jonathan, new update fixes this bug for me too.
Thank you.

Oh awesome, thank you! I didn’t even think to follow up with an ‘undo’ SQL statement but that’s super helpful, thanks a ton.