-
Posts
2,321 -
Joined
-
Last visited
-
Days Won
44
Everything posted by tpr
-
What modules are you using? Try to disable them to check whether they are causing this, if you haven't dine this yet.
-
Just committed v1.1.0 to the dev branch at GitHub: https://github.com/rolandtoth/InputfieldURLChecker/tree/dev This is 99% the same in functionality but under the hood it uses InputfieldURL::render and InputfieldURL::renderValue. The only new feature is that locked field urls now respect the module setting "Target", so clicking on them may open in an iframe if setting so. Locked url fields with description or notes was linkified incorrectly in the previous (JS-only) version, as all the field contents were wrapped in a link, not only the url. Now it's handled beautifully with the renderValue hook. Using backend hooks made it much simpler and reliable to deal with template/field restrictions, and probably there will be more benefits in further developments.
-
I will rewrite half of the module to take advantage of InputfieldUrl::render, which would make things simpler. Now JavaScript makes all the heavyweight stuff which works, but it's too clunky here and there.
-
Thanks, version 1.0.5 is up on GitHub with the fix.
-
I just installed from the module directory (entered the classname "InputfieldURLChecker") and worked fine. I'm on Win but I don't think that could be an issue. What FF/Chrome versions are you using? I guess you tried it on az URL type field and not on a regular InputfieldText. In the module settings, have you added anything to the "Enabled templates" and "Enabled fields" area? If so, the module will be active only in those templates/fields, and unavailable elsewhere. Also make sure the Mode is set to "Button" and not hotkey. On the admin page where you expect the button to appear, check the page source if it contains "IUC" within a script tag in the head.
-
Available also from the modules directory: http://modules.processwire.com/modules/textformatter-multi-value/
-
v1.1.5 is up with a handful of fixes and some new features. Thanks for all who reported/suggested/helped in any ways. Changelog
-
Thanks, works fine! It's because of this I guess: http://php.net/manual/en/language.oop5.object-comparison.php#71623
-
When I select a sub-branch as parent, I get "Nesting level too deep - recursive dependency?" error. I have 3 sub-branches and selecting the first is OK, then selecting second or third results in this error. Changing the line around 162 to this ("===" instead of "=="): return $page === $this->user->branch_parent ? true : false; or this (adding "->id"s): return $page->id == $this->user->branch_parent->id ? true : false; seems to solve.
-
No, I haven't committed the new version yet as there are some other things to add/fix.
-
I wish I could say AdminRestrictBranch works great but... IT WORKS F***** GREAT! Unfortunately that's not entirely true for FEEL. I found a mistake that haven't show up so far because I was mainly testing with superuser rights. I was checking if the actual page was editable and added FEEL js/css if yes. Now on pages that included edit links targeting other pages and the "hosting" page itself was not editable, assets weren't added. Obviously with superadmin the current page was always editable. Now I modified my module and it uses only Page hooks, so perhaps it was working with your previous module version too. Thanks for the other FEEL reports, will check them.
-
I knew I should have deleted that old repo, sorry https://github.com/rolandtoth/FrontEndEditLightbox Yes, I hook to init in Feel. The question is that I really need that so perhaps your module shouldn't be changed.
-
I have no issues in the admin, PW edit links appear fine and visibility is OK. Using PW 2.70. Are you using an older version of FEEL? It has been rewritten as a module and usage was changed to $page->feel($options). The module render edit links to the page only if the page is editable, which should be the case according to your findings. I guess there's something with FEEL, I will try to track it down when I will have a larger screen in front of me
-
Sorry, no success so far. I have updated the module, refresh, uninstall and then install but $page->editable() doesn't return true. If I make it literally true in FEEL then the edit link appears and the lightbox shows the admin page, so the page is editable to the user. Autoload seemed the culprit but somehow it doesn't work. I will investigate the issue later, maybe it's something on my side. Thanks for the help!
-
Looks like just what the doctor ordered, thanks! I can't test it on the site I need this because it is demoed to the client. But on another site works beautifully at first sight. One thing: "$page->editable()" returns false even if the page is under the selected branch and the user could edit it otherways. I did try "$page->parent()->editable()" too but no success. Is there a way to check the editability of the page? My FEEL module currently fails because of this.
-
Sanitizer pageName and french closing quote ("«")
tpr replied to Webrocker's topic in Multi-Language Support
Looks so. I haven't looked into the code but yesterday I had a same situation where it helped. So as it turns out the character that was missing for me was in the InputfieldPagename translation settings. -
Sanitizer pageName and french closing quote ("«")
tpr replied to Webrocker's topic in Multi-Language Support
Try pageNameTranslate -
UX nightmare: nested modals in theme (default & Reno)
tpr replied to steveooo's topic in Themes and Profiles
I was just overriding values in the dev tools (inspector). Unfortunately I have no PW install where there are nested lightboxes but just repeat the second half of the gif 2-3 times and you got the idea how it would look The easiest way I guess is to add a custom stylesheet with the overriden values using this module: http://modules.processwire.com/modules/admin-custom-files/ -
UX nightmare: nested modals in theme (default & Reno)
tpr replied to steveooo's topic in Themes and Profiles
Playing with the dev tools it's easy to force the fullscreen modal by tweaking some css: But would you know on which page you are if 3-4 lightbox layers are on top of each other? -
UX nightmare: nested modals in theme (default & Reno)
tpr replied to steveooo's topic in Themes and Profiles
What I can think of as a quick fix to make the overlay 100% opaque and set modal sizes equal using custom CSS with a hook, perhaps in ready.php. -
Huh, I was hoping something like that because otherways I may had deep misunderstanding of roles and PW as a whole Anyways, your code will be a strong starting point, thanks for that!
-
In my setup I may need hundreds of editors so creating hundreds of roles seems an overkill. I would give them the same role and select the tree they can edit - one user, one page (and its subpages). So if a new affiliate is added, I would add one new editor and select one page that he can see in the admin and edit. I have no pagetables so perhaps that's why I see my idea better for this purpose.
-
-
Thanks, I will definitely try this when the time comes - it will be only in the second phase (if ever). I would tie user name instead of role to a branch. If I get it right your code requires setting each user a new role, which is I guess unnecessary, and an overkill on a larger user (editor) base. Ideally I would add a new field to users, eg. "home_branch", where the superuser could select the user's own tree.