Forum Replies Created

Viewing 15 replies - 16 through 30 (of 74 total)
  • Excellent news. I was also looking for this facility. Looking forward to 2.0.1.

    @gresakg

    So can’t they simply issue a version 4.0.2 that will deal with the migration propperly??

    Possibly, I don’t know. But the issue is not a code error really, just a problem caused by reverting to the older version. So easy to fix I see no need for another version update personally.

    I did that and it still does not work.
    The table with images is missing, there’s just the backup.

    I don’t think the plugin uses an images table now. Previously that table (on my install at least) contained only links to the main media storage. So now they link directly without the table. I have only two tables (plus the three backup old tables): _hugeit_slider_slide and _hugeit_slider_slider.
    Have your old three tables had names altered to add “_backup” to the end of their names? If so, then yes the migration did work, so perhaps you have a different issue?

    Do you perhaps have a caching issue? Try clearing browser cache etc. (just guessing).

    I expect after the weekend HugeIt support will be able to assist you. I found them very good to deal with.

    • This reply was modified 7 years, 11 months ago by kiwi3685.

    @v2006 and others…..

    I was having exactly the same problem. I upgraded to 4.0.0 and it failed. So I removed it and reloaded 3.2.3 which worked OK.
    When 4.0.1 came I removed 3.2.3 again and installed 4.0.1. That failed. So I again went back to 3.2.3.and requested help from HugeIT.

    But now I have seen the comment on here from @theDavies: “But before i need to force the wp_option with option_name row = ‘hugeit_slider_version’ to 3.2.3 for force the migration, after that, i updated again to the 4.0.1 and it’s all working.

    That is the answer! Go to the table wt_options, find the row containing ‘hugeit_slider_version’. Even though you are running 3.2.3 it will say 4.0.1. (because of your earlier failed upgrade). Edit that back to 3.2.3. Now do a normal plugin update to 4.0.1. I think you will then find that your old slides will be correctly migrated and 4.0.1 will work. It did for me anyway. ??

    So the problem is understandable. Reverting to an old version does not change the stored version number. But if the version number is already 4.0.1, migration is not triggered!

    Sadly, no. 4.0.1 does not make a difference.

    I may be confusing issues by adding my issue to this thread though. Perhaps I shoulld have posted a new topic.

    I see NO error messages (I have checked server logs). Simply, the existing sliders are no longer visible either in config or front end.

    Thanks. I have now downloaded the github master version. But it does not fix the problem – at least not the one I am having.

    As stated above, following testing yesterday I do not believe the PHP version is causing the problem.

    After installing 4.0.0 my sliders are not displayed in the config page, but they do still exist in the database (thank goodness!).

    Reverting to the previous version of slider fixes the issue.

    PHP still at 7.0.14.

    Unless you include 7.0.14 in “old versions of PHP” I don’t think that is the problem.

    I was using PHP 5.6.29 and had the problem after upgrading slider to 4.0.0, so reverted to Slider 3.2.3.
    I then upgraded to PHP 7.0.14; upgraded Slider again to 4.0.0 and the same problem appeared.

    I am now back to Slider 3.2.3 on PHP 7.0.14, and that is working fine.

    I am happy to run any tests that might help. Email: admin @kiwitrees.net. Slider is on my front page at https://www.kiwitrees.net

    Thread Starter kiwi3685

    (@kiwi3685)

    EDIT: Sorry, error in my first post. I found that line in Eonet.php not bootstrap.php. But it doesn’t matter, as it didn’t solve anything.

    I have now downloaded and put the missing set of fontawesome files into the plugin’s font/ directory. Hopefully that will stop the continual 404 errors.

    Now checked again with latest update to TML. No change. A number of issues appear related to registrations:

    1 – If error made on register form the red error field shows but it doesn’t contain any text explaining the problem (in this case it was using an email address already used).
    2 – Once registration is accepted the user appears in WP with status “pending”, but neither the user nor admin (me) receive any emails about the registration (all spam folders checked). I have set up custom emails in TML for these.
    3 – If I go to WP users and “approve” this user the status still remains as “pending” (i.e. doesn’t change), but the user does now receive an email confirming the accepted moderated registration.
    4 – Despite receiving that email the user still cannot login as the status is still “pending”.

    Thanks Jeff. I’ll have to try and remember to check for new registrations regularly until you have chance to confirm / fix 4.7.0 compatibility.

    If it helps I can say that apart from this issue TML seems to work perfectly in 4.7.0.

    No suggestion, but I am having a similar problem. Main difference is that for me new users can’t login, I don’t get an admin notification, and clicking “Approve” in the users list doesn’t change their status. To approve I have to actually edit their profile and change the status.

    I am also using BBPress, so that might be the issue (?), but I have also just updated WP to 4.7.0, so could that be the problem?

    • This reply was modified 8 years, 2 months ago by kiwi3685.

    I have the same issue. I want to exclude site admin downloads from appearing in counts, and ideally from inclusion on the download log table as well.
    Barry, your suggestion doesn’t really help, not me at least. Blacklisting my own IP prevents me from downloading completely. I want to be able to download, but have the count / log entry excluded.

    Where in the code is it supposed to be excluded already? When logged in my site role is administrator, but my user name is not. Could that be the problem?

    Thread Starter kiwi3685

    (@kiwi3685)

    Steve
    Thanks for your candid response. I do understand the problems you face, and did recognise that in my original post. Thanks also for posting the latest update to the code.

    I accept there have been plenty of updates, but that doesn’t, in my opinion, replace the need for active support.

    I have a very strong view, and no offence intended, that plugins should not be made or kept available if it is not possible to provide timely support, or at least prompt responses to questions.

    I know of a number of users of PVC for whom your latest update will be a great relief. But for myself I have taken on-board your very reasonable admission that “we have no time to do support on this or any of our Free plugins” and so have deleted it and moved to an alternative.

    Thread Starter kiwi3685

    (@kiwi3685)

    Well, a week later and no response.

    Front page here now down to “1 of 16 support threads in the last two months have been resolved.”, so I guess the answer to my question is self-evident….

    So sad. It was a nice tool. RIP.

    Yes, I agree. I’ve just edited a page and found exactly the same problem. VERY annoying!

    Thread Starter kiwi3685

    (@kiwi3685)

    Thanks Yannick.

    1.3.9 is a great improvement. Very happy to donate now as well. ??

Viewing 15 replies - 16 through 30 (of 74 total)