Xedin Unknown

I would also like to know what the solution was, if any.

To upload, I go to the project, then click on a locale, then “Import Translations” at the bottom.

I did not check the POT file, but it was created by an automated tool. Regardless, one would think that the errors should tell what went wrong. This is the information I’m looking for.

erisal,

Unfortunately, we are unable to reproduce your issue. In order to address it, we would need a way to reproduce or at least witness it, so something like a screencast where we can see the problem could be very helpful. Please use the contact form from my previous reply to open a ticket in our premium support channel, an our engineers will look into it.

Hi erisal,

The domain staticxx.facebook.com is used by Facebook for cross-domain concerns, and therefore is not associated with a virus. Still, if this is a concern for you, could you please expand on the following, in order to give us more information to go on?

1. What do you mean by “there is access”? Access from where?
2. How have you determined that the WP RSS Aggregator – Excerpts & Thumbnails plug-in is responsible for this?

Please open a ticket by using this contact form.

Hi David,

And thank you for this report. Because we cannot test our products in all possible environments, feedback like yours is very valuable to us.

Unfortunately, at this time we do not have access to a comprehensive report of how our plugin behaves under high load and with your set of components. Therefore, I cannot really tell exactly whether or not the high number of “function calls” is a bad thing. I have been unable to find information on what this metric is and how it is gathered, in the New Relic documentation. WP RSS Aggregator is a far more complex product than Genesis, where there’s no dependency injection, no MVC, and which is almost completely procedural, with the exception of around 25 classes (that’s all I could find in the endless mixture of PHP and HTML) versus many dozens of classes in WP RSS Aggregator Core alone. If a function is considered by new relic to be either a procedural function or a class method, then the number of calls can easily grow dozens of times over what Genesis makes. After all, the Genesis theme has a total of slightly more than a 100 files, while WP RSS Aggregator Core has over 350 PHP files. I’m sure that you can see a correlation here.

Nevertheless, 100 times more sounds like alone, and if this worries you, we would be willing to investigate further, if you can provide access to the data and analysis results you used to assess the plugin. I would also highly suggest that you isolate the metrics for usage *during a typical request*, separately for the front-end and the back-end of your site.

I hope this helps.

Hi rklrkl!

We are happy to receive comments and suggestions from users and developers experienced with PHP or Linux, so thank you very much for your feedback!

The page to which my colleague had linked to earlier mentions multiple reasons for us raising the minimal requirements of PHP, with security fixes being only one of them. It may sound like this is the main one, but that is probably because this is what most of the other popular sources are talking about. If you look at the bottom part of that post, you will find “a word from our Lead Developer”; that’s me. In my allocution, I explain that newer PHP versions provide syntactic features that make programs more concise and therefore easier to read, maintain, and adapt. Truly, the introduction of closures in PHP 5.3 is a major breakthrough, and allows WordPress developers to avoid falling into callback hell by handling hooks where they need to be handled, not somewhere else, and without polluting the global namespace with endless functions. Together with the __invoke() magic method, this made WordPress hooks much more useful and usable, because it allows for a more structured approach to event handling. This is just an example of how new language features greatly influence the developers’ decisions to raise the minimal requirements; but at the same time, this is probably the main reason. And from what you wrote, it appears that you agree that the minimal requirements should be at least PHP 5.3; please correct me if I’m wrong.

Like you mentioned, RHEL operating systems and their derivatives including CentOS backport the most critical fixes to previous PHP versions. At the same time, this is policy of operating system families, not of PHP itself. This is why we cannot rely on what some OS maintainers do: because we cannot cater for all cases and environments where our software is used. The decision to require at least PHP 5.3.9 and not a lower 5.3.x version is mostly based on the fact that PHP 5.3.9 introduces a fix that is critical to some elements of our architecture. This fix allows the same method from multiple interfaces to be correctly interpreted in the implementing class, instead of throwing an error. Truly, re-declaring the same method with identical signature lower in the interface inheritance chain should seamlessly override the previous identical declaration. Thus, we are able to write code that is more semantically clear and natural. This is very important when writing large enterprise software, which our product aims to eventually be. We are currently adapting many useful and widely accepted standards into our codebase, and without this ability we would have to sacrifice some of those standards, or flexibility due to being unable to provide a padding between standard interfaces and our own standards.

