painfreecomputing

I’m just another user, but it’s clear that this is not a feature of wp-cycle. I was just about to suggest this as a future enhancement. The author’s FAQ lists the following “future plans”, but does not list the ability to use multiple instances.

• Add ability to reorder the images
• Add new effects to the slideshow
• Add the ability to override settings by using function arguments: <?php wp_cycle(‘rotate=1&effect=fade&img_width=300&img_height=200&div=slideshow’); ?>
• Possibly add widget support so that you can put a slideshow in a widget area

Jack

Never mind, I finally found the “Arbitrary” widget in the widget area and the rest was easy.

Jack

Problem solved. It was not a NextGen Gallery issue after all. The problem was due to a procedural error on my part. Between the time I backed up my original Nextgen Gallery data tables, and the time I installed on the new server, there was a plugin update. The new server got the NEW NextGen Gallery, which had a new column for “slug”. Since I overwrote this table when I imported the old data, that column was missing. This caused all subsequent database writes to fail, since they tried to write to include a slug for the album. There were a couple of other column constraints that had changed with the new plugin, too (NOT NULL was added). In my “test” installation, I manually created the additional “slug” column, and modified the two other columns so that the data table structure is identical to the new version…problem solved. I then took the three sql statements and put them into one .sql file and imported that into my “production” database. Again, problem solved.

I doubt anyone will have the problem I had, but here’s a good hint for general troubleshooting, and it’s how I found the problem: Turn on debugging and check the output. In wp-config.php, add the following line:
define('WP_DEBUG', true);
(remove it or comment it out after you’re finished debugging.

Jack

Hmmm. I have a lot of galleries and photos, but I can back up the tables and then try a clean install. If it works, I’ll import the data back in.

Thanks.
Jack

This is NOT even close to a wordpress issue.

Jack

Always search before posting…this one was quite recent.

Jack

I’ve found a workaround.

In the past, I used the Advanced Category Excluder plugin. It has its own “ACE Recent Posts” widget. This widget DOES keep the sticky posts at the top of the list. I installed it and it works without even activating the whole plugin. I just activated the Advanced Category Excluder widget set that is included, and put the “ACE Recent Posts” widget into my sidebar.

It’s quite possible that I was using that widget all along.

Jack

I posted here rather than the BFA forum, because the problem a) began when I moved to PHP 5.3.2, and b) it persists even with the default WordPress theme, with no plugins enabled.

However…I see that I need to clarify my issue, and perhaps it’s actually working as designed.

I have a fourth WordPress site on the same server. It’s brand new, with no plugins ever installed. This one, unlike the others, does not use a static page as the start page. It uses the most recent posts. The “sticky” posts do indeed stick. So it’s working, in that regard. The issue is, they don’t stick to the top of the “Recent Posts” menu. I’m almost 100% sure they used to stick there, too. Am I mistaken?

Jack

This “host” is a brand spankin’ new RHEL virtual machine and it has no old versions of PHP.

If I post a URL, you won’t know which post should be sticky.

It’s not a critical issue, so I think I’ll hold off and see if someone has actually figured this specific problem out, rather than doing more experiments. Surely I’m not the only one who’s seen this issue. I’ve duplicated it on three different WordPress sites that I built (all on the same host).

Thanks.
Jack

I think you might be able to control that in htaccess/php.ini, https://davidwalsh.name/php-values-htaccess

Not sure what you mean by that. I looked at your link, but I don’t see how it applies.

Have you tried:

– deactivating all plugins to see if this resolves the problem. If this works, re-activate the plugins one by one until you find the problematic plugin(s).

Good suggestion, but my first step when everything broke was to do a clean install, then add each plugin and its data (via command-line sql statements). That’s how I discovered which plugins were causing my site to fail (specifically, EVERY link produced a 404). Once I modified the functions, it worked–except for the sticky feature.

However, I disabled all plugins, and still the same problem–the sticky is not sticky.

– resetting the plugins folder by FTP or PhpMyAdmin. Sometimes, an apparently inactive plugin can still cause problems.

I don’t understand this one. What is “resetting” a folder? Permissions? Or do you mean the plugin data that’s stored even after you deactivate the plugin?

Thanks.
Jack

Well, I’m just going to do this by letting the user select from multiple forms via a dropdown menu (the main menu will not be a Contact Form).

Jack

Can you be a little more specific? Perhaps a sample of the code?

Actually, I may be looking for something a little more involved that what you’ve done. I’ve created the dropdown for the recipient, but that’s not exactly what I need. I’d like for the user to select from a Subject dropdown (I’ve done that) and I’d like the email recipient to be determined by the subject that was chosen. For example:
Subject “Website Access” goes to recipient1
Subject “Site Feedback” goes to recipient2
Subject “Feature Request” goes to recipient3
…

(All via one dropdown)

I could do this on a Joomla plugin, but I’m not sure this functionality exists in this WordPress plugin.

Thanks.
Jack