adrian

Why don't you try it and see what happens

You could maybe hook into PageRender::renderPage ? Take a look at the ForcePasswordChange module: https://github.com/adrianbj/PasswordForceChange/blob/master/PasswordForceChange.module#L57 and the method that is called: https://github.com/adrianbj/PasswordForceChange/blob/master/PasswordForceChange.module#L87 Taking that approach you can prevent them from viewing the restricted pages even if they are logged in.

What's the missing 10% ? Did the field pairings work as expected? Is there anything I can do to make BCE work better for your needs?

There is a setting for the Forgot Password module that lets you set the from email address.

@sappel - maybe I am not getting exactly what you want, but something like this should do the trick. $products = $pages->get("/products/")->children(); foreach($products as $product) [ echo $product->sidebar; }

Because when you manually unzip a project from Github it has "-master" or "-dev" etc in the folder name. You don't want this in PW, so you either need to manually remove this, or install automatically from the zip itself. If you install manually and then run the Upgrade module, it is adding the version without the -master so you end up with two versions. Does that explain it?

The -master issue is probably just a result of you manually unzipping and FTP'ing the module folder. If you use the modules page to install, either via class name, github url, or from your hdd you won't see these. PS Glad you are now seeing 0.1.5!

The module includes the latest core version of Tracy with that commit you referenced, so not sure why manual updating would have helped. Also note that I make a couple of manual modifications to the core to make editor links reference the main template file, rather than the compiled version, so you will have problems there. Did you try the stable version - that should really speed things up - seems to me that the new src/Tracy/assets/Bar/loader.phtml approach used by master is the source of the slowdown. Any chance you can give me access to this server - I am baffled as to why the latest commit to the module stopped by debugger bar from working again. PS For reference, here is my Issue report to the Tracy core: https://github.com/nette/tracy/issues/157 - hopefully they'll be able to figure out the slowdown problem with the master (dev) version.

Any chance you can PM me with access to this server, or is it a local dev setup? Why do you have multiple copies of so many of your modules? You should delete all the -master versions. Also, when installing modules I would recommend the core method of installing by class name - it looks to me like you installed several modules manually and then used the upgrades modules to upgrade them - hence the extra copies. You must have a 0.1.4 version of PageProtector somewhere in your system.

@tpr - back to your slow loading issue - I don't think it is https related. I am getting TTFB for 3 scripts files at about 10s for all. This only happens for the master (dev) version of the Tracy core which is loaded automatically if you have php 5.4.4+. If I manually force the stable version to load, then it loads very quickly. Weird thing is that I have two PW installs on my local dev setup and one is fast with the master version and one is slow. So I need to investigate further but thought you'd like an update on that. Until I get it sorted properly (maybe needs a fix in the Tracy core), you can always force the stable version of Tracy here: https://github.com/adrianbj/TracyDebugger/blob/master/TracyDebugger.module#L102 - you'll want to change the two lines after that. Hope that helps in the meantime.

Back to the Tracy logs directory/files permission issue - I have just added a check that prevents the error and warns if the directory is not readable. Still don't know why it ended up that way for you guys, but at least now Tracy will still work and you'll get a message about why it can't show the Tracy log file entries.

Interesting that it's now working fine - it does suggest that there was initially an access permission problem - either "execute" on the tracy folder or "read" on the file. Any chance that might have happened when copying a site from one server to another? I wonder if I should add a check on the folder and chmod it to the default directory value for PW if it doesn't already match? I haven't tested on https yet - can you narrow it down to one particular panel, or does it cause the slowdown even if all custom panels are disabled?

Sure, although if you have lots of separate pages protected you might want to copy the module settings from the modules DB table so you can add them back in without having to re-create them all after the reinstall. Are you having issues with updating any other modules, or just this one?

Yeah sorry about that - I read your request in a hurry and saw "So not including any hashes" and extrapolated the "not" to the url segments etc.

$page->httpUrl

I am not sure what to suggest. Can you take a look in the .module file and make sure it says: "15" as the version number? If it does, then can you let me know if the new functionality is available despite the version number in the module config showing 14?