The current trend is heading away from older PHP versions, and even though the minimal requirement for WordPress remains at PHP 5.2, the official stats indicate that the majority of people are running PHP 5.6, while the recommended version of PHP is at least 7.0. Being able to cater for 5.8% of users in our humble opinion does not justify losing the ability to improve our software for the benefit of the rest of the users. It is almost always advisable to run the latest patch version of your chosen version of PHP, which for PHP 5.3 is 5.3.29, and it would seem that it is up to the OS maintainers in this case to port the most critical fixes to that version. For a long time, the WordPress community had been hesitant to move forward from PHP 5.2. But if the developers do not write software for newer PHP versions, the hosting providers will never upgrade their environments, since there would seemingly not be a need to.

To conclude, we are sorry for the inconvenience caused by our minimal requirements. This was a carefully weighed decision made on solid grounds and for the benefit of the majority, and many more plugin developers made the same decision for similar reasons. Please don’t hesitate to contact us if you need any information about our software, or advice on running it in your environment. We hope to receive more helpful feedback from users like yourself, and promise to continue working hard to bring to you the most useful and architecturally sound solutions, while contributing to the community and standards, and drive global development forward.

• This reply was modified 8 years, 1 month ago by Xedin Unknown. Reason: typo
• This reply was modified 8 years, 1 month ago by Xedin Unknown.

Hi Sebastien,

And thank you for your report. This is a known issue, and we are working on a fix, which will be getting released not later than next week, along with a huge amount of other fixes and improvements. Please update frequently to receive all the latest features and fixes.

Meanwhile, you are seeing this error because your error reporting settings include E_NOTICE – possibly because you have WP_DEBUG and DISPLAY_ERRORS enabled. The notice is causing the “headers already sent” message, because a redirect is attempted during activation. Just a reminder that in production environments, notices should be turned off. With the notice gone, so would the “headers already sent” message.

Please let us know if you have any further questions or suggestions.

Hi websitehelperuk,

If I understood everything correctly, then the suggestion of my colleague Eric should prevent search engines from following, and therefore indexing, pages of individual Feed Item posts. If the search engines cannot index them, then these items will not appear in search results, and this would prevent visitors from landing on the new items that get imported after you apply the suggested option. For the feed items that are already indexed before you apply the “Set links as nofollow” option, your server rewrite rule should do the job of hiding the feed item pages from the visitors.

Does this solve your problem?

Brent,

We appreciate that you are concerned for the stability of your website. However, I must note that this is not a test. This release was made in order to update contributors and copyright information due to internal changes in our team, and as can be seen here does not contain any changes to the code at all, save for the version number in the constant value.

Please do drop us an email here with your system info. This could really help us understand the cause of this problem, and develop a solution.

Thank you for your patience.

Hi christopheran,

And thank you for using WP RSS Aggregator.

We’ve created a snippet for you that, if included with WordPress (perhaps in functions.php) will process all headings of all incoming items and transform them into a text-only version. This is a rough example, so please feel free to customize as needed.

Also please note that this will only work with Simple Feeds Bundle add-ons, and will not work if the Feed to Post add-on is installed.


if (true) {

if (!function_exists('my_normalize_rss_item_heading_chars')) {
function my_normalize_rss_item_heading_chars($text) {
// Replaces specifically the <| thing with a dash
$text = preg_replace('/[\x{25C4}]/u', '-', $text);
// Replaces all other "cool" chars with nothing
$text = preg_replace('/[^\x20-\x7E]/','', $text);
// Remove extra space around text
$text = trim($text);

return $text;
}
}

add_filter('wprss_populate_post_data', function($data, $item) {
/* @var $data array */
/* @var $item SimplePie_Item */

$data['post_title'] = my_normalize_rss_item_heading_chars($data['post_title']);

return $data;
});
}

