Jump to content

modifiedcontent

Members
  • Posts

    250
  • Joined

  • Last visited

Recent Profile Visitors

2,792 profile views

modifiedcontent's Achievements

Sr. Member

Sr. Member (5/6)

45

Reputation

  1. I am using this module and am generally happy with it. Would be good if someone would maintain it. One issue I have; maps sometimes don't show up. I guess the javascript doesn't kick in somewhere and then you get a empty blank block. What can I do to make sure the javascript kicks in? Or something has to happen in the right order? Has anyone else seen this issue and fixed it? Probably not even 100% related to the module; it may just be something dumb in my templates.
  2. Just started using the image focus feature - very cool, works great, fundamental workflow improvement. 🙂 What happened to the optional, future zoom feature that Ryan showed in the video here? Can I enable it somewhere? Is it still coming? Or left out to keep things clean and simple? Other ways to achieve the same?
  3. Upgrading the secondary site to the same version as the "mothersite" fixed the issue. As explained here: 'Ideally all instances should be running the same exact version of ProcessWire if possible. At minimum, the versions must be close.'
  4. Upgrading the secondary site to the same version as the "mothersite" fixed the issue. As explained here: 'Ideally all instances should be running the same exact version of ProcessWire if possible. At minimum, the versions must be close.'
  5. Several of my sites stopped working. Has this multi-instance support been removed somewhere between v3.0.162 dev and 3.0.198 dev? Is there now another way to achieve the same? I urgently need to restore my sites. ? Is it related to this? Setting $config->useFunctionsAPI to 'false' makes no difference, so I guess not. The mothersite on the older PW version is still accessible with useFunctionsAPI on false or true; trying to access content from sites on newer PW versions produces a nasty 503 Service Unavailable error.
  6. I am now starting to rebuild this from scratch. I have a main "mothership" site and want to display content from that site in a secondary site on the same server, with another URL. I had three sites working like this with a solution that involved $config->useFunctionsAPI that worked fine, until an upgrade somewhere between 3.0.169 and 3.0.198 dev. Did anything change recently? Where are the current instructions for this? I see a lot of stuff about multisite, but that seems to be about managing multiple sites with different databases from the same admin etc. When I put this in my home.php template: <?php $forum = new ProcessWire('/home/bizpartn/public_html/mymothershipsite/site/', 'https://mymothershipsite.com/'); echo $forum; ?> I get this error in the browser: No error message in logs. If I uses another site on a lower PW version, echo $forum outputs this in the browser: I guess this was "multi-instance support", I originally worked on it here. Has it been deprecated/removed?
  7. My multiple instances (?) broke in upgrade somewhere between v3.0.169 and 3.0.198 dev. Did something change? What is currently the way to use this? I have to go back to basics and try to rebuild it.
  8. I have three secondary websites that get content from a related mothership website's database via the API - "multisites" or multiple instances with $config->useFunctionsAPI enabled and `new ProcessWire()` etc. This broke for mothership websites that were upgraded to PW version 3.0.198 dev; it still works fine for the one that is still on 3.0.169. If I edit the other secondary sites to get content from the v3.0.169 site, they work fine as well - but with the wrong content obviously... With the v3.0.198 dev mothership sites, I now get error page 503 on the secondary websites that should get content via the API. The log says: 'Error: Exception: Unrecognized operator: % (in /path_to_my_pw/wire/core/Selectors.php line 410)' - I can't find info where that problem starts. There is probably bad coding/syntax somewhere in my template files, but I can't pinpoint it. Any suggestions? What changed between 3.0.169 and 3.0.198 dev? What could cause 'Unrecognized operator: %'? The selector error could be related to this?
  9. @da², there are probably several standard ready-to-use scripts floating around on this forum and elsewhere and I think there was another module - curious to hear responses from others, I haven't checked recently. Here is a login/register process from the main PW developer Ryan Cramer. It's 5 years old, but I think it should still work and that it was provided as an example that you can adapt and expand to suit your needs. And if you really need a generic out of the box solution, you could always use the Pro module. Here are some of the old threads where I was trying to solve some parts of this, like best practices to secure registration and front-end password reset. Also see this post.
  10. @da² I developed my own login/register process with a lot of help from this forum, I think just before that LoginRegister module(s) appeared. There are a lot of advantages creating your own process and PW makes it relatively easy. Once you have it, you can reuse it for different sites. Probably not super helpful in your case, but I imagine this is how many PW users approach it. Curious to see other responses...
  11. I am trying to put together a front end form for a repeater field. The solution in the previous post gives helpful clues, but my repeater field doesn't need new pages and templates I think - isn't that a Page Reference field? My repeater field is for RSS feeds; name 'feeds', type 'Repeater'. The field used by 'feeds' is name 'rssfeed', type 'URL'. To store a regular field I'd use something like this: But instead of one value it would be adding one or more values to an array, somehow done with the fieldname[] and for ( $i=0;$i<$fields;++$i ) stuff, but without new Page() and template etc.? Not sure how to put that together, will try things this weekend... Is there a code example somewhere? Is there a way to get the same fancy repeater input field as in the admin area?
  12. Thank you @horst! That was the problem. I was using $sanitizer->text() on the field. If I remove that it works fine. There is a $sanitizer->textarea() and $sanitizer->purify() is probably best for my use case.
  13. Input from a textarea field via the front-end gets truncated; only the 246 characters (with spaces) get saved, nothing longer. When I enter text for the same body field via the admin back-end there is no limit and it also shows up fine on the front-end, but when I edit and save that same longer text from my front-end form, it gets cut at the same spot around 246 chars. I have tried with and without Ckeditor, but that makes no difference. I guess I can eliminate Ckeditor as a possible cause. What else could it be? This may be related or not. Any other ideas appreciated.
  14. Why would I do that? I now have the delete button figured out - with your help! - so why would I start over again? I do normally avoid modules and try to use built-in methods that I understand. Agreed with your point. But for the comments section, this is a module by our fearless leader @ryanand as far as I understand it, I like his approach; looks like a solid future-proof basis to move forward with. So I need to sort out an edit button next, probably next Christmas... If anyone has any ideas, please post in this thread. I guess for an 'edit' button you would use updateComment()? Edit field via ajax?
×
×
  • Create New...