Jesse Smith (Mardesco)

Hi @leisuremike, I realize it’s been some time since you posted this. I just discovered that I am experiencing the same issue on one of my sites. The “Event Organiser” plugin stopped displaying a calendar on my events page. Instead, the loading icon just spins and spins forever. When I changed the shortcode from [eo_fullcalendar] to the widget version, [eo_calendar], it displays a minimized version; but the mini version lacks the same functionality, and the link to next month is broken.

Did you ever find a solution for this problem? Any insights you can provide would be very helpful. Thanks!

Hi @timelymanner1, I am having a similar issue on my site. Just as you describe in this thread, the payment goes through successfully, but the customer receives an error message saying that it did not. This thread does not contain the solution, as it appears the conversation moved into private messages. Would it be possible to share the solution you eventually decided on? It would be very helpful if you can. Thanks so much! Have a great day.

Happy to do it man! Thanks for your work on this plugin. Have a great day.
-Jesse

The updates in question are now live and available for download from the WordPress theme repository. This includes a fix to the native WordPress Customizer integration. I hope you will have a blissful experience with the “Bliss” theme by Mardesco. Have a great day.

minor correction, “Text Widget” was the saved title of a text widget in my test environment…

Hi @carrietv Caroline, I hope you are doing well. I apologize that Mardesco does not actively monitor this forum and your question has not been answered yet. It’s been quite some time so I hope you’ve been able to find a satisfactory solution in the meantime. But I thought I would attempt to address your question.

The green heading and separator bar in the “Boldly Go Green” theme are only applied to certain widgets by default, unless the widget was saved with a “Title” field. For example, the styles are applied to the text widget, archives widget, and pages widget (even if the Title is blank); but by default there is no header or separator bar for the calendar widget or the search widget. The default widget heading is a fancy bonus feature, because Justin Tadlock, the creator of parent theme “Stargazer,” built in those default headings for some of the most commonly used widgets. For example, if you create a text widget with no “Title” field, the widget will be displayed with a title that says, “Text Widget.” Other widget types are commonly used without any heading, so he did not include a default header for the “calendar” or “search” widgets. (The same is true of widgets for custom post types and third-party plugins: they will not have a default heading.) But I tested this just now and it looks like the solution is:

From the Appearance > Widgets menu, if you add a Title to your widget (the field is blank by default) and hit Save: then when you go back and view the site again, the widget heading and divider bar should appear between those widgets. ??

I hope that helps! Apologies for the severely delayed response. Have a great day.
-Jesse

• This reply was modified 8 years, 1 month ago by Jesse Smith (Mardesco).

Hi @rohineemo I hope you are doing well. Mardesco does not actively monitor this forum, so I’m sorry your question was not answered. I see you have marked this as resolved in the meantime, so hopefully you have sorted this out or found an alternative solution and I hope that’s working well for you.

Generally, removing the author link requires modifying the theme template files. “Boldly Go Green” is already a child theme of “Stargazer” so modifying the output would require you to create your own child theme based on this one.

To remove the author link from the post, you would make a copy of the parent theme file found in /wp-content/themes/stargazer/content/content.php and place that file within your own child theme (still using the structure /wp-content/themes/your-child-theme/content/content.php) Then you just delete the line within the “entry-byline” div where it outputs the_author_posts_link() Note that this means deleting two different lines, because the same function is called on both sides of an “if/else” block.

Apologies for the late response. Have a great day.

I’m noticing something similar. At first I thought it was because I had set up custom user roles, but then I noticed that the “view statistics” link in the left-hand sidebar menu works fine! The difference that I see is, the link in the dashboard points to index.php?page=wps_visitors_page&etc=etc but the sidebar link points to admin.php?page=wps_visitors_page – for what that’s worth.

I’m loving this plugin! Hopefully this minor quirk can be easily resolved.

Thank you for suggesting a fix. Saw a lot of one-star reviews that the plugin is broken. Your comment is helpful.

Thank you, Mark Chouinard, for pointing this out.

I came on to this forum to report the issue but see that it has been raised before. On the plugin settings page in WP 4.4, this plugin raises a “notice” level PHP error:

Notice: Use of undefined constant GENESIS_SLIDER_SETTINGS_FIELD - assumed 'GENESIS_SLIDER_SETTINGS_FIELD' in /path/to/plugins/genesis-responsive-slider/admin.php on line 350

Looks like the best solution for now is to manually edit the plugin’s source code to add “_RESPONSIVE” to the named constants where they’re called, as Mark showed. Is there a better way to ask the plugin devs to include this fix in a future update? Thanks!

Hey dev.lounger, I had another thought about this scenario. If you don’t need a whole development site, but just a page or two to demonstrate a theme in progress, you might be able to use a theme switcher plugin in conjunction with an access restriction plugin. In the theme switcher plugin’s settings, specify that your test page uses the work-in-progress theme, and all other pages use the main active theme. Then limit your test page so only users with appropriate permissions can see it. There are lots of plugins available for these purposes, a quick search will reveal the most highly rated. Wish I’d thought of this sooner… Hope it helps.

I’m in agreement with WPyogi that if a local test environment doesn’t work for your client, then installing a copy of the site in a subdirectory is the best solution. The landing page idea is a great suggestion, as well. The clone can be a completely separate, second installation of WP. Best of luck!

The easiest way to test a WordPress theme in development is to create a copy of the site on your local testing computer. Many Linux and Mac installations come with Apache/MySQL/PHP pre-installed; otherwise you can use something like MAMP, XAMPP, WAMP, AMPPS, etc. to set up a compatible server environment on your own computer. After you get WordPress running, you can export a backup of your content from your live site, and install it into the test environment. This way if something goes wrong, the live installation will not be affected; and you don’t expose untested code to the wild Internet. When the new theme is ready, you just .zip it and install it in the usual way. Have fun!

A new version of the “Bliss” theme is now available for download from the WordPress repository. Please update to the latest version. I think this addresses all related issues. If you do have more questions, please feel welcome to open another thread. Thank you!

I do have a little good news on this question. Based on a recent experience with a client’s low-cost, well-known shared hosting provider who I won’t name, the file ssv3_payload_extractor_somerandomstring.php may be employed by the host’s third-party installer service during the process of installing WordPress itself. Yes, those third-party service providers will bundle your install with plugins that you’d probably want to delete immediately… but even as cynical as I am, I find it difficult to believe they would ship an installation that’s actually compromised by default.

I recently found a message about this file in my client’s error log, which was alarming and led me to this thread; but looking at the timestamp, I don’t believe WP had been installed long enough for anyone to launch an attack against it. That’s why I think this file is used by the third party service to install WordPress.

As to the OP’s essential question, multisite doesn’t work well on these low-cost shared servers, as I have previously been told by Ipstenu in another thread. ?? I would recommend a more robust system, such as VPS hosting.