jsafire,

As I explained earlier, when you rename a folder of a plugin that is active, and then access the site, that plugin gets de-activated. That is why the site goes up again – because the plugin, which causes the fatal error, is no longer active. So, if you would like to continue using the plugin afterwards, it must be activated again.

We are sorry to hear that some of the users of our plugins are experiencing issues while updating the core WP RSS Aggregator plugin. Unfortunately, we are still unable to reproduce this, as updates are happening normally for us, and all plugins stay active without errors of any kind. If you would like to help us find the cause of the issue, please contact us using the premium support channel, and make sure to attach the system info that is available on the RSS Aggregator > Debug page of the WordPress backend.

Brent,

In this comment, you mention that you’ve solved the problem by reverting to the previous version. However, I don’t believe that this was necessary.
Would you mind trying to manually trigger an update of the WP RSS Aggregator plugin? If you experience the same problem, please try following the instructions provided by our support staff, without uploading the old version. Either way, please let us know how it goes.

Hi all,

Sorry to hear that you are having trouble using our plugins.

The wprss_autoloader() function returns an instance of the autoloader class, which is responsible for loading classes, and is contained in the core WP RSS Aggregator add-on. The cause of the errors you are seeing is most likely that the core add-on is inactive. Please make sure it is active, and let us know if the symptoms persist.

Please be advised that the latest version of WP RSS Aggregator, 4.9.1, does not contain any changes to code at all, and therefore we’re pretty confident that nothing in this version could break anything. That said, it doesn’t mean that it’s impossible for the software to contain a bug from before somewhere, or that the issue is with the update, and not with the update process itself. If you are using premium add-ons, and are experiencing an issue, please contact us via our premium support channel.

Also, kindly note that when you rename a folder of an active plugin, that plugin becomes de-activated, which is a common way of re-gaining admin functionality in cases with fatal errors. Therefore, if you have re-named a folder of a WP RSS Aggregator add-on, that add-on may currently be inactive.

Hi sagetopia!

Currently there is no filter that would allow you to override this. However, you can achieve the result you have described by de-queuing the colorbox script, and the custom script that makes the links use colorbox. This is what worked for me:

add_action('wp_footer', function() {
wp_dequeue_script('jquery.colorbox-min');
wp_dequeue_script('wprss_custom');
});


Hi christopheran,

And thank you for your kind words. We work hard to provide effective tools for importing RSS/Atom feeds with maximum flexibility and reliability, and appreciate all reviews very much.

Below, I will try to address the points you brought forward:

1. Unfortunately, when using the Simple Bundle add-ons or just the core WP RSS Aggregator plugin alone, it is not possible to override specific parts of the display template, but only the entire template as a whole. This is problematic, because the template also contains the logic for retrieval of the relevant data.

   If you’re up for that, you would need to unhook the wprss_default_display_template() function from the wprss_display_template action, and hook in your own implementation.

   Alternatively, you could try adding CSS that will, in response to the <body> tag’s class that reflects the current page or post ID, show or hide some specific element of the list items, such as div.feed-author which contains the author information.

2. The HTML of the source link is exposed via the wprss_item_source_link filter, which receives that HTML as the one and only argument. You may try to change the link HTML via this filter, but of course the problem here is that it knows nothing about the item that is being displayed. You can try getting the ID of the current item with the get_the_ID() function.

   If that doesn’t work, you could try hooking into the wprss_after_feed_item_title action, which exposes the post ID of the current feed item as the 3rd parameter. This will not allow you to change the source link or text itself, but may allow you to output some extra HTML.

3. I’m not quite sure what you mean by that. Would you be able to provide a demonstration please?