requinix

As said, PHP does not distinguish between 123 and 123.0. If you must have 123.0 then you need to do that manually. Which would suck. Are you absolutely sure it has to be a float? Have you tried an integer and the service is returning an error?

You're comparing with $first_name but you never update that value.

Right now I don't care about $json. Listen to me, okay? This code: <?php ini_set('display_errors',"1"); header('Content-Type: text/plain'); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://eu.myconnectwise.net/v2017_1/apis/3.0/services/tickets/13934"); curl_setopt($ch, CURLOPT_HTTPHEADER, array('Authorization: basic ' . base64_encode('#######'.'+'.'##########'.':'.'##########'))); curl_exec($ch); curl_close ($ch); ?>Put the right username and password in there, then run it. What is the output? If there's sensitive information then redact it, but otherwise post exactly what you see.

I know who and what you've speaking of and I haven't seen it happening. If it does happen to you then PM me directly about it. If you think it's happening to other people then use the reporting function and the staff will investigate, though we likely will not tell you what/if anything happens.

Do the work during an AJAX request, not on a regular page load, and then you can do anything you want: message, spinning thing, busy cursor, whatever.

Of course not: the API call is happening on your server, not in the browser. So how about we return to what I was asking about before. That test script I posted - what do you get if you run that?

Okay... Can you solve that problem on your own?

Try running just this: <?php ini_set('display_errors',"1"); header('Content-Type: text/plain'); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://eu.myconnectwise.net/v2017_1/apis/3.0/services/tickets/13934"); curl_setopt($ch, CURLOPT_HTTPHEADER, array('Authorization: basic ' . base64_encode('#######'.'+'.'##########'.':'.'##########'))); curl_exec($ch); curl_close ($ch); ?>

What is the contents of $json?

$.cookie can both get and set the cookie.

Access keys only work if you can assign them to each endpoint. You could do that for a mobile app, but that's not the best way to go about it. Access tokens would be more appropriate. Rather than send the login information for every request, requiring that you hold onto that information the whole time the user is on the app, you only log them in once. The server then returns a temporary token that can be used for subsequent requests in lieu of the credentials; it's time-restricted so the token doesn't last forever, and to keep the app working without requiring a login every 5 minutes you add to the API something which can generate a new token if requested (which the app would do when the token is close to expiring).

Oh. Here's a question I'll pose for you: If the browser is currently displaying the page at http://www.example.com/items/p/123/and you tell it to make an AJAX request to search.php url: "search.php",what do you think the full URL to that page will be?

As you can tell, RewriteRule ^items/p/([0-9]+)/?$ /items.php?page=$1has absolutely nothing in common with url: "search.php",So what do you mean by it's "blocking" scripts? Are you getting 404s? Or what? What else have you changed in the .htaccess recently?

Fix the code? You didn't post that part.

First, can you verify whether and when the cookie is being set? Forget the appearance of the page and look at the cookie directly through your browser's developer tools.

The cookie parameters need to be the same every time you access it. That means including path:/ when setting the cookie, not just when removing it. Are you sure that the cookie is not set? You've manually checked the value in your browser? So it's definitely not the case that the cookie is set correctly but the page is not showing the right... whatever it shows?

You'll need to use imagettftext instead: give it a path to a bold font (yes, the font itself must be bold) and whatever size you want. For centering you'll need imagettfbbox to determine the size of the rendered text, then you can calculate the correct offset for imagettftext so that the text is placed in the center. Google has suggestions on how to do that.

And saving uses the filename? Huh. Didn't know that.

Ubuntu probably means you're using Apache for the web server. (Or is it nginx?) Can you edit the virtualhost configuration? Are you using .htaccess files? And you should verify the caching thing I assumed first. Open up your browser's developer tools, look for a "network"-type thing that shows page requests, make sure it's enabled or activated or whatever so that it's working, then load up a page from the intranet site. The tool should then show you information about each page that was requested, including the Javascript and CSS files. Pick one of those. Somewhere in the details will be a list of the request and response headers - what are they?

Can you ask whether the mail is being sent immediately or being queued through a sendmail service? If immediately, is there a way you can make your emails be queued instead? Queuing will be much faster: sending requires connecting to the remote mail server, sending the contents of the mail, waiting for the server to validate everything and check you against spam services and whatnot, while queueing is just the amount of time it takes to save the email to the server (so it can go through the sending process later without impacting your script). Otherwise, short of moving to dedicated hosting where you could manage all this yourself (for better or worse), something like MailChimp will probably be your safest bet. Unless you wanted to implement the mail queue yourself, but I don't think I would recommend that in this case - if it's even possible given what you have access to.

Caching is set by something. Generally the server, since that's the one handling the files, but if you're passing these files through PHP code first (for some weird reason) then you'd have to be explicitly doing something about caching in there. If you didn't do anything then the server is likely using Expires: it instructs the browser to not even attempt to redownload the resource until some specific time has passed. That works well... up until you change the resource, so all in all it doesn't work well. What web server are you using? Are you the one who manages it?

If you don't mind forcing a download instead of presenting it in the browser then you can do header('Content-Disposition: attachment; filename="quote-123.pdf"');Otherwise make the URL to the PDF be something that ends in /quote-123.pdf. You can use URL rewriting (nicer) or change your /path/to/script.php to be like /path/to/script.php/quote-123.pdf which should still invoke your PHP script (easier).

Based on those numbers (which you got from code that I revised... but not fast enough) it took six seconds to send the email. That's slow. Talk to your hosting provider.

Oh, not your own hosting? Perfect. Complain to them that sending emails is slow and they can look into it. But first, be sure that it's not your code. Try a simple mail script <?php function udate() { list($us, $s) = explode(" ", microtime()); return date("Y-m-d H:i:s" . ltrim($us, "0"), $s); } header("Content-type: text/plain"); echo "Time before sending mail is: ", udate(), "\n"; mail("[email protected]", "Test", "The time is " . udate(), "From: [email protected]"); echo "Time after sending mail is: ", udate(), "\n"; and see how long it takes.

Fix your caching so that it correctly indicates when and when not to refresh a resource. How does it work right now? Maybe there's a site you can point us to?