Latest Release (V2.0.1)

Could you provide a screenshot or the raw code showing the issue with the Settings tab?
Could it be a side effect of some other plugin / or specialized admin theme?

This will help in identifying the problem, as it’s unusual for raw code to appear.
We would not publish the widget with such obvious flaw – it was tested across different themes and websites.

So, I took a backup, deactivated all plugins (except yours) & my theme, installed & activated default 2023 theme; no change in Settings. When I re-installed my backup, however, the Settings page is now fine!

What I would like clarification on though please is why you’re not using $wpdb->prepare for the SQL query that fetches the content for the Settings page.

Thanks.

Hi,

great that your issue with raw code has been fixed. Hope it will not appear again.

$wpdb->prepare is used when writing custom SQL queries to interact with the WP database.

When using WordPress’s built-in functions, like get_option and update_option, $wpdb->prepare is not needed as these functions handle the necessary preparations and sanitizations internally.

This piece of code which appears in at least 3 of the plugin’s files (eg: line 52 in weather-atlas/admin/weather-atlas.php) doesn’t use a WP wordpress function:-
$widget_options = $wpdb->get_results( "SELECT * FROM {$wpdb->options} WHERE option_name LIKE 'weather_atlas_widget_%'" );

Using $wpdb->prepare is a best practice when writing SQL queries in WordPress, especially when the query includes variables or user input. It’s a crucial step for preventing SQL injection attacks by ensuring that SQL statements are safely formatted. But,…
There are no external variables or user inputs directly incorporated into the query, which is why $wpdb->prepare wasn’t used.
The query is a static string, and the table name ($wpdb->options) is a property of the $wpdb object, which is considered safe.
If we were to include any variable or dynamic data in that query, then using $wpdb->prepare would be necessary.

for the peace of mind, we’ll incl. this in v.2.0.2

$prefix = 'weather_atlas_widget_';
$query = $wpdb->prepare( "SELECT * FROM {$wpdb->options} WHERE option_name LIKE %s", $prefix . '%' );
$widget_options = $wpdb->get_results( $query );

I’m having a similar issue, the shortcode wasn’t working properly and when I looked to settings I get this:

“; echo “

” . __( ‘Fair usage policy restricts widget instances to a maximum of 10. Please edit or delete existing widgets before adding new ones.’, ‘weather-atlas’ ) . “”; echo “

get_results( “SELECT * FROM {$wpdb->options} WHERE option_name LIKE ‘weather_atlas_widget_%'” ); // Unserialize and sort $widget_options by ‘widget_name’ usort( $widget_options, function( $a, $b ) { $a_data = unserialize( $a->option_value ); $b_data = unserialize( $b->option_value ); return strcmp( $a_data[ “widget_name” ], $b_data[ “widget_name” ] ); } ); foreach ( $widget_options as $option ) { $widget_data = maybe_unserialize( $option->option_value ); // Extract widget ID from the option name $widget_id = str_replace( “weather_atlas_widget_”, “”, $option->option_name ); $widget_name = isset( $widget_data[ ‘widget_name’ ] ) ? $widget_data[ ‘widget_name’ ] : ‘Weather Atlas Widget ‘ . $widget_id; // Generate edit link $edit_link = admin_url( ‘admin.php?page=weather-atlas-widget&edit_widget_id=’ . $widget_id ); // Generate delete link $delete_link = admin_url( ‘admin.php?page=weather-atlas&action=delete&widget_id=’ . $widget_id ); // Display edit and delete links echo “

“; echo do_shortcode( ‘[shortcode-weather-atlas selected_widget_id=’ . $widget_id . ‘]’ ); echo “”; echo “

“; echo “” . __( ‘Edit’ ) . ” ” . esc_html( $widget_name ) . “ “; echo “” . __( ‘Delete’ ) . ““; echo “”; echo “

“; } if ( count( $widget_options ) < 10 ) { // Link to add new echo “

“; echo “” . __( ‘Add New Location’, ‘weather-atlas’ ) . ““; echo “”; } else { echo “”; } ?>

Hi @joanlaura404,

We’re glad to inform you that version 2.0.2 of the Weather Atlas plugin has been released with an update that addresses the issue you. (the $wpdb->prepare method in our SQL queries as discussed in previous posts)

Please update to the latest v. 2.0.2 and let us know if this resolves the problem you were experiencing.

Your feedback is essential for us to ensure the best performance of our plugin.

Tnx,
The Weather Atlas Team

I updated, the widget is working, it was showing hourly where it wasn’t before so I added hourly=0 to the shortcode to remove as we just need the current temp. The plugin dashboard however still shows this text (pasting in case there is a difference from above)

“; echo “

” . __( ‘Fair usage policy restricts widget instances to a maximum of 10. Please edit or delete existing widgets before adding new ones.’, ‘weather-atlas’ ) . “”; echo “

