formulate

Members
  • Content Count

    111
  • Joined

  • Last visited

Community Reputation

42 Excellent

About formulate

  • Rank
    Sr. Member

Profile Information

  • Gender
    Not Telling
  • Location
    Canada

Recent Profile Visitors

1,516 profile views
  1. Wow, wireHTTP is perfect! How have I built a zillion PW sites without ever knowing about wireHTTP. Sheesh. Thanks again Horst.
  2. Very interesting. While I don't think I need the .htaccess part, the second half of your response is probably doable in some fashion. Something like this: Site B tries to pull "optimized" image from publicly accessible url. If it can't get it, it triggers script on Site A to create optimized image and then tries pulling it again. I'll probably have to use curl in order to properly get the 404 call back. I'll report back once I've rigged something up and tried it. Thanks Horst.
  3. Looking for some advice. On site A, I have Ryan's Service Pages module installed and am serving data as JSON. On site B, I'm retrieving the data by passing a page ID. This works great for all the data, but for images it is pulling the full image that's stored in the field for a given page. On site A I store full size images as I use them in a variety of ways and use the API to resize them. However, when using the service pages and pulling the data to site B, I don't have opportunity to resize first and thus it's pulling 6mb, 8mb files over every time site B displays the data. I of course resize the images once they get to site B, but it still has to pull that initial full file over. I need the resize to happen on site A first. So a few thoughts... 1) I could build a caching system on site B that uses cron to execute a script to pull the images, resize them and store them. I'd rather not do this if I can help it and would prefer to rely on a solution that is self-contained on site A. 2) I could use the API on site A to create a compressed version of the file that is publicly accessible via http. I would write up a script that would go through the thousands of pages I have and create these http accessible versions and then create a cron to fire off a script to create these images on a regular basis to account for newly added pages. Not an ideal solution. 3) I could hack the service pages module and somehow resize images before serving the JSON filename. 4) Is the service pages module hookable? That would be preferable to #4 above. Any other thoughts? Some angle or idea I'm not seeing? Thanks for your time looking at this.
  4. Brilliant! In the end my code was more or less along the lines of what d'Hinnisdael posted above. Thanks everyone for chipping in and resolving this issue.
  5. Yeah, first thing I did was strip the conditional back. It appears that if I'm logged in as a superuser, your ready.php code works (as expected). If I'm logged in as any other role, a generic error is thrown and pages in the admin don't work. Below is the code I'm using. Note, I also tried removing the appending of check_access=0 line and it still throws an error (some issue with re-assigning the event arguments, which makes no sense to me). $this->addHookBefore('Pages::find', function(HookEvent $event) { $selector = $event->arguments(0); $selector = ', check_access=0'; $event->arguments(0, $selector); }); Will look again tomorrow. Thanks Adrian.
  6. Couldn't get this to work on my first attempt. Out of time tonight, but will try another crack at it in the morning. Thanks for the github link as well.
  7. Ok, I can confirm the following: 1. Adrian's advice above about check_access=0 works, provided you're doing #2 below. 2. Custom Selectors and therefore the solution from #1 above, will NOT work using page list or auto complete. You need to use good old fashioned select drop down. Adrian, in your example above, how do you think you were able to circumvent issue #2 that myself and d'Hinnisdael seem to be experiencing? Was your screen shot from a superuser or non-superuser role?
  8. Strange, any custom selector I try and specify doesn't work. Even when using standard select vs auto complete. Running a clean install of 3.0.108. I'll try a different version PW install and see what happens. Once I get my selector working I can then test check_access. EDIT: Turns out using a standard selector works after all, but using page list or auto complete doesn't seem to use custom selectors. My experience here confirms what d'Hinnisdael has said above.
  9. Well, that would explain my custom selector not working. Problem is that the page reference is pulling several thousand pages. Very impractical for anything but the autocomplete search from a usability standpoint. Not sure what I'll do for a solution - will put on my thinking cap.
  10. I am having a separate issue at the moment where my custom selector isn't working (either in the Input or ready.php). Once I get that hashed out I'll try the two above solutions and report back.
  11. No, not hidden. I also messed with doing a custom selector both in the input tab and ready.php - doesn't work.
  12. I have a page reference field with the "include unpublished" checked. Non-superuser accounts still can't see unpublished pages. I went through the permissions for the role and couldn't see anything related. Do I need to create some kind of custom permission to get this working?
  13. formulate

    I'm still having an issue with this. Both with my older PW sites and my newer 3.0+ sites. I can see the rule in the htaccess, but .well-known is still blocked. Any ideas?
  14. formulate

    It's been a while since I had these issues, but yes it's definitely tied to some setting in CKEditor as not everyone seems to have this issue. As Robin mentioned, it's most likely one of the image related settings in CKEditor under the "HTML Options" settings. One of those checkboxes is messing with things. I haven't had time to try and debug/test it further, but that's where my suspicions are at.
  15. While I can't speak for everyone, I think we're all being positive and supportive. We are grateful this now exists. However, I think there is a valid argument to be made in the desire for a paid enterprise level solution that will give us peace of mind in trusting that such a critical component of a website is a high priority with proper attention, development and support. Raising this point isn't negativity, it's just an expression of concern. I work with large organizations that have thousands of members. I need a solution that is rock solid, that I can trust will have bugs and support issues attended to in a timely manner. It just stands to reason that a paid solution is going to receive higher priority than a free one. You're right, it's new and let's see how things are in a few months.