I adopted Userhomepage plugin and just published a new version

geekitude

Hi everyone!

I adopted Userhomepage plugin and just published a new version :-D
I thought it would be a good idea to create a thread here for potential discussions rather than on it's wiki page :-p

michaelsy

geekitude I thought it would be a good idea to create a thread here for potential discussions rather than on it's wiki page :-p

I don't think it's a good idea to deal with all issues for a plugin in a single thread. Reason: A forum should not only help the individual questioners, but should also and above all help those who are looking for solutions for which answers already exist. However, this possibility is significantly hindered if several issues are dealt with in a single thread.

- Michael Sy.

geekitude

Just discovered and corrected a bug when the path to old template is manually emptied before saving options (the path DOKU_INC exists but, of course, doesn't content the template source file).

Sorry for the inconvinience. :)

marphod

I'm sure I did something fairly brain-dead when setting options for userhomepage, but I did something that meant whenever I logged in, I got stuck in a redirect loop attempting to access my user page.

I had set my template path to data/pages/users, and then copied the defaults from lib/plugins/userhomepage/lang/en to that directory.

If I created the file (username.txt) manually, I would get an edit page instead of the reload loop. There is an error 'Copy error (lib/plugins/userhomepage/lang/en/userhomepage_public.default > data/pages/user/userhomepage_public.txt)' (which doesn't make much sense, as the datestamp on the defeault page is 30 Sept, and the copy is 6 Oct).

I get the same error if I delete the default files from data/pages/user, and the redirect loop happens if I delete the data/pages/user directory

my settings are:
plugin»userhomepage»create_private_ns: <unchecked>
plugin»userhomepage»use_name_string: unchecked
plugin»userhomepage»use_start_page: unchecked
plugin»userhomepage»users_namespace: user
plugin»userhomepage»group_by_name: <unchecked>
plugin»userhomepage»edit_before_create: <unchecked>
plugin»userhomepage»acl_all_private: none
plugin»userhomepage»acl_user_private: None
plugin»userhomepage»create_public_page: <Checked>
plugin»userhomepage»public_pages_ns: user
plugin»userhomepage»acl_all_public: Read
plugin»userhomepage»acl_user_public: Read
plugin»userhomepage»templates_path: data/pages/user
plugin»userhomepage»templatepath: <emptystring>
plugin»userhomepage»acl_all_templates: Read
plugin»userhomepage»acl_user_templates: Read

geekitude

I had set my template path to data/pages/users, and then copied the defaults from lib/plugins/userhomepage/lang/en to that directory.

The plugin copies it's included template to correct place, don't manually copy a file.

.../...
plugin»userhomepage»templatepath: <emptystring>
.../...

That setting might cause a problem if it is empty but it should have been corrected have you emptied it manually?
EDIT I made a few tests with an empty string for this setting and it's not the source of the problem (at least if your Userhomepage plugin is up to date)...

Have you checked for Userhomepage updates?
If your install is up to date, try to manually set this to ~~lib/plugins/userhomepage/_template.txt (without double quotes) or~~ the path to your old template if I understood correctly (it will not be harmed, only used as source instead of plugin's localized template).

geekitude

There is an error 'Copy error (lib/plugins/userhomepage/lang/en/userhomepage_public.default > data/pages/user/userhomepage_public.txt)' (which doesn't make much sense, as the datestamp on the defeault page is 30 Sept, and the copy is 6 Oct).

I don't get what you mean about the datestamp, there shouldn't be a copy yet...

If the file data/pages/user/userhomepage_public.txt doesn't exist, the plugin tries to create it from it's localized template. Is there any ACL or other security that could block this process? If so, remove those securites (ACL is automatically managed by the plugin).

Normally, you would let the plugin create it's template then edit it to your likings.

marphod

geekitude wrote That setting might cause a problem if it is empty but it should have been corrected have you emptied it manually?

Uh, yeah.
The comment is "Template path from version 3.0.4. If this file exists, it will be used as default source for new private namespace start page template (clear the path if you don't want to)."

As I just did a clean install of userhomepages, I didn't have a path from 3.0.4, so I cleared the line.

I don't get what you mean about the datestamp, there shouldn't be a copy yet...

The documentation seemed to imply I should copy it by hand. I deleted it, regardless.

Looking at apache2's error.log, I see

[Tue Oct 07 17:43:15.475084 2014] [:error] [pid 7977] [client 192.168.253.98:41908] PHP Warning:  copy(/etc/dokuwiki/../data/pages/users/userhomepage_public.txt): failed to open stream: No such file or directory

Why on earth is DOKU_INC set to '/etc/dokuwiki/' It should be '/var/lib/dokuwiki/inc'

geekitude

I will try to clarify those points in the documentation page...

All paths are based on DOKU_INC and DOKU_CONF constants wich are defined by DokuWiki so I don't get where the problem comes from. I'll try to find if I can reproduce this.

Is it a fresh wiki install?

EDIT
Can you add this line:
msg('DOKU_INC: '.DOKU_INC.' / DOKU_CONF: '.DOKU_CONF, 0);
Anywhere after a <?php tag either in plugin's action.php or one of your templates' php files (for exemple with DokuWiki template, inside "breadcrumbs" div of tpl_header.php. I know it's a bit strange and the result will probably not be pretty but it's just to check the values of those constants).

marphod

... Crap. Long post got eaten by Xwindows being slow to update focus. Yay.

Long story short:; from action.php:function redirect()

                lock($this->public_page);
                saveWikiText($this->public_page,$this->applyTemplate('public'),'Automatically created');
                unlock($this->public_page);
error_log('Attempted to create: ' . $this->public_page );
error_log( page_exists($this->public_page )? 'Success.' : 'Failure' );
error_log( 'Page attempted to create: ' .  wikiFN($this->public_page) );

Reports the right file path but failure to create the file.

Changing the last line of the block to:

$created['public'] = page_exists($this->public_page);

fixes the infinite loop, but doesn't leave me with any more information why the file save failed. (The Directory in question is owned by www-data.www-data (the apache user and apache group), and has perms 0771, as does every directory down to the doc root.)

geekitude

Hi

Sorry for late answer...

Thanks for sharing your result, I'll look at this closely to see if I will include your change :)
The file creation problem is also a mystery to me when I see the ownership and permissions on your folder.

Sorry for all that...

EDIT
change added to code (as well as same modification for private page creation)

melat0nin

Is it possible to disable the ability for users to edit their homepages? I'd like to use it more as an automatically-created area for personalised content for the user, rather than a place for them to make changes.

I tried playing with the ACLs and altered /conf/acl.auth.php but when creating a new user it always reverts back.

Many thanks :)

PS thanks for this great plugin!

geekitude

Hi melat0nin.

If you change acl_user_private plugin's option to Read, the rights should be set to Read instead of Edit (don't give higher rights to ALL with acl_all_private because it would probable have unwanted effect). You can also set them to 'No automatic ACL' and set your own ACL rules (I suggest using ACL config page rather than editing /conf/acl.auth.php file though).

Let me know if you have any problem with this.

PS: thanks for the positive feedback ;-)