prepare( “SELECT * FROM {$wpdb->options} WHERE option_name LIKE %s”, $prefix . ‘%’ ); $widget_options = $wpdb->get_results( $query ); // Unserialize and sort $widget_options by ‘widget_name’ usort( $widget_options, function( $a, $b ) { $a_data = unserialize( $a->option_value ); $b_data = unserialize( $b->option_value ); return strcmp( $a_data[ “widget_name” ], $b_data[ “widget_name” ] ); } ); foreach ( $widget_options as $option ) { $widget_data = maybe_unserialize( $option->option_value ); // Extract widget ID from the option name $widget_id = str_replace( “weather_atlas_widget_”, “”, $option->option_name ); $widget_name = isset( $widget_data[ ‘widget_name’ ] ) ? $widget_data[ ‘widget_name’ ] : ‘Weather Atlas Widget ‘ . $widget_id; // Generate edit link $edit_link = admin_url( ‘admin.php?page=weather-atlas-widget&edit_widget_id=’ . $widget_id ); // Generate delete link $delete_link = admin_url( ‘admin.php?page=weather-atlas&action=delete&widget_id=’ . $widget_id ); // Display edit and delete links echo “

“; echo do_shortcode( ‘[shortcode-weather-atlas selected_widget_id=’ . $widget_id . ‘]’ ); echo “”; echo “

“; echo “” . __( ‘Edit’ ) . ” ” . esc_html( $widget_name ) . “ “; echo “” . __( ‘Delete’ ) . ““; echo “”; echo “

“; } if ( count( $widget_options ) < 10 ) { // Link to add new echo “

“; echo “” . __( ‘Add New Location’, ‘weather-atlas’ ) . ““; echo “”; } else { echo “”; } ?>

We’ve been working hard to detect and fix the problem, but we can’t seem to replicate it.
New widgets are working fine, so maybe the issue is with the older widgets while thay were imported.
But even this doesn’t fully make sense because old widgets are showing up correctly on the front pages.
It’s quite confusing.

Can you try deleting the versions of widgets that were imported to see if that helps?

Just updated to the 2.0.2 version and have the same issue as reported. Mine was an upgrade from the previous version. Plugin works just find but the settings blow up as described above.

• This reply was modified 12 months ago by demoman2k10.

Thanks for altering the SQL queries. My settings page is still OK now since I de-activated and re-activated other plugins & theme. Don’t know why that would make a difference. I’ve not had a problem with the shortcode output not showing.

Hello to all,

Thank you again for reporting the issue with the Weather Atlas Widget v2.0.2. We’ve thoroughly tested various scenarios, installing previous versions of the plugin and updating to version 2.x.x. We also experimented with various configurations and shortcode implementations, trying different combinations of single (‘) and double (“) quotes, among other variations, in an effort to replicate the issue you’re experiencing. Despite these efforts, we were unable to reproduce the problem.

It seems this issue might be specific to updates from older versions, but the exact cause is unclear. Interestingly, deactivating and reactivating other plugins/themes temporarily fixes the issue. This hints at potential conflicts or interdependencies with certain plugins or themes.

We’ll keep trying to find the cause, but since its a problem to replicate the issue it’s a problem. To aid us in this process, it would be extremely helpful if you could share more specific information, such as:

1. The theme you are using
2. A complete list of plugins currently active on your site
3. Any special settings or customizations you had applied to the Weather Atlas Widget before the update

Additionally, it’s important to note that we have not removed the old settings from the previous version. These settings are still stored in your WordPress database, under the wp_options table with the option name widget_weather_atlas. The data format typically looks like a:2:{s:12:"_multiwidget";i:1;i:3....". Analyzing these old settings, especially if you had multiple weather widgets configured, might be key to resolving this issue.

If you could review these old settings and share any details you think might be relevant, it would greatly assist our efforts to identify and fix the problem.

So, I’ve checked the content of the options field and mine looks like this:-

a:1:{s:12:"_multiwidget";i:1;}

I’m not displaying mine as a widget, I’ve just put the shortcode in the editor in WP Admin.

It occurred to me that there might be an incomplete div tag somewhere so I had a look at your PHP files. One thing struck me: on most of them your HTML is preceded by a closing PHP tag and then you PHP echo values within your HTML. For example, like this:-

<label for="text_color"><?php _e( 'Text Color', 'weather-atlas' ); ?></label>

In the file weather-atlas.php, however, you echo your HTML within your PHP. For example, like this:-


echo "<div class='weather_demo_wrapper'>";
echo do_shortcode( '[shortcode-weather-atlas selected_widget_id=' . $widget_id . ']' );
echo "</div>";


Personally, I like a consistent approach but it’s not my plugin and it shouldn’t affect the output. What is probably more of a problem though is that the opening PHP tag on Line 49 is incomplete; it reads <? instead of <?php.

Might I suggest you scrutinise your code thoroughly in case there are other instances of incomplete PHP tags and you might find a “<” or “>” is missing somewhere too.

Hello again,

The a:1:{s:12:"_multiwidget";i:1;} in the options field indicates that no specific widget instances are configured, which aligns with your use of a shortcode in the WP Admin editor.
– tested that variant, and upgraded from 1.2.1 – still can not replicate the error ??

Regarding the mixed PHP/HTML coding styles in the files – while this shouldn’t affect functionality, we aim for consistent coding practices for better readability and maintenance. Will be sorted (eventually).

<? instead of <?php
Thank you for pointing out this oversight – this may be crucial for the widget’s reliability.
Due to the dependency on server configuration and potential compatibility issues, it is highly recommended usage of the <?php opening tag for PHP code, especially in distributed scripts.
(here might lie the issue)
The problem you highlighted with the short PHP opening tag has been immediately fixed in newest v. 2.0.3

That’s good news

I’m closing this ticket now; if anyone else continues to have any issues, please open a fresh ticket.