Jump to content

Hani

Members
  • Posts

    113
  • Joined

  • Last visited

Posts posted by Hani

  1. Thanks for the responses, guys. After a bunch of back and forth with Dreamhost, I ended up asking them to move us to a different web VPS and MySQL VPS.  After they did that, the problem disappeared!  Still not sure exactly what the issue was (my GUESS is either a network issue or another VPS on the same hardware causing an issue), but glad we got it figured out.

    • Like 1
  2. Short update.  I was able to uninstall SessionHandlerDB successfully now and the errors have stopped.  But the site remains very slow and the API calls are intermittently quick and then VERY, VERY slow.  I have Dreamhost looking into the issue because I truly believe it is an issue with the MySQL VPS (and/or the networking) they have my client on.

    • Like 1
  3. Hi all - I recently started getting the GET_LOCK error on an old client's website for the API calls that are being made. The VPS web and MySQL servers are separate (have been for a while) and are hosted on DreamHost. I just can't seem to get a handle on it. I tried to uninstall SessionHandlerDB and that led to more problems so I reverted the change. I have SessionHandlerDB v0.0.6 and PW v3.0.227.

    When I uninstalled the module, I immediately got an error that said :

    Compile Error: Declaration of WireMailSmtp::attachment($filename) must be compatible with WireMail::attachment($value, $filename = ") (line 550 of site/modules/WireMailSmtp/WireMailSmtp.module This error message was shown because: you are logged in as a Superuser. Administrator has been notified. Error has been logged.

    Note that I will see that error every now and then now too when I go to the modules pages in the admin portal.

    After I uninstalled it, I reverted by restoring the "modules" and "sessions" database tables to get things back up to a state where the site loads again.

    There was a beta version of the module that @netcarverhad posted in another forum thread. I tried that too, but to no avail.

    Any ideas? Things to check?

    Thanks for any help and tips!

  4. A bunch of my old clients started having this issue on Dreamhost as well.  Like @cstevensjr, I noticed that any domains on a VPS weren't affected. However, some domains on shared hosting plans were affected while other ones were not.  Probably a difference between servers, but not certain why shared servers would have different ModSec settings.

    Anyway, I was lucky to chat with a tech that was patient and knew his stuff.  (Shout out to John B!)  We worked through one of the affected domains and he figured out what ModSec rules were being tripped by the uploads. So he had to add exceptions to those rules until the uploads worked - even with the Extra Web Security option still enabled for the domain.  After we got one domain working, he replicated the same exceptions to the other domains and we tested each one as we went.

    He kindly shared the list of rules that were causing the problem after I asked for them (in case this issue popped up again or if I had to speak to another agent about another domain).

    The rules being tripped were:

    • application-multi
    • language-multi
    • platform-multi
    • event-correlation
    • attack-generic

    If you have to talk to a Dreamhost tech to get this problem resolved, it may be helpful to point them to this post or simply pass them the list of rules being tripped that need exceptions added.  Like I mentioned earlier, and unfortunately, these rule exceptions need to be added on a domain-by-domain basis.

    • Like 4
  5. Ah. Okay, so Martijn's solution won't work for me.

    I suppose the implementation I imagine something like this would work is that under a page's "Settings" tab, there is the same configuration setting that we see on a template's "Family" tab that allows us to define what templates the children of this page can use.

    Given PW's core functionality, would adding something like this by using a module be possible - and if so, would clicking "Add New" be able to take into account the parent page's allowed templates for children?

    • Like 1
  6. Being able to restrict the templates used for children pages under a template's Family tab has always come in handy (defined under the "Allowed templates for children" setting), but is there a way to restrict the templates used for children pages for a specific parent page (based on ID) rather than the parent page's template?

    My use case: I have a template called "Data Container" which I use for several pages to keep pages organized.  Each of these data containers have children of specific template types.  For instance, one data container might have "cities" and another may have "buildings", etc.  Currently, an admin user has the freedom to choose any template type for children of any Data Container page.  

    While I could create a new template for each data container that restricts children by template, it seems redundant because every one of those data container templates only has a "title" field and they will always only be used for one page. I think it would be great if I can define a page's children's template type by the specific page itself (based on the page's ID).  That way, I can only have one Data Container template but restrict an admin from putting a child with an incorrect template in the appropriate data container.

  7. There's also another way of pulling calendar information from Google - but you have to have an API key to do so.  I have a non-Processwire site (still on the task list of one to convert) where I pull Google Calendar data. This is a snippet of what I recently ended up with once I realized that the full calendar feed was no longer working.

    // GET NEXT FOUR UPCOMING EVENTS
    // maxResults = 4
    // timeMin = current timestamp in ISO8601 format
    
    $url = 'https://www.googleapis.com/calendar/v3/calendars/[EMAILADDRESS]/events/?key=[APIKEY]&timeMin=' . date('Y-m-d\TH:i:s\Z') . '&maxResults=4&singleEvents=true&timeZone=Los_Angeles&orderBy=startTime';
    
    $calendar = json_decode(file_get_contents($url), TRUE);
    $events = array();
    foreach ($calendar['items'] as $item) {
    
        if (array_key_exists('dateTime', $item['start'])) { // has a specific beginning time
    	$events[] = array(
    	  'title'=>  $item['summary'],
    	  'start'=>  strtotime(substr($item['start']['dateTime'], 0, -6)),
    	  'end'=>  strtotime(substr($item['end']['dateTime'], 0, -6)),
    	);
        } else { // an all-day event with no specific beginning time
    	$events[] = array(
    	  'title'=>  $item['summary'],
    	  'start'=>  strtotime($item['start']['date']),
    	  'end'=>  strtotime($item['end']['date']),
    	);
        }
    }
    
    return $events;
    

    Who knows if Google will eventually close off the basic feed or not, so at least there's a bit of an alternative approach here if they do that.

    • Like 1
  8. Sorry it took me a few days to respond, Jonathan.  Well, the .htaccess file that's in the page's assets directory should automatically redirect any requests to the pass-through page.  So, if I were to try to get 

    http://www.mydomain.com/site/assets/files/xxxx/mydocument.pdf

    the request will instead will be redirected to 

    http://www.mydomain.com/file-download/?page=xxxx&file=mydocument.pdf

    The template file is used on the page that I've created at http://www.mydomain.com/file-download

    Does that help at all?

    At this point, the .htaccess file has to be manually copied into the files folder for each page that you want assets protected.  However, after developing a lot more with PW, I realize that this can be automated by hooking into saveready.  The idea is that if there is a flag set to protect the files for this page, copy the .htaccess file to the files directory.  Otherwise, delete it if it exists.

    At one point Ryan had said:

    But I think separating the dirs is the right way to go. Either that, or renaming protected page file directories with a "." in front of them, i.e. /site/assets/files/.1234/ That way, the htaccess file can recognize them ahead of time in a predefined manner. And PW's htaccess already blocks any files/dirs that start with a period.

    I haven't had a chance to really dive back into this issue (because the solution I've implemented works and it's a small-scale website) - but I think that if a module were built and hooked into saveready - instead of copying an .htaccess file, it simply renames the folder and adds the period at the beginning.  Of course, this has trickle down effects because PW itself would have to know that that's the new "location" of the folder so it doesn't always look for "files" instead of ".files".


    Just re-read your question.  I may have given you too much detail and not answered your question directly.

    The .htaccess file that I've manually added to the /sites/assets/files/xxxx directory handles the redirect.

  9. On the site I built that has protected files, I'm still using the .htaccess solution I described.  It has the pitfalls Ryan mentioned, and the solution isn't perfect or easily scaleable, but it works!  I definitely would be excited if this feature made it's way on the ProcessWire roadmap.

  10. For anyone else who runs into this issue, a quick, temporary fix is to hack the LanguageFunctions.php file.  For all three functions in there, you'll need to wrap each with a check to make sure the functions haven't already been declared.  For example, the first function:

    if (!function_exists ('__')){
        function __($text, $textdomain = null, $context = '') {
                ...snip...
        }
    }
    

    My best guess is that this not recommended as a permanent solution since it may cause issues with WordPress.  And of course, ProcessWire upgrades will overwrite the hack.

    Best solution? Don't use Wordpress. :)

    For reference, here's Ryan's awesome Blog Profile for ProcessWire.

    http://modules.processwire.com/modules/blog-profile/

    • Like 3
  11. I have a Wordpress blog installed in a subdirectory of a PW site (transferring the blog from WP to PW is on my task list) that was working with Processwire 2.2.9.  I just upgraded to 2.4 and it broke.   :(

    The error I'm getting is:

    Fatal error: Cannot redeclare __() (previously declared in /home/me/mydomain.com/blog/wp-includes/l10n.php:146) in /home/me/mydomain.com/wire/core/LanguageFunctions.php on line 39
    

    Any idea what I can do (temporarily) to get it up and running?

    Processwire is installed at the root of the domain and Wordpress is installed at /blog.

    EDIT: I don't have any of the Language Support modules installed.

  12. Yup - the new URL structure for maps doesn't work with the module but I was able to get it working by manually building the URL.  For example, this is the simple structure I used:

    https://maps.google.com/maps?q=Santa+Barbara+CA+93101
    

    That seems to work just fine - even in CKEditor.  :)  My guess is that Google will continue to support that URL structure for quite a while.  They've typically been pretty good at backwards compatibility and not implementing new methods that break old URLs.

    • Like 1
  13. so this way i will get all pages with the selected templatei thought it could be used as kind of templateblock in a page, which would be populated with certain content from the page.

    this way the editor could choose a special layout for a part (e.g. hero) of the page without messing up the code.

    Martijn is right - it's not as straightforward as it sounds.  I've tried to do that before and the solution I came up with was simply to use child pages.  Since each part of a page's content can look different, it may contain different content.  While a repeater COULD be used, it doesn't give as much flexibility.  It all really depends on what you're trying to do.

  14. I was having an issue with a 404 error appearing when adding an image using TinyMCE for a client once (see here: http://processwire.com/talk/topic/4340-tinymce-images-saving-leads-to-404/) - so I know mod_security rules can do funny things that cause issues with HTML in TinyMCE.  Perhaps look into that?

    (I ended up having the webhost, Liquidweb, help me out and they whitelisted the rules that were causing the issue.)

    • Like 1
  15. When calling rename() on a file where the same filename already exists in that pagefiles array, the unique name given to the target file doesn't follow the same convention used when uploading a file using WireUpload.  Is there a reason or was this just a carryover from old version of PW that never got revised?

    For example, I have two files in a file field.  The first being called "los_angeles.jpg" and the second called "new_york.jpg".  If I rename "new_york.jpg" (using rename() via the API, of course), the file ends up being called "1_angeles.jpg".

    If I were to upload a duplicate of "los_angeles.jpg" to the field normally from within ProcessWire, the file ends up being called "los_angeles-1.jpg" - which is arguably the better result.

    To fix this, I tweaked the cleanBasename function in Pagefiles.php in the core (gasp!).   :)

    I replaced the following:

    while(is_file($path . $basename)) {
            $basename = (++$n) . "_" . preg_replace('/^\d+_/', '', $basename);
    }
    

    With:

    $p = pathinfo($basename);
    while(is_file($path . $basename)) {
            $n++;
            $basename = "$p[filename]-$n.$p[extension]";
    }
    

    I don't think there are any negative trickle-down implications for doing this.  Is this something we can get changed in an upcoming build?

    Side note: just had to share that by inspecting the code, I learned about the pathinfo() function - which for some reason, I never knew about.  What an amazing little function!  Whenever I have needed to get a file's name and extension before, I'd do something that now seems embarrassingly amateurish (and now laughable):

    $filename = 'myfilename.jpg';
    $name = substr($filename , 0, strrpos( $filename , '.') );
    $ext = end( explode('.',$filename) );
    

    :-X

    • Like 1
  16. Yup - whenever I pull records from their database, it's MAINLY all or nothing.  I can pull just record IDs to see what records are still in their database - but that only serves to remove records on my end that are no longer in theirs.

    GREAT call about Ryan's Google Map Marker fieldtype!  That would totally work in this case.

  17. PHP 5.5 dropped JSON support due to the developer's aesotheric license.

    I was really intrigued by that (and getting mad at lawyers!), so I Googled for more info.  Apparently, it's not quite removed. There was widespread misunderstanding of what was going on.

    See here: http://iteration99.com/2013/php-json-removed-from-php-5-5/

    So, developers, rejoice! Workarounds won't be necessary when upgrading to 5.5 so long as you have the JSON-C extension installed.   :lol:

    • Like 3
×
×
  • Create New...