-
Posts
10,896 -
Joined
-
Last visited
-
Days Won
348
Everything posted by adrian
-
For many years I was fortunate to host all my sites on my own dedicated University servers. These days I also use unmanaged Digital Ocean VPS servers whenever I can, but obviously these are not for everyone. The one thing I steer clear of is FastCGI / nginx as an apache reverse proxy - PW always gives me errors on these setups.
-
Sorry, @guenter55 - I don't see anything in that example at osana.com that looks like a way to revoke consent after they have already given it. In my mind the link to revoke after initial accepting isn't something that can really be part of the module because where it should physically appear is specific to every different website - it's not something that can be in an overlay banner like the initial accept/deny option.
-
I think this is probably just a side-effect of this recently introduced core bug: https://github.com/processwire/processwire-issues/issues/979
-
Your mileage might be different, but I found Webfaction hosting quite slow, not to mention a very strange and overly complicated control panel ?
-
MarkupSEO - The all-in-one SEO solution for ProcessWire.
adrian replied to Nico Knoll's topic in Modules/Plugins
-
MarkupSEO - The all-in-one SEO solution for ProcessWire.
adrian replied to Nico Knoll's topic in Modules/Plugins
Not sure, but I think my fork/branch does take care of that: https://github.com/adrianbj/MarkupSEO/tree/various-fixes-enhancements -
Thanks everyone for the recent discussion on this - the intricacies of GDPR are not my forte. Sorry, I don't really understand what you are looking for here - I don't think the module should always output a "Manage Your Cookies" - I think this needs to be something that the site developer decides where it should go and how it should be styled. Or maybe I am confused by what you want?
-
I agree with @teppo - I recently discovered a colleague who was using phpc extensions on a site and he'd left debug mode on. I changed a URL query string value to something invalid which threw an error in a phpc file and I could simply load that file in the browser and view its contents - turns out it contained a payment gateway API secret key. All this because of a non-standard extension that PW's default htaccess file doesn't prevent access to.
-
Handling special cases: The elusive navigation menu override
adrian replied to MoritzLost's topic in Tutorials
I know I am getting OT, but I almost never use target="_blank" anymore. Here are a few thoughts: https://css-tricks.com/use-target_blank/ I think the key thing for me is that it's really hard to prevent opening a new tab when it is used, but it's really easy for the user to choose to open in a new tab if they want, so my rule is that unless the user will lose unsaved form data as a result of opening a link in the same tab, I never force a new tab. -
Yeah, I feel like the new core addition could show the layout of the fields like your Robin's does. I guess the issue could be with not having enough room to show the field label, name, type and width, but maybe there is a solution that would work.
-
Handling special cases: The elusive navigation menu override
adrian replied to MoritzLost's topic in Tutorials
Some great musing there! I don't think there will ever be a one-size-fits-all approach for creating menus that works for every site. Sometimes I match the menu exactly to the page tree. Sometimes I hard code it. Sometimes I have a checkbox field that determines if each page should be in the menu. Sometimes I let the site editors control it like this with two page reference fields for the header and footer menu respectively, and put it in a "Menus" tab on the homepage. And sometimes it's a combination of these approaches for different parts of the site. There are so many options and each has its place. -
Not currently, but it could be a simple addition.
-
I see you are using what looks to be custom action. Do any actions work? Have you put a bd() call inside the exexute function to see if it's called at all? Have you done a hard reload in your browser to make sure you are getting the latest js files?
-
Make sure sure you get your PW and LP versions compatible with each other: ListerPro v1.1.3 for PW 3.0.137+ (August 2019) - Newest DEV version: ProcessPageListerPro113.zip ProcessWire 3.0.137 or newer is required for this version! ListerPro v1.1.2 for PW 3.x (January 2019) - Newest MASTER version: ProcessPageListerPro112.zip ProcessWire 3.0.98 or newer recommended.
-
Anyone new to this module, please be aware of this unfixed issue: https://github.com/ryancramerdesign/ServiceCurrencyConversion/issues/1
-
It doesn't diminish your request, but Interestingly I have an issue where AOS actually causes a horizontal scrollbar to appear on desktop on some pages - as soon as I disable AOS it goes away. I haven't narrowed down the cause, but something worth thinking about in all this.
-
Thanks @Macrura - that got me on the right track - should be fixed in the latest version.
-
Hey @Macrura - you gotta give me more than that ? Seriously though, it looks like there is something breaking output for the Server Request section, or perhaps it's actually being broken in the preceding Field List & Values section. Could you please try disabling those two sections (in the config settings there are checkboxes) and see if that fixes things? Then perhaps you could narrow down what part of the section is failing please? My gut feeling is that it is the Field List & Values section and there is some field that is breaking things. Thanks.
-
Based on the available methods in this module, it seems like the best approach is actually now: $map = $modules->get('MarkupGoogleMap'); echo $map->getGMapScript(); You can see here: https://github.com/ryancramerdesign/FieldtypeMapMarker/blob/917edef8efe92bf8bdbdff62b66f6eca581ca57e/MarkupGoogleMap.module#L154-L165 that this will return the entore script tag you need, along with your API included. Of course it would be nice if the module docs mentioned this ?
-
Just added a small feature that fixes a big pain point for me. When editing a page, there is a new button in the AdminTools panel to change the "collapsed" status of all fields to fully open and editable. This is great for those fields that you don't want available regularly (especially for non-superusers), but occasionally need to view or edit. Fields will remain like this until you click this alternate button, or the site cookies are cleared. Hope you find it useful!
-
@teppo - yep, you have understood exactly what I am suggesting. I agree - I don't like long click / double click. Perhaps just a dropdown from the "Edit" link that says "Edit in Admin". But of course the main top-level Edit link would edit in the overlay, so no need to wait for the dropdown to appear when wanting to edit this way. ??
-
The term "Setup" doesn't make much sense to me either for things other than Templates and Fields and perhaps others like Languages etc. But the nice thing is that you can rename Setup to something else if you want, or move any of it's children out to the top level, or under another parent you might create, perhaps called "Tools" or whatever you want.
-
Awesome - thank you @teppo Not sure if this is a good idea or not, but what about a way to choose between edit modes from the AdminBar? Inline Edit vs Admin Edit, or something along those lines. Not sure whether they should be separate buttons, or a dropdown for the alternate (not default) method, or perhaps long-click (although this takes training users so not sure this is a good idea). I just feel like sometimes you know you will want to edit other pages after this one so it's a shortcut to the admin along with editing the page. Maybe it's getting too complex though, so no pressure ?
-
Hey @teppo - you raise some interesting points regarding Tracy's output mode. Honestly I think when I initially set that logic up I wasn't certain of the approach that would make the most sense so what we currently have may not be perfect, but here are my thoughts on the current state of things. In Production mode Tracy logs and emails (if set up) errors, but doesn't display the debug bar or errors on the screen. Unless you are a superuser or other authorized user, all sites will be in Production mode regardless of this setting. If you are a superuser and the output mode is set to Production or Detect (and the site is on a live server) and the "force" option is not checked, then Tracy will be in Production mode - I guess my thinking around this is that some superusers may not want Tracy to be in Development even for themselves when a site is live, but that on the dev version of their site with all the same settings, they would like it to be Development mode. The reason it's not all tied to PW's debug mode is that if debug mode is on and for some reason Tracy doesn't capture the errors (unlikely/impossible I suppose), guest users may see PW/PHP error messages (not good!), so I like to have Tracy's Development mode tools (debug bar / bluescreen error stacks, etc) available for superusers even when debug mode is off on a live site. I hope that explains a little of my thinking, but if you are struggling with the way things are set up and would like to see changes, I am definitely willing to consider your suggestions - I haven't revisited this logic in many years! Re: breakpoints - sounds like you figured that all out in the end, but regarding the bp() method that is used by the Performance panel - that comes from the wording used in that Panel (https://github.com/Zarganwar/PerformancePanel/blob/master/src/Panel.php) which is clearly not a good use of the term and is confusing. If you're interested, you may like to look through the other 3rd party panels available for the Tracy core: https://componette.com/search/tracy - in particular there are a couple of XDebug related panels that you might find helpful - they don't seem to be actively developed anymore, but perhaps you could investigate and we could implement one into TracyDebugger if helpful. In general, I'd definitely appreciate any thoughts you have on Tracy and its functionality. Cheers!
-
Just noticed something in the new php.ini that is shipped with php7.3 ; The value is also used for json_encode when encoding double values. ; If -1 is used, then dtoa mode 0 is used which automatically select the best ; precision. serialize_precision = -1 The php.ini with php7.0 had the precision set to 17. Not sure what real world impact this will have though.