Jump to content

formulate

Members
  • Posts

    141
  • Joined

  • Last visited

Everything posted by formulate

  1. The initial install was a couple months ago, so it seems like an update is in order! Thanks for the heads up dragan!
  2. I have a new project that uses extremely long page urls. I need to bump the 128 character limit to 256. Does anyone know how to do this? As it is now, when creating a new page with a really long title (ie: more than 128 characters), the URL is getting truncated to 128 characters. Thanks.
  3. Wow, wireHTTP is perfect! How have I built a zillion PW sites without ever knowing about wireHTTP. Sheesh. Thanks again Horst.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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?
  10. 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.
  11. 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.
  12. 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.
  13. No, not hidden. I also messed with doing a custom selector both in the input tab and ready.php - doesn't work.
  14. 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?
  15. 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?
  16. 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.
  17. 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.
  18. I fully agree with Lance. Firstly, a HUGE thank you to Ryan for doing this. It was badly needed and the only thing that held me back on converting some of my legacy ModX sites. I love PW and this was the missing piece for me. I can't thank Ryan enough for turning his attention to this sorely lacking functionality that almost every other CMS has. However, I'm very sad that this isn't a pro module. Rather than being part of the core to "guarantee" attention and updates (as others above have indicated), I would have preferred this to be a paid module to ensure such attention and updates. That's not to say Ryan won't be maintaining this module in a reasonable fashion, just that this is a huge enough component of a CMS that it absolutely could have warranted being a pro module and there are many of us that would have gladly paid for it. I will gladly use this module, provide feedback on bugs, questions on customizing, etc. and hope that all such things are attended to in a timely manner. While I appreciate that it is *FREE*, Ryan, please consider making it a pro module. I'm sure you have your reasons for not doing so and I guess I'm just worried it won't get the attention it deserves. It will be critical to many of my membership sites that I will now convert to PW and thus I'm worried about future development on it. Things like images support are crucial and if this was a paid module, may be higher up Ryan's priority list.
  19. Thanks everyone! This solved my issue. K.
  20. In the admin template's URL settings I forced HTTPS. However, I do not actually have an SSL cert in place and now I can no longer access the admin (shared hosting issue, it redirects me to some other site). How do I undo this? I've searched everywhere in the database and files for the setting and can't find it. I also tried forcing http in the .htaccess file and that didn't work. I found the template settings in the database, but couldn't see anything I could change for the URL setting. Help!
  21. Ah ha! That makes sense from my end. At the time I was having problems, it was on a server that was using Cloudflare. I had disabled Cloudflare for other reasons (namely their CSS caching drives me bonkers) and that resolved my issues, but I had never made the connection between the two. Thanks for coming back and chiming in with your findings.
  22. For what it's worth, I'm running it with 2.8.x no problem. Aren't 3.0 and 2.8.x essentially the same apart from the namespaces stuff? Does namespaces affect the module?
  23. Sorry, forgot to state that I had re-built the site using it's own domain. It's no longer subject to the multiple copies of PW issues. It's something specific to this site and I think I'm starting to track down the issue. There's a broken image in one of the CKeditor fields and it's causing the logout. I'm going to manually remove the image using phpMyAdmin and see what happens... UPDATE: FIXED! For some reason, if there's a broken (ie: missing) image in a rich text editor field it causes logouts. I haven't tried reproducing this yet from a clean install, but something funny happens when there's an image that's referenced in a rich editor field and it gets removed.
  24. Ok, starting to get really frustrated. I have a client that is upset with me as they can't edit their site. I have tried re-installing the site from scratch with the latest 2.8.x version and it still logs me out all the time. It's become worse actually... now 100% of the time if I edit the home page it will kick me out. What's going on? Why is it doing this? What do I do now? I'm at the point of desperation, I need content updated but the site is broken because of this logout issue. All the other PW sites on the same hosting account are working just fine.
  25. It's a fresh site. The only module installed is markup simple navigation, but it was doing this before that was installed. I strongly suspect it's because it's running in a sub-directory and therefore I have two copies of PW running on the same domain. I added the following to my config.php to try and make things behave: $config->sessionName = 'wire2'; $config->sessionFingerprint = false; However, this doesn't seem to make it work either. I suspect once I move the site out to it's own domain, things will work. PW just gets grumpy when there's multiple copies on the same domain, even though they're in separate directories, etc.
×
×
  • Create New...