tombenner

Thanks, Robert! Using robert.peake did the trick.

Hi,

Currently, the best way to do this is to use the mvc_render_to_string() function. There isn’t support yet for using a controller’s action in this context, but you can easily access models and data using mvc_model(). Here’s an example:
https://wpmvc.org/documentation/88/mvc_render_to_string/

There are other mvc_*() functions that may be useful to you in code that’s outside of the WP MVC context, too:
https://wpmvc.org/documentation/74/functions/

Best,
Tom

Hi,

Have you set up Pretty Permalinks and verified that they’re working for posts? That’s the most common cause for 404 errors like this. If those are working and you’re still getting that error, let me know.

(This is mentioned in the installation instructions but not in the tutorial; I might add it to the tutorial, as it’s not always obvious.)

Best,
Tom

You’ll want to use the load_model() or load_models() methods for this; here’s how to use it:
https://wpmvc.org/documentation/91/load_model/
https://wpmvc.org/documentation/92/load_models/

(Sorry, I had somehow overlooked including these in the documentation, but they’re in there now.)

HapiDjus, apologies for the huge delay; I had been a bit swamped. If you’re still looking to get this working, could you try adding print_r($argv); at the top of wp-mvc/core/wpmvc.php, run ./wpmvc generate plugin mynewplugin, and let me know what the output is?

jevets, thanks for catching this. AFAICT, there isn’t a way for wpmvc to determine where wp-config.php is if it’s in a non-standard location, so I’ve added a way to set a custom path to the WordPress directory in an environment variable. See “Setting a custom path to the WordPress directory” here:
https://wpmvc.org/documentation/90/using-the-code-generation-utility/

For example, you would run something like this before running any wpmvc commands:

export WPMVC_WORDPRESS_PATH="/my/path/to/webroot/wordpress/"

That should work, but let me know if not.

To avoid the need to write SQL for this, I’ve added a function (in 1.1.4) called mvc_model, which lets you instantiate an MVC model anywhere in WP (e.g. in the theme). You can call find() on it to get objects and then iterate through them to create the HTML to pass into the wp_nav_menu_items filter:

$venue_model = mvc_model('Venue');
$venues = $venue_model->find(array('limit' => 5));
$items_html = '';
foreach ($venues as $venue) {
    $items_html .= '<li><a href="'.mvc_public_url(array('controller' => 'venues', 'id' => $venue->id)).'">'.$venue.'</a></li>';
}

I’ve also added another function called mvc_render_to_string() which lets you render a view to a string. The example in the documentation should show how to use it, but I haven’t thoroughly tested it yet.

If you have any questions about this or anything else, definitely just shoot me a line.

Best,
Tom

Hm, you might check to see if register_argc_argv is disabled, which would prevent arguments from being passed when calling a PHP script. Try running the following command:

php -i | grep register_argc_argv

If the output says that register_argc_argv is Off, that’s probably the issue, and you’ll want to set that to be On in your php.ini (you can find the location of this with php -i | grep "php.ini"), if you have privileges to modify that. Let me know what you find, and I’ll see if there’s a way around this without having to have register_argc_argv on.

Hi,

Thanks for letting me know about this; there was indeed a bug here, but it has been fixed in 1.1.2, which I’ve just pushed out. The passing of the params in above route should work as expected now, but if it doesn’t, definitely just let me know.

If there’s anything else that you happen to catch, don’t hesitate to shoot me a line.

Best,
Tom

The issue with User Avatar avatars not being deleted should be resolved in the current version (1.2.1), but let me know if it’s still not working for you.

I’m unfortunately too swamped to add support for more plugins’ profile fields, but if you can find how to make one of them work, definitely let me know, and perhaps shoot me a pull request on GitHub if you’d like to contribute your code to the plugin. You’d probably want to find the function(s) in the avatar plugin that handle updating the avatar and call them during either the feu_before_update_user action or the feu_after_update_user action. Any CSS and JS that the plugin includes would also need to be included in the settings view.

The feu_display_settings_page()/set_custom_feu_views_directory() issue is now resolved in 1.2.1. I’m not sure why get_theme_root().'/'.get_template() wasn’t working in set_custom_feu_views_directory() in your case, but I’ve replaced it with get_template_directory() in case that helps.

I’ve also added a feu_settings_update_url_params filter that will let you set additional URL params after a settings update (there’s an example in example_hooks.php).

Nice, thanks, Dominor; I’ve updated the version number accordingly.

Thanks, this is helpful feedback.

I’ve added a function in the recent update to version 1.2 that will output the settings page:

feu_display_settings_page();

If anyone would like to modify what shows up on the settings page, the current most straightforward method would be to copy and paste the contents of views/settings.php into your template and modify them as need be (see Dominor’s 4-step directions here).

The cleaner, slightly more advanced way would be to set a custom FEU views directory as described in example_hooks.php (see set_custom_feu_views_directory()) and modify the settings.php within that directory.

I may add some arguments to feu_display_settings_page() that allow for modification of what shows up there when I find some time.

Thanks again,
Tom

I’ve added a function to simplify this a bit in the recent update to version 1.2. In the “Test FEU” template above, instead of copying the big block of PHP code that begins with “global $feu”, you can just put this:

feu_display_settings_page();

Btw, many thanks for helping with these questions, Dominor; I’ve been swamped as usual.

Hi Markus,

I’ve just posted a new version (1.2) that should fix this. Thanks for catchin’ it!

(Not sure why it still says “Download Version 1.0”, but 1.2 will be downloaded.)

Best,
Tom

Hi,

I can definitely understand your frustration; I’ve added more documentation in example_hooks.php and functions.php to make things a little more transparent. However, I’m unfortunately externally swamped with work and don’t really have time to implement lots of UI-based settings that you can manipulate without touching any PHP. Customizing views and integrating views within a theme is really best done by using PHP and not through abstracted settings, anyway, IMHO (this is exactly how BuddyPress does it, for example).

If you have any questions about how to do something specific, though, definitely just let me know.

Best,
Tom