Jump to content

modifiedcontent

Members
  • Content Count

    173
  • Joined

  • Last visited

Community Reputation

29 Excellent

About modifiedcontent

  • Rank
    Sr. Member

Recent Profile Visitors

1,862 profile views
  1. Excellent. Thanks rick and wbmnfktr. I'll do this in the coming weeks and will report back.
  2. What is currently the best way to move a Processwire site to a new server? I have to upgrade my VPS, from CentOS 6 to CentOS 8. I have several relatively complicated Processwire websites. I am currently downloading all the files via FTP. I will export databases next. I guess I'll use Export Site Profile. Or had that been replaced by something else? New modules that I missed? Or will the FTP'ed files + exported database be enough? Just copy them 1-on-1 to the new server and it will all work? What can go wrong? What are the pitfalls to watch out for?
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. 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?
  8. 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?
  9. 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.
  10. 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.?
  11. 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?
  12. 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?
  13. 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...
  14. 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?
×
×
  • Create New...