Jump to content

modifiedcontent

Members
  • Content Count

    171
  • Joined

  • Last visited

Community Reputation

29 Excellent

About modifiedcontent

  • Rank
    Sr. Member

Recent Profile Visitors

1,811 profile views
  1. Thanks wbmnfktr, I had seen that one. That page gives a lot of general, very useful background info on the how and why of permissions, but I was looking for a quick overview/cheatsheet with recommended settings for each processwire directory/file.
  2. Is there an overview/cheatsheet anywhere with recommended permissions for each folder and file? I know permissions are set at installation, but I probably messed things up a bit in a server upgrade or PHP 7.3 has different requirements. I now keep running into permission issues.
  3. Answering my own question: I got directory/files ownership/permission screwed up on /site/assets/cache. Or PHP7.3 handles those differently? /cache and /modules should be writable. I had both on 755, but guess ownership was wrong. Doing this via ssh fixed it: chown -R myserveruser site/assets/cache chown -R myserveruser site/modules chmod -R a+w site/assets/cache chmod -R a+w site/modules Are there other folders/files I should double-check?
  4. I had upgraded my Apache configuration to include PHP7.2 and PHP7.3 for a Laravel-based script on the same server. Somehow it/I messed up a previously fine Processwire site, in a very confusing way. The site still looks fine, but editing template files has no effect whatsoever. It is stuck on some kind of cached version. I have already disabled PHP7's OPcache, cleared browser caches, etc, with no effect. The pages now apparently come from PW's assets/cache/FileCompiler folder, even though I never enabled template caching for this site. I have tried adding "namespace ProcessWire;" to the top of the homepage template file, but then I get this fatal error: My functions.php file pulls data in from another Processwire installation on the same VPS with the following line: $othersitedata = new ProcessWire('/home/myaccount/public_html/myothersite/site/', 'https://myothersite.com/'); That apparently still works fine; the site still displays data from the other installation, but via the "cached" template that I am now unable to change. I don't know where to start with this mess. Does any of this sound familiar to anyone? Any pointers in the right direction would be much appreciated. Edit: Adding "$config->templateCompile = false;" to config.php results in the same fatal error as above.
  5. Is there a way to allow the front-end editing feature for a role, without also giving that role access to the admin area/control panel?
  6. Why doesn't this work? $members = $pages->find("template=user"); foreach($members as $bogus) { // don't use $user if ( $bogus->firstname === $bogus->lastname ) { $bogus->delete(); } } I get this error: If I echo $bogus->fullname, I get a nice list of spam accounts where the first and last name are the same. There has to be a way to let PW allow me to delete them. I have also tried $users->delete( $bogus ) and $users->delete( $bogus, true ) and a few other variations, but keep getting the same error message. Line 1017 is this: if(!$this->isDeleteable($page)) throw new WireException What makes a page not deletable? Any ideas? I have a similar bit that deletes user accounts with numbers in the name fields: $members = $pages->find("template=user"); foreach($members as $bogus) { if ( preg_match('/[><\-0-9]/', $bogus->name ) ) { $users->delete( $bogus ); } } That one works fine. What am I getting wrong with the other one? Edit: I think I figured it out. $firstname === $lastname would also be TRUE for two empty fields, so I guess PW has wisely made that not deleteable somewhere. So you have to check first if either field is set at all. The following seems to work: $members = $pages->find("template=user"); foreach($members as $bogus) { // don't use $user if ( $bogus->firstname && $bogus->firstname === $bogus->lastname ) { $users->delete( $bogus ); } } Or still wrong?
  7. To me the beauty of Processwire is that it makes no assumptions how you use it. This module breaks with that logic a bit, probably unnecessarily. I have started editing the css. That is no big deal. I'll look into how to use this field as input for the map marker modules, make them work together. btw, I hope your health problems are under control. Either way, take care.
  8. I need some kind of address field type to store street addresses for events - the map marker modules produce unusable garbage addresses... This module looks solid and probably does what I need for my case. Why does the module assume it will be used for postal mailings? Is that really necessary? Couldn't the UX be a bit more usage agnostic and use the regular admin fonts etc.?
  9. The 'address' field is supposed to output the address you entered. echo $page->map->address; // outputs the address you entered But it actually outputs whatever the map thinks is at that lat-long, with a lot of unnecessary details added, something like this: The address search also insists Water Street is in lower Manhattan when I mean Water Street in Brooklyn. Brooklyn becomes Kings County in map->address; nobody calls it that! You can force the map to select the right location by dragging the pointer. Now the address is: Which is hilarious and completely useless. Is there a way to keep/store the actual "address you entered"? Or else a way to format that map->address into something usable?
  10. This module is great, essential. Unfortunately I can't yet get it to work on my front end. The map doesn't show up due to a javascript/jquery conflict. The module outputs regular jquery script starting with $(function() { ... If I manually add the following alternative to the footer it works fine, the map shows up in all its CartoDB glory: How can I get the module to do the same? Or get around this problem some other way? Edit: I have replaced the following line in MarkupLeafletMap.module: $inlineScript = "<script type='text/javascript'>\n$(function() {\n" . with this: $inlineScript = "<script type='text/javascript'>\nvar jMap = jQuery.noConflict();\njMap(function() {\n" . Now the module works as expected. Could you make that part of the module for next updates? With jLeaflet instead of the more generic jMap. Or is there a good reason not to do it like this or a more cleverer way to avoid jquery conflicts?
  11. Thank you so much adrian. I had been using your Admin Actions module for other things. Super useful. I should have thought of trying that sooner. I have first applied 'Copy Content to Other Field', then used 'Delete Unused Fields'. Both no problems. More clean-up work to do before I can declare victory. I would be pleasantly surprised if the data really is still there, but at least the old fieldtype is gone. Will report back...
  12. I was trying to uninstall the FieldtypeMapMarker module, that is connected with the problematic Google Maps API that has raised their prices and produces errors. I want to replace it with Leaflet Map Marker. I uninstalled parts in the wrong order, hoping I could keep my address data. The module's uninstall is disabled, because the 'module is a Fieldtype currently in use by one or more fields'. But admin for the field in question now produces this error: Fatal Error: Uncaught Error: Call to a member function set() on null in /home/.../site/modules/FieldtypeMapMarker/FieldtypeMapMarker.module:54 Stack trace: Reuploading/reinstalling the FieldtypeMapMarker module didn't fix access to the fieldtype admin. I have tried uninstalling via the API, but don't understand how that works. I have tried putting this in a template file: $modules->uninstall("FieldtypeMapMarker"); That didn't do anything. I guess I have to put this in a function or "hook" it somewhere? I have no clue. Or would this method still perform the same check if I am allowed to uninstall? How can I nuke FieldtypeMapMarker without doing more damage? Is deleting rows in mysql really the best option? Is there a somewhat clean way to force uninstall and/or replace FieldtypeMapMarker with the Leaflet alternative?
  13. I have "solved" the issue by using window.location.origin as the ajax url. My ajax call now looks something like this: Leaving url out - using "self" as url - produces the error described above for urls based on titles starting with quotes. I wasn't able to figure out what/where/how to escape something to prevent that error. Bypassing problematic urls by using window.location.origin solves the problem. Or is there a better solution?
  14. I have this same error after updating to the latest version of PW: I haven't explored further yet, working on other things, will get to this eventually. Any news what causes this?
×
×
  • Create New...