Thanks both of you - so it really does seem to be a permissions issue. Given @netcarver's report about the file permissions being correct, I was wondering if there was maybe an issue with the folder permissions - I was initially thinking it might be a lack of execute permission on the created "/site/assets/logs/tracy/" folder, rather than the log files themselves, but then I don't see how the file could be written in the first place unless the permissions have changed since the file was initially written. So I am actually not getting anywhere I do have a couple of tweaks coming (one which might fix the issue where @netcarver still had the problem even when the Tracy logs panel was disabled), but I don't think anything will fix this properly yet. What do you both have your $config->chmodDir set to? If you change this (increase permissions), delete the /logs/tracy folder and send something to the log again, does it work now?

Thanks for helping to debug. I wonder if this is the same issue that @tpr is having? I can replicate what I think is the same problem if the log file doesn't have read permission. Can you please check to see if it works with 0777 (just a temp change to debug)? I am using wireMkdir to create the tracy logs folder though so I feel like it should be correct. Also wondering if maybe there is some issue with the content of the log file - does it return with a simple text entry? If the permissions change doesn't fix things, any chance you could PM me a copy of the log file you deleted (if you still have backup of it) so I can test?

@tpr - those suggestion were kinda only relevant before I committed the update. @netcarver - looking forward to seeing those errors - thanks. I can't imagine that either of you guys are running less than php 5.4, but could you confirm that https://github.com/adrianbj/TracyDebugger/blob/master/TracyDebugger.module#L102 is validating to true and therefore including the master (dev) version of Tracy? While you are there I guess it would be good to see if instead the stable version works. Thanks again.

This sounds like a modules caching issue or maybe a FileCompiler caching issue? Can you try a Modules > Refresh? I'd be surprised if that doesn't work, but if not, maybe clear your FileCompiler cache as well?

I decided to update the Tracy core now anyway - please let me know if the latest version fixes it for you.

I was just writing this when your new post came through If you haven't already started the version checking, perhaps first try this latest change to the Tracy core which looks like it might possibly be the issue: https://github.com/nette/tracy/commit/5ecd8e7b011580f44191be7ef40487e8b09a2555#diff-36dcf2914a684042e3718478c5c6faa9 You can just manually add that "isset" to the src/Tracy/assets/Bar/loader.phtml file. Also, perhaps it might be worth trying the stable branch of Tracy - remember I recently (v1.2.6) added the master (dev) branch if you have php 5.4. Easiest way to do this is probably to edit this line: https://github.com/adrianbj/TracyDebugger/blob/f8d4ca6c1f8afe31331bdaa94a89b50874371586/TracyDebugger.module#L103 so that it loads stable anyway. So could you please check both those approaches in that order please. Hopefully it's the first one.

@tpr - sorry to hear that - definitely weird as it's working fine here. Obviously hard for me to debug without any errors. It would be awesome if you could figure out the exact commit that breaks it for you. You can download the zip from Github for each commit quite easily. That will take you to a link like this: https://github.com/adrianbj/TracyDebugger/tree/0b9696921bcd33ac18460b5501f13c8784b4188b From each of these you can use the normal "Download Zip" button. Sorry this could be quite time consuming for you. You probably do this already, but in this situation I always grab the middle commit between the one I know is working and the one that isn't. If that works then split the difference to the latest and if it doesn't split the difference to the oldest and so on - that should reduce the effort significantly. Thanks for taking this on!

If you're using that module of mine, you currently need ffmpeg and php-ffmpeg installed to generate poster/thumbnail images. I am planning on adding the option to manually add an image at some point, but it will be much easier if your host has ffmpeg available. As for autoplay, just edit the the play code in the module's config setting. Although I should probably add the ability to pass various options like autoplay via play() If you want to go back to the plain html video tag, it shouldn't be hard to get the path correct. I am not sure this makes sense yet because as far as I know, you need to provide mp4 and webm versions for all modern browser support, whereas with my module and its use of mediaelementjs you can just supply an mp4. On further reading, I am actually not sure of the support for mp4 anymore. It seems contradictory between http://caniuse.com/#feat=mpeg4 and http://mediaelementjs.com/ Are the videos being uploaded via a files field? or manually uploaded to site/templates/video/ ? <?php echo $config->urls->templates; ?>video/voorstelling_orgelpijpjes_2016.mp4 If so, then it should work fine. What is the URL that is shown when you view source?

Does this help: https://processwire.com/talk/topic/8553-how-to-increment-file-download-counter/