-
Posts
10,902 -
Joined
-
Last visited
-
Days Won
349
Everything posted by adrian
-
The "http" may be optionally prepended to any property accessed from $config->urls (including those you add yourself). https://github.com/processwire/processwire/blob/57b297fd1d828961b20ef29782012f75957d6886/wire/core/Paths.php#L49
-
@MilenKo - take a look at the "Jumplinks" section of the Hanna Code docs: https://modules.processwire.com/modules/process-hanna-code/ That is what Ryan uses for the ProcessWire blog. I think that is what you are looking to do.
- 14 replies
-
- 1
-
- table of content
- anchor
-
(and 1 more)
Tagged with:
-
Ok, new version committed. I am now forcing more complex password generation. Using the settings from the "pass" field just weren't working well - often not complex enough for the complexity validation, but should be good now.
-
Actually, I think there is a bigger issue at hand - setting the password generator to less than 8 characters results in "too weak" from the PW password validation, so I am going to force the number of characters higher for the automatic generation. After all, this is only meant to be a temporary password so probably no real need to worry because users will be copying/pasting anyway. I'll commit an update shortly. Hopefully this will deal with your issue anyway, although it would still be nice to know why you are getting "1".
-
Hi @jmartsch - I can't seem to reproduce this - it always returns the correct value from the "pass" field's settings. I tried an API send and a Re-send message and they both returned 10 correctly. In my case it is set to 10. Any chance your pass field is set to 1, or it's not named "pass". What happens if you do: d($fields->get('pass')->minlength); in the Tracy Console panel?
-
@FrancisChung - I agree, although I would go with JSON over XML given the choice.
-
No problem. I have a solution in place on your site, but I need to test a little more before releasing, so I would appreciate it if you could keep my account active for a while still. Take a look though - now you'll finally see what the Captain Hook panel is all about
-
Thanks - I have figured out the issue - it's to do with the path of your site, which starts with: /home/.sites/ which that strpos($path, '/.') === false is catching. I'll get a fix out shortly, although I have to leave in a few minutes, so it might be better if I don't rush and leave it till later today or tomorrow. Thanks again for access to your site - we could have gone around in circles for hours otherwise
-
@Juergen - do you have a live somewhere that is showing this problem that you might be able to give me access to? BTW, commenting out like that will mean result in a weird: if(!$dir->isDir() === false) which isn't what we want. So try removing this in its entirety: && strpos($path, '/.') === false Can you try putting: bd($path); just inside the foreach loop - above the if() You will need the Dumps Recorder panel for this - the main Dumps panel will miss it because the Captain Hook panel does it's scanning before the regular debug bar panels are loaded. PS - You will need to clear that cache again - actually I forgot that a simple way to do that is a Modules > Refresh
-
Ok thanks - can you please go back and check the things I mentioned in this post: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=154591 and the following one about the Windows path issue.
-
A CSV parser will be no use for an XML feed - I was just responding to @FrancisChung's comments about CSV not handing certain things. That's good news for sure - that should make things more manageable.
-
Ok, so please delete the Captain Hook cache from the database caches table. That will trigger it to rescan all your files again. If that doesn't work, we'll need to go back to that $paths issue which I think might still be a problem - I get the feeling that maybe that $iter foreach loop has nothing to loop.
-
I wasn't suggesting that there shouldn't be anything to show, but rather maybe there is an issue with them not being populated. Actually maybe it is related to the $paths not defined issue you were having - maybe the Captain Hook cache is not properly populated. That's why I need to know if there is anything under each file, eg in this screenshot I have opened up the Field.php file. By the way, hooks you are calling in ready.php aren't relevant - Captain Hook shows hooks that are available in the core, not hooks that have been triggered - for that, take a look at the "Hooks Triggered" section in the Debug Mode panel - this can be very handy to test if you hook is working.
-
Sorry I just noticed this - glad other panel's toggles are working, but it would help to know whether the individual toggles on the Captain Hook panel are working. It contains a list of all the files that have hooks. You should be able to click on each file and see a table of hooks within that file. We need to know that they're there because maybe that is the issue with the Toggle All - maybe there is nothing to show?
-
Maybe you could try disabling that for a test? If that doesn't help, I might need you to debug that toggleHooks() function in CaptainHookPanel.php to see where it's failing. Anyone else out there have any problems with the Toggle All button not working?
-
Do each of the files toggle correctly when you click on one separately? I just tested on all my browsers and had no problems. I am wondering if maybe there is some JS on the frontend of your site that is conflicting. If you're not already, can you please test on the backend of the site?
-
Another weird one That's obviously all JS - what browser are you using? Any browser console errors reported?
-
Thanks - that is what I thought. Weird though that it's not causing problems for anyone else I'll push an update in a minute.
-
Maybe it's: strpos($path, '/.') failing on Windows?
-
Well in that case can I please ask if you could check where things are failing. Start with checking if the "if" statement on line 35 ever validates. The maybe the value of $iter before the foreach. Then go back and check $root which is defined in the GenerateHTML.php file. Thanks for helping with this.
-
I am getting a little OT, but it's possible to support commas and complex data types in CSV with a proper CSV parser. PHP's native ones are not great. I make use of https://github.com/parsecsv/parsecsv-for-php in a couple of my modules. It's an older library that doesn't appear to be maintained anymore. I think there might be better ones out there, but at the time it handled everything I needed better than anything else I found. Back to the topic at hand - I am curious about a feed of 1300 pages - that could definitely take a little while to process. It's a shame it's not just addition of new pages - you could make that very quick if the xml feed entries had a date. But if you have to process them all for updates and deletions, you will be relying on the title of the page for matches. Will you just update them all, or will you compare the contents of fields for differences and process only if there has been a change?
-
Hey Robin - I have thought about it but I have always found that clicking Toggle All and then CTRL/CMD+F to use the browser's "Find" functionality works just fine. I agree that it would be a nice addition though, so I will have a think about it. Hey Juergen - I am wondering if maybe you're running PHP 5.3? I think it might be coming from the fact that I directly set $paths[] rather than previously defining $paths = array() Could you help me out and try adding: $paths = array(); on line 32, before the start of the foreach on 33 Please let me know if that works.
-
Most editors should these days, eg. Sublime and even the Tracy Console panel SublimeText TracyDebugger Console
-
Major revamp to Dumps / Dumps Recorder panels This has bugged me for a while - the Tracy core dumps panel is: ugly and with a forced label whether you want labels for it or not doesn't show a count of dumps next to the icon doesn't show dumps from consecutive ajax calls - each call overwrites the previous dump That is why I built the original Dumps Recorder panel, but it also had a problem: the redirect and ajax Dumps Recorder panels contained all previous dumps (those from the main page request, etc) which made it hard to see what was from what So now I have overridden the core Dumps panel with a new version that has: an optional label a count of dumps adds consecutive ajax calls so you don't miss any. I have rebuilt the Dumps Recorder panel as well. You probably won't want this most of the time, so it is no longer enabled by default on new Tracy installs, so if you are upgrading, I recommend disabling the Dumps Recorder panel by default and just enabling via the Panel Selector as needed. It no longer has a "Preserve Dumps" option, because that is now it's only purpose, so when it is enabled, it will preserve all dumps across all page / ajax requests and reloads. You can click "Clear Dumps" whenever you want, and of course disabling it will also clear the recorded dumps. I think this is a major improvement - it keeps things simple when that's all you need, but enables recording when you want to keep track of changes over multiple requests or you simply find that your bd() calls are somehow being lost / not shown - sometimes I see this when debugging modules - the dumps will be stored, but not shown - the dumps recorder will record these and show on the next page reload. Hope all that makes sense - please try it out and let me know if you find anything that you think can be improved. One other thing - I have moved the $_SESSION section from the Debug mode panel to the Request Info panel - I think that's a more appropriate location - inline with having the INPUT (post, get, and cookies) in there. On Tracy upgrades, you'll need to enable SESSION in the config settings for the Request Info panel.
-
EmailNewUser respects the "Automatic Force Change" option in the PasswordForceChange module which ensures it is automatically checked when a new user is created. Does that work for you? I am hesitant to override that setting if it's intentionally unchecked. What do you think? Actually, maybe the solution here is another config setting in EmailNewUser. The setting would force automatic selection of "Force password change on next login", even if the "Automatic Force Change" option isn't checked in the PasswordForceChange module. Do you think this would work ok?