melat0nin

Thanks for the quick reply!

I tried changing acl_user_private to "no automatic ACL" but the relevant entry in the ACL page (clients:%USER%:*) still defaults to "Delete". I even tried deleting that entry, thinking the user group would apply (which doesn't permit any editing) but it then re-appeared! Changing it to Read didn't work either. I might reinstall the plugin and set these options first before creating any new users, to see if that helps.

geekitude

Give me 24h to make a few tests. Maybe the option doesn't work as intended.

melat0nin

geekitude wrote Give me 24h to make a few tests. Maybe the option doesn't work as intended.

Thank you! :)

(for reference -- I uninstalled the plugin then re-installed, and that didn't help)

geekitude

The "No automatic ACL" options are not taken care of in code. New release to fix that this week end. Sorry for the trouble.

geekitude

Double checked everything and ACL works as intended (including "No automatic ACL"), we just have very different points of view :-D

Made a new release with a new option "no_acl".
Enable it and save options then clean all existing ACL rules that you don't want, they won't come back (at least they shouldn't :-p).

melat0nin

geekitude:1417764879 wrote The "No automatic ACL" options are not taken care of in code. New release to fix that this week end. Sorry for the trouble.

Works perfectly now, thank you! :)

dsalamos

Can i use a link for directing to each user homepage?

example
http://www.dokuwiki.org/doku.php?do=userhomepage
which redirect to the current login users home page?

geekitude

Hi

Can you explain a bit more what you would like to do?

If you mean to provide a link to each user to his own private namespace or public page, it can only be done by editing your template and using userhomepage's helper (see Helper section of plugin page: https://www.dokuwiki.org/plugin:userhomepage).

geekitude

Hi everyone

2015-02-01's version introduced a crucial change in ACL process to reduce the amount of IO operations on acl.auth.php file and hopefully get rid of a bug that corrupted it from time to time.

Every one would be well advised to update ;-)

Global DokuWiki Links