adrian

Hi @Christophe, I expect the issue is the missing ffmpeg on the server, although they are only used for making the video thumbnail/poster image, so I could probably do a class check and if it's not available, just not generate the image. Would this be acceptable for your needs? It would of course mean that the player would have blank black screen until it starts playing the video.

A quote in the conclusions section: "From the platform possibilities ProcessWire was best suited for the task due its developer centered approach by making the design part of the site the responsibility of the developers. This responsibility also brought the desired freedom to change the platform in the ways needed."

If you are using the automatic page name format option, then this module makes the name much more configurable: http://modules.processwire.com/modules/process-setup-page-name/

It really depends on how you can modify the third party booking software. Potentially you might be able to bootstrap PW into the software's processing script and save the info to PW fields using PW's API. You could use Profields table, or even just child pages - either can be populated via the API. We can help if we know more about how the booking software works.

The easiest way will be to buy the Pro forms module: http://modules.processwire.com/modules/form-builder/ Otherwise there is this free module: http://modules.processwire.com/modules/form-template-processor-mailer/ Or if you want complete control, start reading about processing forms via the API here: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ - with this you can do anything you want, but you'll have to get your hands dirty

I am not sure why it would have just stopped working, but it would be good if you could check to see if http://fma.loc/imagerenamer-copyInput is actually a valid link. Is there an index.php file or similar in there that the ajax url is supposed to be calling?

Yep - hover links are now default in the core although it can be disabled with a config setting: https://processwire.com/blog/posts/processwire-core-updates-2.5.26/#pagelist-now-supports-hover-actions They do work a little differently in the core than with that custom css. In the core you have to mouseover the Title of the page, but with that CSS you can mouseover anywhere on the line which I actually prefer.

Just in case someone else wants to do something like this, I just wanted to note that hooking before ProcessPageEdit::execute and foreaching through wire('breadcrumbs') works well. But for my particular needs I had problems with this approach and the Reno theme and so had to take another approach which worked: hooking after Process::breadcrumb Anyway, thought it might be useful info for others.

I think it should just be a matter of setting the page to hidden.

Have either of you tried 2.7.2 (current stable) or 2.7.3 (current dev)? If there is no improvement I would be curious what happens in PW 3.x but it still might be worth filing a Github issue to get the 2.x branch fixed.

This works for me: $user->of(false); $user->member->gender = 123; $user->member->save("gender"); EDIT: or for something even simpler using the new method introduced in 2.6.9 (https://processwire.com/blog/posts/processwire-2.6.9-core-updates-and-new-procache-version/#new-page-gt-setandsave-method): $user->member->setAndSave('gender', 123);

@tpr - I have just added an option to modify the breadcrumbs to remove pages that are outside the restricted branch. It seems to be working well here, but please let me know if you notice any problems. It's a new config setting option that needs to be checked. This example is for a user restricted to "Branch One" Modified Breadcrumb: Full / Unmodified Breadcrumb:

Just wanted to wrap this up and let folks know that the problem that @Christophe discovered has been fixed.

Hi @fablei - sorry for the rough start. Can you tell us if it makes a difference if you upload the image to the images field directly, rather than via the CKEditor upload? If that works ok, what about if you subsequently insert them into a CKEditor field and save the page again? Also, is there any difference if you upgrade to the latest stable 2.7.2, or the main dev version 2.7.3?

Just wanted to wrap this up and let folks know that the problem that @Christophe discovered with AdminRestrictBranch has been fixed.

Just wanted to wrap this up and let folks know that the problem that @Christophe discovered with AdminRestrictBranch has been fixed.

I see that PW is using the procedural date() in many places, rather than Datetime() which supports dates before 1901: http://stackoverflow.com/questions/18579567/change-the-format-of-dates-before-1900-without-using-explode I wonder if this should be a Github issue? EDIT: https://github.com/ryancramerdesign/ProcessWire/issues/1624

I am also one of those weirdos without a Facebook or Twitter account - I'd much rather read the PW forum or Github activity. That said I am often accused of staring at my wife's computer when she is looking at friend's photos on FB, so I guess I am a social media voyeur rather than exhibitionist.

Thanks for those settings - everything looks normal for using the "specified_parent" option. I wonder if the "Branch parent to restrict access to" setting on the user's setting page was set to something unexpected before you changed it to "home". Can you try resetting it to the desired branch to see if the problem returns? If it does return I wonder if you'd consider giving me access to the PW so I could investigate if there is some strange conflict?

@Christophe - sorry you are having trouble - I am curious about "all of a sudden" - I feel like something must have changed. I did add some new functionality yesterday, but this shouldn't be an issue - what version of the module are you running? Did you update PW or anything else between when it was working as expected and now? I don't really understand this - "restricted to everything" - does that mean the user is restricted from access to everything or that they can see everything when they shouldn't? I see in one of the threads you linked to that you are also using code in your ready.php - is the problem still there if you remove that code? @adrianmak - no it doesn't support multiple branches - it would have to be re-written completely for that and there are some core PW issues that would currently prevent this from working perfectly. It is also not really the goal of this module - it was designed for sites that have user specific parent branches - it is not really for hiding or restricting to a variety of sections. You might look at: https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/?p=84916 as a usable but not ideal solution. I still don't fully understand what is going on - does restricting to the homepage mean they now have access to everything, but before they weren't getting access to anything? I wonder if maybe there are some config setting being left in the system that are conflicting? Can you post the contents of the data field for module's settings - you'll need to get this via PHPMyAdmin or similar - modules table - grab the entry for this module - maybe there will be a clue in there?

@Gideon So and @regesh, I am pretty sure this is a bit of an abandoned experiment - it was never officially released in the modules directory, so I don't think it will see anymore updates. Also @kongondo has a new module that will do all this and lots more: https://processwire.com/talk/topic/11224-media-manager/

You may potentially want to revisit repeaters now that they are collapsed by default and AJAX loaded - there should be no more performance issues: https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/ Although to be honest I still think I would use pages for a staff directory because I like being able to have a direct URL to each staff member.

I know this is a little old, but perhaps this new module might help with the multilanguage issue: http://modules.processwire.com/modules/process-setup-page-name/ Have a read of this message in the support thread: https://processwire.com/talk/topic/8576-name-format-children/?p=110656 - maybe posting a followup there might also help to motivate kixe (the module author) to work on the multi-language stuff.

They don't really go together - ASM multi should be set to multi, but maybe I am misunderstanding. Anyway, glad it is working for you now.

In some cases it doesn't matter, and in some cases it does It depends on the scope and class context as to whether $this->user->name will work or not, but seems to have been common practice in various modules. With PW 3.x ramping up I would suggest reading this: https://processwire.com/blog/posts/processwire-2.6.21-upgrades-comments-more-on-pw-3.x/#more-updates-on-processwire-3.0 - scroll down a little to the "Multi-instance with 3rd party modules and PW 3.x" section where it explains what works where. Actually this is a good reminder for me to update my modules to use $this->wire()