Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Cannot be enabled because of fatal error

aeryaery ✭✭✭
edited January 2013 in Vanilla 2.0 - 2.8

For my site http://forum.gtricks.com runninr vanilla 2.0.18.4 it says when enabling,

Parse error:  syntax error, unexpected T_STATIC, expecting T_STRING or T_VARIABLE or '

Huge thanks @BusinessDad for making this plugin :)

There was an error rendering this rich post.

Comments

  • edited January 2013

    Make sure you are using PHP 5.3+. That error usually occurs with PHP 5.2, which is no longer supported.

  • aeryaery ✭✭✭

    it means I cant use this plugin on my shared hosting

    There was an error rendering this rich post.

  • You can ask your provider to enable PHP 5.3 (it's quite common, over 4 years old). Supporting PHP 5.2 would require to rewrite of part of the plugin.

  • This is the error that I'm getting:

    Parse error: syntax error, unexpected T_STATIC, expecting T_STRING or T_VARIABLE or '
    in /home/thriveym/public_html/ao/forum/plugins/PostScheduler/install/plugin.schema.php on line 242

  • Send a ticket to my hosting, will post back

  • @businessdad said:
    You can ask your provider to enable PHP 5.3 (it's quite common, over 4 years old). Supporting PHP 5.2 would require to rewrite of part of the plugin.

    I'm using 5.3.20 on my end. Anything else I should check into?

  • Hum. After some digging, it seems that I was running 5.3.17, despite what my host said. I updated to 5.3.20 and the plugin enables fine.

    But it "looks" like it's posting the discussion. The only visually different thing within my current theme is a small yellow area, as noted here: http://d.pr/i/Vm3G

    I noticed in the plugin settings, that discussions will appear as posted if you're using an admin account. But even when I log in with my dummy account, it still shows.

    Is there something I need to modify with my user permissions?

    Is the time localized? So 6pm is really 6pm?

  • Usually the time is your server time, which would be set to where the server is located. If the server's physical location is in your timezone then 6pm would be 6pm. I'm not sure what settings are available for this plugin, but it would be nice if it came with a time offset to set a proper time zone.

  • edited January 2013

    To clarify:

    • Some classes use late static binding, which works only from PHP 5.3+. It may be that some PHP versions have some bugs and don't interpret that properly, it's not unheard of.
    • The "yellow bar" is a message telling that discussion has been scheduled at a later time. I didn't test the UI with any theme other than the default, therefore it might require CSS adjustments.
    • An explanation of who can see what are in Plugin's settings page.
    • Any time will be taken as being in Vanilla's configured time zone.
    • Plugin has been tested on Vanilla 2
      0.8.14, it won't work on 2.1.
  • When I go to edit a post, the time looks like this: http://d.pr/i/fjJC And I'm unable to post without clearing out that box. Not a big deal, but I thought I'd post that feedback.

    What specific elements on the CSS do I need to look at? I'm using @aery Nebula.

  • @businessdad said:

    • An explanation of who can see what are in Plugin's settings page.

    This: Administrators and Users with proper permissions can always see all discussions, at any time. What permissions do I need to edit to let my users not see them? Is there a way to make them only visible by Admins?

  • @peripatew I don't normally provide free support for free plugins, however, to answer your questions:

    • You can't save a post without clearing the "Schedule Post" because the timestamp is improperly formatted. It must be in YYYY-MM-DD HH:MM format, currently there is no support for date localisation (that's why I added the DateTimePicker, which should sort things by itself).
      It may be possible that Vanilla automatically fills the field using the local date format, i.e. M-D-Y, which would not work properly.

    • CSS classes are in postscheduler.css file, in plugin's folder. I can't tell what adjustments should be made, as I don't know Nebula theme.

    • Without configuring anything, scheduled Posts should be hidden from all Users except Admins. Filtering is done at a query level, therefore scheduled Posts should not even be returned from the database. This is the case on my tests systems, it may be that, for some reasons, the queries on your configuration are not modified correctly and always return all the results. You might try having a look at the queries that are run when you open the page by using the Debugger plugin, or by adding a var_dump() before the Discussions are retrieved.
  • @businessdad said:
    peripatew I don't normally provide free support for free plugins, however, to answer your questions:

    Gotcha, I was just providing feedback as someone who's using/testing the plugin.

    • You can't save a post without clearing the "Schedule Post" because the timestamp is improperly formatted. It must be in YYYY-MM-DD HH:MM format, currently there is no support for date localisation (that's why I added the DateTimePicker, which should sort things by itself).

    Makes sense.

    It may be possible that Vanilla automatically fills the field using the local date format, i.e. M-D-Y, which would not work properly.

    • CSS classes are in postscheduler.css file, in plugin's folder. I can't tell what adjustments should be made, as I don't know Nebula theme.

    I'll take a look around and see what I can figure out, that's for the file reference.

    • Without configuring anything, scheduled Posts should be hidden from all Users except Admins. Filtering is done at a query level, therefore scheduled Posts should not even be returned from the database. This is the case on my tests systems, it may be that, for some reasons, the queries on your configuration are not modified correctly and always return all the results. You might try having a look at the queries that are run when you open the page by using the Debugger plugin, or by adding a var_dump() before the Discussions are retrieved.

    Thanks, I'll look into this as well, and testing with different user accounts.

Sign In or Register to comment.