• Resolved cwfaraday

    (@cwfaraday)


    I’m trying to test the custom function capability, but I can’t get them to execute. Even though the constant APL_ALLOW_PHP is properly defined as true in wp-config.php, I keep on getting the error message.

    Elsewhere “echo APL_ALLOW_PHP” returns 1, so I can’t understand what’s wrong.

    Thanks for looking into it!

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Author EkoJR

    (@ekojr)

    Hmm, are you 100% sure you have this in your wp-config.php config file?

    define('APL_ALLOW_PHP', true);

    Also be sure you have the most recent version ( I’ll be pushing another here soon ). I did make some recent changes and updated the documentation. So, the current method may not be the same as the old; the old function also had a major bug that was fixed.

    I suppose the last method to troubleshoot this would be to remove the checks all together in class-apl-shortcode.php, but it was added as an additional safe guard.

    Plugin Author EkoJR

    (@ekojr)

    Disregard that last, this was a bug.

    JUST recently Fixed [php_function] Undefined Constant with an update I’m about to push (APL 0.3.5). I thought it was the last update I had added it.

    I decided to push an early update mainly because of the File Structure & Class/Object changes that I prefer to do before 0.4 (which has a database update). In your case, it is a good thing I’m pushing an early update.

    Keep a look out for an update for the next few hours, and hope to hear positive results ??

    Thread Starter cwfaraday

    (@cwfaraday)

    I updated to 0.3.6 and the lists aren’t showing up, neither in the settings page’s preview nor on the actual pages with the shortcode.

    Thread Starter cwfaraday

    (@cwfaraday)

    I went back to 0.3.4 and removed the constant check: it seems to be working.

    However, this won’t work:
    [php_function name="testFunction1234" param="[post_meta name='wp_review_total']"]

    Catchable fatal error: Object of class WP_Post could not be converted to string in /var/www/dev.local/wp-content/plugins/_mg_plugin/_mg_plugin.php on line 82

    I guess post metas aren’t retrieved?

    Thread Starter cwfaraday

    (@cwfaraday)

    Removing $this->_post as the first parameter for call_user_func in function php_function($atts) did the trick, at least temporarily…

    Plugin Author EkoJR

    (@ekojr)

    I may have to run this through a few tests, and like you say, removing $this->_post is only temporary.

    Currently doing some much needed organizing and cleaning after the recent code push. So it may be a little while. However, I do suspect these…

    1. [post_meta] is being passed to another ‘internal’shortcode – This is likely NOT the issue, but “internal shortcodes” was designed to be encapsulated, and only work within the Internal Shortcodes Class. However, I designed everything to be loaded before the [php_function].
    2. The WP_Post has nothing to reference to in that instance while in another function/shortcode that also uses $wp_query. Which is still odd considering there should still be a valid $post. I’ll need to confirm this theory first.
    3. Removing $this->_post prevents the defaults, and fixes the issue, but is still being stored in APL_Internal_Shortcodes::_replace(). This is rather interesting, but falls under #2. However, in one of the 0.3.X versions, I did remove WP_Post from being passed, but quickly added it back in to prevent issues with other sites.
    4. It is an issue with the WP Review Plugin code when getting the meta data; which seems like a function rather than a value to reference to, but I still want to confirm this scenario ( personally haven’t had much need for meta data…yet ). Please note: I might not be able to help if it is a Premium Plugin/Feature.

    Hope this helps some, but I at least wanted to add my thoughts on it for later if needed. I’ll need some time until I can reproduce this, and it may even end up on the GitHub Ticket list.

    • This reply was modified 7 years, 6 months ago by EkoJR. Reason: Converted Markdown to HTML
    Thread Starter cwfaraday

    (@cwfaraday)

    I guess it’s simpler than that: in my function I din’t expect the first parameter passed by call_user_func to be $this->_post, so making space for it resolved the issue.

    Unless it’s something that one is supposed to know (I’m not a pro), I’d only suggest to add it to he wiki.

    Thanks for all your work, this plugin is by far my favourite!

    Plugin Author EkoJR

    (@ekojr)

    You’re absolutely right too! I have a draft written on how to use it, but still have yet to posted it on the Wiki, and I probably should sooner rather than later; considering I even forgot mentioning passing the $post, and the error it throws.

    I suppose my delay on the Wiki is mainly due to the amount of work that has been going on in the backend of APL, and the amount of changes that could take place. Plus, I have been trying to force myself to be more user-friendly on explaining, but with APL being somewhat of a Web Design tool. It makes it a little bit harder to explain through an additional layer.

    I’ve also been thinking about re-coding the php_function, or alt, to make the $post an optional variable.

    Plugin Author EkoJR

    (@ekojr)

    I finally got around to adding a Tutorial for this feature. I mainly wanted to wait until I felt comfortable with 0.4’s stability before I added more documentation. So far I’ll have to re-document the Admin UI, but here’s the tutorial on How to use the [php_function] shortcode.

    Please let me know what you think.

    Hi,

    Very helpfull. That confirm my understanding of this function.

    Thanks

    Plugin Author EkoJR

    (@ekojr)

    Ah, good to hear ??

    Hi,

    As said in an other topic, please add an example with a param.

    Thanks

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Error: add define(“APL_ALLOW_PHP”, true); even when present’ is closed to new replies.