Question 1

In PHP, what determines the maximum size of an uploaded file and how can you increase this limit?

Accepted Answer

Introduction / Context: File upload limits are a practical concern in many PHP applications, such as content management systems, image galleries, and document portals. When users see errors uploading large files, developers need to understand how PHP and the web server enforce size limits. Interview questions about maximum upload size test whether a candidate is familiar with php.ini configuration and the relationship between PHP and the HTTP request body. Given Data / Assumptions: PHP is running as a module or handler in a web server such as Apache or Nginx. File uploads are handled with HTML forms using method POST and enctype multipart/form-data. PHP reads the request body and enforces limits before populating the $_FILES superglobal. The system administrator or developer has access to php.ini or equivalent configuration. Concept / Approach: PHP uses several configuration directives to control how large an incoming request can be and how big each uploaded file may be. The most important are upload_max_filesize, which limits the size of uploaded files, and post_max_size, which limits the total size of the POST request, including all file and form fields. Another related directive is memory_limit, which may affect scripts that process large uploads in memory. To allow larger uploads, you must increase these values in php.ini or in a compatible configuration context such as .htaccess or virtual host configuration, depending on your hosting environment. Step-by-Step Solution: Step 1: Open php.ini or the relevant configuration file and locate the upload_max_filesize directive, which might be set to a default such as 2M or 8M. Step 2: Increase upload_max_filesize to the desired limit, for example 50M, making sure the unit suffix is correct. Step 3: Check the post_max_size directive and set it to at least the same value as upload_max_filesize, or slightly larger to account for form data overhead. Step 4: Verify that memory_limit is sufficient if your script reads entire files into memory for processing, adjusting it if necessary. Step 5: Save the changes and reload or restart the web server or PHP process manager so that the new limits take effect. Step 6: Optionally, ensure that the web server itself does not impose a lower limit on request size through directives such as LimitRequestBody. Verification / Alternative check: After changing configuration values, you can confirm the new limits by creating a small PHP script that calls phpinfo() to display current settings or by uploading files of different sizes and observing when uploads begin to fail. The behaviour should match the configured upload_max_filesize and post_max_size values. This confirms that these directives control the maximum upload size rather than fixed limits in the language or browser cache settings. Why Other Options Are Wrong: Option b is wrong because PHP does not hard code a universal 2 megabyte limit; the defaults can vary and are explicitly configurable. Option c is incorrect because the HTML size attribute affects display size in the browser, not server side upload limits. Option d is wrong because browser cache size is unrelated to how PHP parses and limits incoming HTTP requests; the server enforces upload constraints independently. Common Pitfalls: Developers sometimes increase upload_max_filesize but forget to adjust post_max_size, causing uploads to fail mysteriously when the request body is larger than post_max_size. Another pitfall is ignoring web server level limits or reverse proxy limits, which can block large requests before they reach PHP. Additionally, raising limits very high without considering security and resource usage can expose the application to denial of service risks. It is best to set these values just high enough for the application requirements and to provide user friendly error messages when limits are exceeded. Final Answer: The maximum upload size in PHP is controlled by configuration directives such as upload_max_filesize and post_max_size in php.ini, and you increase this limit by raising those values and reloading the web server or PHP process so that the new settings take effect.

Question 2

In PHP with MySQL, how can you find the number of rows in a result set returned by a SELECT query?

Accepted Answer

Introduction / Context: When working with relational databases from PHP, it is common to execute a SELECT query and then need to know how many rows were returned, for example to display totals, implement pagination, or perform conditional logic. PHP database extensions such as the legacy mysql extension and the newer mysqli extension provide specific functions to get the row count, and interview questions often check whether a candidate knows which functions are used and how to call them correctly. Given Data / Assumptions: A SELECT query has been executed against a MySQL database from PHP. The result of the query has been stored in a resource or result object, depending on the extension used. The code uses either the older mysql_* functions or the mysqli extension. The task is to count rows in the result set, not in the entire table. Concept / Approach: The key idea is that the database server returns a result set object or resource to PHP, and the PHP extension exposes a function that knows how many rows it contains. The legacy mysql extension provides mysql_num_rows($result), while the mysqli extension provides mysqli_num_rows($result). These functions return an integer count of rows in the result set returned by the last query associated with that resource or object. Using these functions is efficient because they rely on metadata that the database engine already knows after executing the query. Step-by-Step Solution: Step 1: Execute your SELECT query using functions such as mysql_query() or mysqli_query(), capturing the result into a variable, for example $result. Step 2: If you are using the mysql extension, call mysql_num_rows($result). If you are using the mysqli extension, call mysqli_num_rows($result). Both functions return the number of rows in the result set. Step 3: Use the returned integer to control program logic, such as displaying a message when zero rows are found or calculating the number of pages for pagination. Step 4: Remember that mysql_* functions are deprecated and removed in newer PHP versions; modern code should use mysqli or PDO, where row counts are obtained with extension specific methods. Step 5: Do not confuse the number of rows in a result set with the number of affected rows in insert or update operations, which are obtained with different functions such as mysqli_affected_rows(). Step 6: This sequence shows that using mysql_num_rows() or mysqli_num_rows() is the correct approach to find the row count of a SELECT result. Verification / Alternative check: You can verify this by running a simple script that queries a table with a known number of matching rows and then prints the value returned by mysql_num_rows() or mysqli_num_rows(). The printed number should match the expected count. Changing the query condition to narrow or broaden the result set will change the value accordingly, confirming that these functions operate on the result set, not on the raw SQL string or the physical table size. Why Other Options Are Wrong: Option b is wrong because count() on the SQL string measures the length of the string or the number of elements in an array, not the number of rows returned by the database. Option c is incorrect because inspecting table files on disk is not how application level code determines row counts and would be highly unreliable. Option d is wrong because there is no global ROW_COUNT constant set by PHP; row counts are associated with specific result sets or connections. Common Pitfalls: A common pitfall is to call mysql_num_rows() or mysqli_num_rows() on result sets of non SELECT queries, which can fail or return zero. Another is to rely on row count for large result sets when you really need a separate COUNT(*) query for performance reasons. With modern extensions such as PDO, developers must also remember that rowCount() may behave differently with SELECT statements depending on the driver. However, for basic MySQL usage with mysql or mysqli, mysql_num_rows() and mysqli_num_rows() remain the standard answer for counting rows in a SELECT result. Final Answer: You find the number of rows in a MySQL result set in PHP by calling mysql_num_rows() or mysqli_num_rows() on the result resource or result object returned by your SELECT query.

Question 3

In PHP, what is the functionality of the md5() function and when is it typically used?

Accepted Answer

Introduction / Context: The md5() function is one of the earliest and most widely recognised hashing functions in PHP. While it is now considered weak for cryptographic purposes, it still appears frequently in legacy code, tutorials, and interview questions. Knowing what md5() does, the format of its output, and where it is safe or unsafe to use is essential for any PHP developer who deals with security, data integrity, or legacy systems. Given Data / Assumptions: md5() takes a string input and returns a deterministic hash value. The output can be returned as a 32 character hexadecimal string or as raw binary data if the second parameter is true. MD5 is a one way hash function, not an encryption algorithm. Modern security practices discourage using MD5 alone for password storage due to known vulnerabilities. Concept / Approach: MD5 stands for Message Digest Algorithm 5. In PHP, md5() implements this algorithm and produces a fixed length hash of the input string. Hash functions map arbitrary length input to a fixed length output in a way that is designed to be hard to reverse. This has traditionally made MD5 suitable for checksums and basic integrity verification, such as comparing file downloads or detecting accidental changes. However, advances in computing power and the discovery of collisions mean that MD5 is no longer strong enough for serious cryptographic uses such as password hashing without additional safeguards. Step-by-Step Solution: Step 1: When you call md5($text) in PHP, the function computes the MD5 digest of the string $text. Step 2: By default, md5() returns a 32 character hexadecimal string that represents the 128 bit hash value. Step 3: If you pass true as the second argument, md5($text, true) returns the raw binary hash, which is less readable but slightly more compact. Step 4: Because the same input always produces the same output, you can store the hash value and later recompute it to check whether the original data has changed. Step 5: In older systems, developers sometimes stored md5 hashes of passwords in databases, but this is no longer considered safe because attackers can use rainbow tables and fast hardware to crack these hashes. Step 6: Today, md5() may still be used for non security critical checksums or as part of a larger scheme, but password storage should use stronger functions such as password_hash() with Bcrypt or Argon2. Verification / Alternative check: You can verify the behaviour of md5() by running small tests: md5("hello") will always return the same 32 character string across different systems. Changing even one character in the input will produce a completely different hash, illustrating the avalanche effect typical of hash functions. There is no built in md5_decrypt() because the hash cannot feasibly be reversed in a general sense, which confirms that md5() is a hashing function rather than a two way encryption function. Why Other Options Are Wrong: Option b is wrong because md5() is not two way encryption; it is one way and cannot be reliably reversed to retrieve the original string. Option c is incorrect because file compression into ZIP format is handled by separate functions or extensions, not by md5(). Option d is wrong because JSON encoding arrays uses json_encode(), not md5(), and produces structured text rather than a fixed length hash. Common Pitfalls: A common pitfall is continuing to use md5() for password storage in new projects, which exposes users to avoidable risk. Another issue is misunderstanding hash collisions; MD5 collisions mean that two different inputs may produce the same hash, which can be exploited in some attack scenarios. Developers should clearly distinguish between hashing and encryption, choose appropriate algorithms for each, and follow current best practices. For interview purposes, it is important to state both what md5() does and note that it is deprecated for sensitive security uses. Final Answer: The md5() function in PHP calculates a 128 bit MD5 hash of a string and usually returns a 32 character hexadecimal representation, which is suitable for simple checksums and integrity checks but not recommended as a standalone method for secure password storage.

Question 4

In PHP form handling, what are the main differences between the GET and POST HTTP methods when submitting a form?

Accepted Answer

Introduction / Context: In web development with PHP, HTML forms can submit data using different HTTP methods, most commonly GET and POST. Understanding the practical differences between these methods is essential for designing secure and user friendly applications. Interview questions about GET versus POST verify that a candidate knows how data is transmitted, how PHP reads it, and which method is more appropriate for different types of actions. Given Data / Assumptions: HTML forms include a method attribute that can be set to GET or POST. PHP exposes GET data through the $_GET superglobal and POST data through the $_POST superglobal. URLs have practical length limits enforced by browsers and servers. Sensitive data such as passwords should not be exposed in URLs. Concept / Approach: GET and POST differ mainly in how data is sent from the browser to the server. With GET, form parameters are appended to the URL as a query string, which is visible in the browser address bar and can be bookmarked or cached. With POST, form data is placed in the request body, which does not appear in the URL and is better for sending larger or more sensitive data. On the PHP side, both methods are accessible and processed similarly, but their semantics and typical use cases differ: GET is generally used for safe, idempotent requests like searches or filters, while POST is used for actions that change server state such as creating new records or submitting forms with files. Step-by-Step Solution: Step 1: When a form uses method="GET", the browser constructs a URL like example.php?name=John&age=20 and sends it with minimal or no request body. Step 2: PHP receives this request and populates the $_GET array with key value pairs parsed from the query string. Step 3: Because the query string is part of the URL, it is visible in the browser, may be logged in server logs, and is subject to length limits that make sending very large data impractical. Step 4: When the form uses method="POST", the browser sends the same parameters in the HTTP request body, and PHP populates the $_POST array with them. Step 5: POST requests can carry much larger payloads, especially when combined with enctype="multipart/form-data" for file uploads, and the data does not appear in the URL. Step 6: For these reasons, the main difference is about where data is placed (URL versus body), visibility, typical size limits, and appropriate use cases, which is correctly summarised by option a. Verification / Alternative check: You can verify these differences by building two simple forms, one using GET and one using POST, and submitting them to the same PHP script. Inspect the browser address bar and server logs to see that GET parameters are visible in the URL and can be bookmarked, while POST parameters are not. Tools like browser developer panels will show that POST sends data in the request body, confirming the conceptual explanation above. Why Other Options Are Wrong: Option b is wrong because neither GET nor POST automatically encrypts data; encryption requires HTTPS at the transport layer. Option c is incorrect because both methods can be used any number of times. Option d is wrong because GET and POST are HTTP protocol concepts and are not tied to any specific server side language; PHP, Python, Java, and others all support them. Common Pitfalls: A common pitfall is using GET for actions that change data, which can lead to unexpected repeats when users refresh or share URLs. Another issue is placing sensitive information such as passwords, tokens, or personal data in GET parameters, which can leak through browser history or logs. Best practice is to use GET for safe, read only queries that can be bookmarked and use POST for state changing operations and larger or sensitive payloads, always over HTTPS when security is important. Final Answer: GET sends form data as a query string in the URL with visibility and length limits, while POST sends form data in the request body, supports larger amounts of data, and is better suited to sensitive or binary data and operations that change server state.

Question 5

In PHP web applications, what is a session and why is it used?

Accepted Answer

Introduction / Context: HTTP is a stateless protocol, which means that each request from a browser to a server is independent and the server does not automatically remember previous interactions. PHP sessions provide a way to add state on top of HTTP, allowing applications to remember logged in users, shopping carts, preferences, and other user specific information. Interview questions about sessions test whether developers understand this concept and know how PHP uses session identifiers and server side storage. Given Data / Assumptions: HTTP requests do not inherently maintain state between page loads. PHP has built in session handling that can be started with session_start(). Each session has a unique session ID that links the browser to server side data. Session data is typically stored on the server in files, memory, or another storage system. Concept / Approach: A PHP session is a server side data store keyed by a session ID. When session_start() is called, PHP either creates a new session or resumes an existing one based on the session ID sent by the client, usually in a cookie named PHPSESSID. The application can then store values in the $_SESSION superglobal, which PHP persists between requests. On the next request, if the browser sends the same session ID, PHP reloads the associated data, effectively giving the application memory of previous interactions for that user. Step-by-Step Solution: Step 1: When the first request from a user arrives and session_start() is called, PHP generates a random session ID and creates an empty data store for that session. Step 2: PHP sends the session ID back to the browser, normally as a cookie, so that the browser can send it with future requests to the same site. Step 3: The application stores values in $_SESSION, such as user id, role, or shopping cart contents, and PHP writes these values to server side storage under that session ID. Step 4: On subsequent requests, the browser automatically sends the session ID cookie, PHP looks up the stored data, and $_SESSION is repopulated, allowing the application to continue the user session. Step 5: When the session is no longer needed, the application can clear or destroy it, or it will eventually expire based on configuration and garbage collection. Step 6: This process demonstrates that sessions are a server side state mechanism, not merely client side variables or static files. Verification / Alternative check: You can verify how sessions work by creating a simple script that calls session_start(), increments a counter in $_SESSION, and displays the value. Refreshing the page will increase the counter, showing that the server remembers state between requests. Deleting the session cookie or closing the browser may reset the session depending on configuration. Inspecting the server session directory will reveal files keyed by session IDs, confirming that session data is stored on the server. Why Other Options Are Wrong: Option b is wrong because while JavaScript can store client side data, PHP sessions are specifically server side, with only the session ID shared with the client. Option c is incorrect because configuration files such as php.ini define settings but are not called sessions. Option d is wrong because caching static HTML is a different performance technique and does not identify individual users or store user specific variables. Common Pitfalls: Common pitfalls with sessions include storing too much data in them, leading to large session files or memory use, and failing to regenerate session IDs after login, which can expose applications to session fixation attacks. Another issue is relying on URL based session IDs, which can leak through logs or bookmarks. Best practice is to use secure cookies for session IDs, regenerate IDs when privileges change, and store only necessary data in sessions. Understanding these details is important for both functionality and security. Final Answer: A PHP session is a server side mechanism that stores user specific data across multiple requests, linked to a browser by a session ID that is usually sent in a cookie or URL parameter.

Question 6

In PHP, how can you destroy a single session variable and how can you destroy the entire session?

Accepted Answer

Introduction / Context: Managing session lifecycle is vital in PHP applications, especially for security sensitive features such as user logins. Developers need to know how to remove individual session variables, for example when a temporary flag is no longer needed, and how to completely destroy a session when a user logs out. Interview questions about destroying sessions check whether developers understand both the PHP API and the difference between unsetting variables and ending the entire session. Given Data / Assumptions: A PHP session has been started with session_start(). Data is stored in the $_SESSION superglobal as key value pairs. Session data is stored on the server, and the session ID is stored on the client, usually in a cookie. The question asks about removing a particular variable and destroying the whole session. Concept / Approach: PHP sessions are represented by the $_SESSION array in the script and by a session file or other storage on the server. Removing one variable from the session usually means unsetting its entry in $_SESSION. Destroying the entire session involves clearing all session variables and removing the session data on the server, as well as invalidating the session ID. PHP provides functions such as unset(), session_unset(), and session_destroy() to handle these tasks. Correct use of these functions ensures that sensitive information is not left accessible after logout. Step-by-Step Solution: Step 1: To remove a single session variable, call unset() on the corresponding key in $_SESSION, for example unset($_SESSION["cart"]); this removes only that entry while leaving the session itself active. Step 2: To clear all session variables for the current session, you can call session_unset(), which empties the $_SESSION array for the running script. Step 3: To destroy the session data on the server and mark the session ID as no longer valid, call session_destroy() after session_start(). This deletes the session storage but does not automatically clear the superglobal or cookies. Step 4: A typical logout sequence is to call session_start(), then session_unset(), then session_destroy(), and optionally delete the session cookie by setting it with an expiry time in the past. Step 5: After these steps, any further requests with the old session ID will not resume the previous session because the data was removed on the server. Step 6: This method ensures both partial and complete removal of session data as required by application logic. Verification / Alternative check: You can test these behaviours in a simple script by starting a session, setting some $_SESSION values, and then unsetting one of them while printing the array. The removed key will no longer appear. In another script, call session_unset() and session_destroy() and observe that a subsequent request does not retain the previous session data. Checking the server session storage directory will show that the session file has been removed or invalidated. Why Other Options Are Wrong: Option b is wrong because deleting a cookie in the browser does not by itself remove server side session files, and restarting the server does not necessarily clear session storage unless configured specifically to do so. Option c is incorrect because exit() simply stops script execution; it does not automatically clean up sessions. Option d is wrong because renaming the script file does not affect existing sessions that may have been created by other requests or scripts. Common Pitfalls: A common pitfall is to call session_destroy() without first calling session_start(), which prevents the function from working as expected. Another issue is forgetting to invalidate the session cookie, which can lead to confusing behaviour on the client side. It is also important not to rely on partial clearing when a full logout is required; leaving sensitive keys inside $_SESSION can create security risks. Following the recommended sequence of unsetting specific keys, clearing all variables when needed, destroying the session, and expiring the cookie helps ensure that user sessions are properly terminated. Final Answer: To delete one session variable you unset the corresponding entry in $_SESSION, and to destroy the entire session you typically call session_unset() followed by session_destroy(), optionally deleting the session cookie as part of a full logout process.

Question 7

In PHP, what is the difference between include(), include_once(), require(), and require_once()?

Accepted Answer

Introduction / Context: File inclusion is a central part of structuring PHP applications. Developers use include and require to pull in shared code, configuration, and templates. Understanding the differences between include(), include_once(), require(), and require_once() is important for error handling and for avoiding duplicate inclusion of the same file. Interviewers often ask this question to confirm that candidates can choose the appropriate inclusion mechanism for different scenarios. Given Data / Assumptions: All four constructs are used to insert and execute code from another file. The target file path may be correct or may be missing due to misconfiguration. Some files, such as configuration or core library files, must be available or the application should stop. Other files can be optional, where the application may continue even if they are missing. Concept / Approach: include() and require() behave similarly in that they read a specified file and execute it in the current script context. The key difference lies in error handling: include() issues a warning if the file cannot be loaded but allows the script to continue, while require() triggers a fatal error and stops execution. The include_once() and require_once() variants add another layer of behaviour by tracking whether a file has already been included and preventing it from being included more than once, which helps avoid redeclaration errors for functions and classes. Step-by-Step Solution: Step 1: When include("file.php") is called and file.php is found, its code is executed at that point in the script. If file.php is missing, PHP emits a warning but continues running the remaining code. Step 2: When require("file.php") is called and file.php is found, its code is also executed. If file.php is missing, PHP emits a fatal error and stops script execution immediately, preventing further code from running. Step 3: include_once("file.php") behaves like include() but checks whether file.php has already been included earlier in the request. If it has, the file is not included again. Step 4: require_once("file.php") behaves like require() with the added guarantee that the file is loaded only once, even if the statement is encountered multiple times. Step 5: Developers typically use require or require_once for critical files such as configuration and core libraries that must be present, and include or include_once for optional components or templates. Step 6: This behaviour matches the description in option a, which distinguishes error handling and single inclusion semantics. Verification / Alternative check: You can verify these differences with a small test script that attempts to include a non existent file using include() and require(). With include(), the script will show a warning and continue to execute subsequent echo statements; with require(), the script will terminate at the point of the missing file error. Replacing include with include_once and repeating the call will show that the file is loaded only once when it exists, preventing multiple execution of the same code. Why Other Options Are Wrong: Option b is wrong because include() does not stop the script on failure, and include_once() and require_once() are not specific to image files. Option c is incorrect because both include() and require() can load local or remote files depending on configuration, and the *_once forms are not deprecated aliases but actively used constructs. Option d is wrong because require() executes PHP code just like include(); it does not restrict itself to plain text. Common Pitfalls: Common pitfalls include using include() for critical files, which can lead to partially running code if those files are missing, and using plain include instead of include_once or require_once for library files, which can cause redeclaration errors. Another issue is relying on include paths or relative paths without understanding how they are resolved, leading to hard to debug failures. Best practice is to use require_once for essential, single load files and include or include_once for nonessential or repeatable inclusion, always with clear and reliable paths. Final Answer: include() and require() both load and execute code from another file, but include() only raises a warning if the file is missing while require() stops the script with a fatal error, and include_once() and require_once() add the guarantee that the file is included at most one time in a request.

Question 8

In PHP regular expressions, how can you extract the domain abc.com from the string https://info@abc.com?

Accepted Answer

Introduction / Context: String processing and regular expressions are very common tasks in PHP applications, especially for validating and parsing email addresses, URLs, and log lines. Extracting a domain name from a mixed string that contains protocol and user information is a typical example. Interview questions like this check whether the candidate understands how to build capturing groups with preg_match() and how to use character classes to capture only the needed portion. Given Data / Assumptions: The input string looks like https://info@abc.com and contains a protocol prefix, a user part, and a domain part. We want to extract the domain abc.com, which appears after the @ symbol. We are allowed to use PHP regular expression functions such as preg_match(). The question focuses on the idea of using a capturing group to isolate the domain portion. Concept / Approach: The core idea is to design a regular expression that looks for the @ character and then captures everything that follows up to a delimiter such as a slash or the end of the string. In PHP, preg_match() can apply this pattern to the string and return matches in an array, where the first capturing group contains the domain. The exact pattern can vary, but it generally uses a group with a character class that excludes slashes or whitespace, ensuring that only the domain name is captured. This approach is efficient and avoids complex manual parsing. Step-by-Step Solution: Step 1: Identify that the domain we want begins immediately after the @ symbol in the string https://info@abc.com. Step 2: Construct a regular expression that matches the @ symbol and then captures one or more characters that are not slashes or spaces, for example /@([^\/]+)/. Step 3: In this pattern, @ matches the literal at symbol, and the group ([^\/]+) captures one or more characters that are not a slash or backslash, which in the example corresponds to abc.com. Step 4: Call preg_match($pattern, $string, $matches) in PHP, where $pattern is the chosen regular expression and $string is the full input. Step 5: After a successful match, $matches[1] contains the value abc.com, which is the domain we wanted to extract. Step 6: This demonstrates a general strategy for extracting domains from similar strings using capturing groups in PHP regular expressions. Verification / Alternative check: You can test this approach by running a short PHP script that defines $string as https://info@abc.com, applies preg_match(), and prints $matches[1]. The result should be abc.com. Trying the same pattern on other strings that follow a similar structure confirms that the capturing group isolates the domain part. Minor adjustments to the pattern can handle more complex cases, but the underlying method remains the same. Why Other Options Are Wrong: Option b is wrong because md5() produces a one way hash; it cannot be reversed to obtain the domain. Option c is incorrect because exploding on every character and manually rebuilding the domain is unnecessary and fragile compared to using regex or string functions. Option d is wrong because PHP does not provide a built in get_domain() function that automatically extracts domains from arbitrary strings. Common Pitfalls: A common pitfall is writing overly strict or overly loose patterns that fail on valid inputs or match too much. Another issue is forgetting to escape special characters like the slash in regular expressions. When working with user provided URLs or email addresses, developers should also consider validation and normalisation rather than relying on simple splits. Nonetheless, understanding how to use preg_match() with capturing groups is a fundamental skill, and extracting abc.com from https://info@abc.com is a straightforward example. Final Answer: You can extract abc.com by using preg_match() with a pattern that matches @ and captures the following characters into a group, for example /@([^\/]+)/, then reading the first capturing group from the matches array.

Question 9

In PHP, what major types of runtime and compile time errors can be generated by the engine?

Accepted Answer

Introduction / Context: Understanding PHP error types is essential for debugging and writing robust applications. Different error categories indicate different problems, such as syntax mistakes, missing functions, or non critical issues that the script can recover from. Interview questions often ask about error types to ensure that developers know how PHP reports problems and how script execution is affected by each category. Given Data / Assumptions: PHP has a built in error handling system that classifies errors by severity. Typical categories include parse errors, fatal errors, warnings, and notices. Configuration settings such as error_reporting and display_errors control visibility of these errors. The question focuses on conceptual types, not numeric error codes. Concept / Approach: Parse errors occur at compile time when PHP interprets the script and finds invalid syntax, such as missing semicolons or incorrect parentheses. Fatal errors occur at runtime when PHP encounters a problem that it cannot recover from, such as calling an undefined function or running out of memory. Warnings are non fatal issues, like including a missing file with include(), where the script can continue but behaviour may be incorrect. Notices indicate minor problems such as using an undefined variable, which usually do not stop execution but can signal poor coding practices. Step-by-Step Solution: Step 1: Parse errors (compile time errors) are generated when PHP reads the script and detects invalid syntax before executing any code. These errors prevent the script from running at all until the syntax is corrected. Step 2: Fatal errors happen during execution when PHP reaches a state it cannot handle, for example trying to call a function that does not exist. Execution stops at the point of the fatal error. Step 3: Warnings signal problems that are serious but not fatal, such as an included file missing when using include(). PHP logs a warning and continues to execute the rest of the script, which may still produce output. Step 4: Notices inform developers of minor issues like reading an undefined variable or using an uninitialised index. The script continues running, but developers should fix these issues for clean code and predictable behaviour. Step 5: PHP also has other related levels such as strict standards messages and deprecated notices in older versions, but parse errors, fatal errors, warnings, and notices are the main categories. Step 6: This set of categories matches option a, which accurately summarises the major PHP error types. Verification / Alternative check: You can verify these categories by writing simple test scripts that deliberately cause different errors. A missing semicolon will produce a parse error. Calling an undefined function will cause a fatal error. Including a non existent file with include() will trigger a warning, while using an undefined variable will generate a notice if error reporting is configured to show it. Observing how each case affects script execution confirms the differences between these error types. Why Other Options Are Wrong: Option b is wrong because blue screen errors refer to operating system crashes, not PHP level error reporting. Option c is incorrect because PHP clearly distinguishes between syntax errors and runtime errors and has warnings and notices. Option d is wrong because PHP errors originate on the server side and are only sent to the browser as output or logs if configured. Common Pitfalls: A common pitfall is hiding errors in production by turning off error reporting completely, which can make troubleshooting much harder. A better approach is to log errors to files while displaying friendly messages to users. Another issue is ignoring notices and warnings, which can mask real bugs and lead to unpredictable behaviour. Developers should aim for code that runs cleanly with strict error_reporting settings in development, addressing parse errors, fatal errors, warnings, and notices promptly. Final Answer: PHP defines several major error types, including parse errors, fatal errors, warnings, and notices, each indicating a different severity level and having a different impact on whether the script can continue running.

Question 10

In PHP, what is the functionality of strstr() and how does stristr() differ from it?

Accepted Answer

Introduction / Context: String search operations are common in PHP, and the strstr() and stristr() functions provide simple ways to find substrings. While they seem similar, they differ in how they treat letter case. Interview questions often ask about these functions to verify that a candidate understands case sensitivity in string operations and can choose the appropriate function for different scenarios. Given Data / Assumptions: We are working with plain PHP strings. strstr() and stristr() both take a haystack string and a needle substring. The functions return either a portion of the string or false on failure. The main difference between them is case sensitivity. Concept / Approach: strstr() searches for the first occurrence of a substring within a string, respecting case, and returns the part of the string from that position to the end. If the substring is not found, it returns false. stristr() has the same basic behaviour but ignores case differences between the haystack and the needle, making it useful when you want to find a substring without worrying about whether it is written in upper or lower case. Both functions can optionally return the part before the match when the third parameter is used in newer PHP versions. Step-by-Step Solution: Step 1: For example, strstr("Hello World", "World") returns "World" because it finds the substring World exactly as written and returns from that position to the end of the string. Step 2: If you call strstr("Hello World", "world"), the function returns false because the lowercase w does not match the uppercase W when case sensitivity is enforced. Step 3: Using stristr("Hello World", "world") instead returns "World" because stristr() performs a case insensitive search and treats World and world as equivalent. Step 4: In both cases, the primary behaviour is to locate the first occurrence of the needle and return the rest of the string starting from that position, or false if no match is found. Step 5: Some code uses these functions to test whether a substring exists by comparing the return value to false, while others may use the returned string for further processing. Step 6: From this discussion, it is clear that the main difference is case sensitivity, matching the description in option a. Verification / Alternative check: You can verify this behaviour by running short PHP scripts that call strstr() and stristr() with various combinations of upper and lower case strings. The outputs will show that strstr() fails when case does not match, while stristr() still finds the substring. Additional experiments with the optional before needle parameter in newer PHP versions will show that both functions share the same extended capabilities beyond simple case handling. Why Other Options Are Wrong: Option b is wrong because neither function reverses or sorts strings; they only search for substrings. Option c is incorrect because both functions operate on strings, not arrays or purely numeric values as separate types. Option d is wrong because strstr() and stristr() are string search functions, not hashing functions, and have nothing to do with md5() or sha1(). Common Pitfalls: Common pitfalls include forgetting to check for false explicitly and instead using the returned string in a context where an empty string or false has different meaning. Another issue is overlooking the performance cost of repeated substring searches on large strings. Developers should choose stristr() only when case insensitive matching is necessary and prefer strstr() when exact matching is required. Understanding the difference helps avoid subtle bugs when matching user input or processing text data. Final Answer: strstr() and stristr() both search a string for a substring and return the part of the string from the first match onward, but strstr() is case sensitive whereas stristr() performs a case insensitive search.

Question 11

In PHP using the old mysql extension, what are the differences between mysql_fetch_array(), mysql_fetch_object(), and mysql_fetch_row()?

Accepted Answer

Introduction / Context: Before mysqli and PDO became standard, many PHP applications used the mysql_* extension to work with MySQL databases. Even though this extension is deprecated, it still appears in older code and interview questions. Understanding the differences between mysql_fetch_array(), mysql_fetch_object(), and mysql_fetch_row() helps developers read and maintain legacy code and understand the general idea of how database fetch functions can return results in different formats. Given Data / Assumptions: A SELECT query has been executed with mysql_query() and returned a result resource. We want to fetch rows one by one from this result set. Each row contains one or more columns with names and positions. Different fetch functions return rows in different structures. Concept / Approach: mysql_fetch_array() is a flexible function that returns a row as an array containing both numeric indexes (0, 1, 2, and so on) and associative indexes keyed by column names, unless a different fetch type is specified. mysql_fetch_object() returns the row as an object where each column is accessible as a property with the same name as the column. mysql_fetch_row() is a simpler function that returns a row as a numeric array only, where indexes correspond to column positions. Choosing between them depends on coding style and performance considerations. Step-by-Step Solution: Step 1: If you call mysql_fetch_array($result) without a second parameter, it returns an array where you can access a column named name as $row["name"] and also as $row[0] if it is the first column. This combined behaviour is flexible but may use more memory. Step 2: mysql_fetch_object($result) returns an object instead of an array. If there is a column named name, you access it as $row->name. This style is convenient for object oriented code and can make templates more readable. Step 3: mysql_fetch_row($result) returns a numeric array such as $row[0], $row[1], and so on. There are no associative keys; you must remember the order of columns in the query to interpret values correctly. Step 4: All three functions fetch the next row from the result set or return false when there are no more rows, and each call moves the internal pointer forward. Step 5: Developers may choose mysql_fetch_row() when they care about speed and minimal memory, mysql_fetch_array() when they want convenient access by name or position, and mysql_fetch_object() when they prefer property style access. Step 6: This behaviour matches the description in option a, which correctly distinguishes the return formats. Verification / Alternative check: You can verify these differences by executing a simple query such as SELECT id, name FROM a test table and then fetching one row with each function and printing the result with var_dump(). mysql_fetch_array() will show both numeric and associative keys, mysql_fetch_object() will show an object with id and name properties, and mysql_fetch_row() will show a simple numeric array. These experiments confirm that the three functions differ primarily in how they structure the returned row. Why Other Options Are Wrong: Option b is wrong because the functions are not identical and do not always return associative arrays. Option c is incorrect because it reverses roles and claims that one of the functions always throws an error, which is not correct in normal use. Option d is wrong because these functions are used only for fetching results from select queries; they do not apply to insert, update, or delete operations, which do not return result sets in the same way. Common Pitfalls: A common pitfall is to use mysql_fetch_array() without specifying a fetch type and then accidentally process the same data twice because both numeric and associative indexes exist. Another issue is failing to handle the case where the fetch function returns false, which can lead to warnings when code tries to access properties or indexes on a non array or non object. In modern PHP, developers should use mysqli or PDO instead, but understanding these legacy functions remains important when maintaining older systems. Final Answer: mysql_fetch_array() returns a row as an array with both associative and numeric indexes, mysql_fetch_object() returns a row as an object with properties named after the columns, and mysql_fetch_row() returns a row as a numeric indexed array only.

Question 12

In PHP, which functions are commonly used for hashing and encryption of data?

Accepted Answer

Introduction / Context: Security is a critical aspect of modern web applications, and PHP includes many functions to help with hashing and encryption tasks. Interview questions often probe whether candidates can distinguish between hashing and encryption and whether they know some of the commonly used PHP functions for each. This understanding is essential for handling passwords, tokens, and confidential data properly. Given Data / Assumptions: Hashing is a one way process that converts data into a fixed length digest. Encryption is a two way process that transforms data into an unreadable form that can be reversed with a key. PHP includes built in functions and extensions for both hashing and encryption. The question asks for examples of these functions, not an exhaustive list. Concept / Approach: For hashing general data, PHP offers functions like md5() and sha1(), as well as the more flexible hash() function, which supports many algorithms such as sha256 and others. For secure password storage, newer PHP versions provide password_hash() and password_verify(), which implement strong hashing algorithms and automatic salting. For encryption and decryption, PHP exposes functions through extensions such as OpenSSL, where openssl_encrypt() and openssl_decrypt() can perform symmetric encryption using algorithms like AES when provided with a key and appropriate options. Step-by-Step Solution: Step 1: For simple checksums or legacy code, md5($data) and sha1($data) generate fixed length hashes, though they are not recommended for new high security uses. Step 2: For more flexibility, hash($algo, $data) allows you to choose from many algorithms supported by the underlying system, for example hash("sha256", $data). Step 3: For password storage, password_hash($password, PASSWORD_DEFAULT) creates a strong hash with a salt, and password_verify($password, $hash) checks user input against that stored hash in a secure way. Step 4: For encryption that can be reversed, you can use openssl_encrypt($plaintext, $cipher, $key, $options, $iv) and openssl_decrypt($ciphertext, $cipher, $key, $options, $iv), where $cipher might be aes-256-cbc and $iv is an initialisation vector. Step 5: PHP also has other cryptographic helpers, such as random_bytes() or openssl_random_pseudo_bytes() for generating random values used in keys or tokens. Step 6: These examples illustrate that PHP includes distinct sets of functions for hashing and encryption, which are captured by option a. Verification / Alternative check: You can verify these functions by reading PHP documentation or by writing small scripts that compute hashes or encrypt and decrypt sample strings. For example, hashing the same string with md5() and sha1() will produce different fixed length digests, while using openssl_encrypt() followed by openssl_decrypt() with the same key and parameters will recover the original plaintext, confirming the distinction between one way hashing and reversible encryption. Why Other Options Are Wrong: Option b is wrong because print() simply outputs text and does not perform any cryptographic transformation. Option c is incorrect because PHP ships with built in functions for hashing and encryption; it does not rely exclusively on external tools. Option d is wrong because mail() sends email; it is not designed as a security function and does not inherently hide or protect data. Common Pitfalls: A common pitfall is using simple hashing functions such as md5() or sha1() directly for password storage without salting or stretching, which is insecure against modern attacks. Another issue is misusing encryption functions without understanding key management, initialisation vectors, or cipher modes, which can lead to weak protection. Best practice is to use password_hash() and password_verify() for passwords and to follow established guidelines when using openssl_encrypt() for other sensitive data. Distinguishing clearly between hashing and encryption and knowing the main PHP functions for each is essential for writing secure code. Final Answer: PHP provides hashing functions such as md5(), sha1(), and hash(), secure password hashing via password_hash(), and encryption and decryption functions through extensions such as openssl_encrypt() and openssl_decrypt(), which together cover common hashing and encryption needs in PHP applications.

Question 13

In PHP, how do you set a cookie from the server to the client browser?

Accepted Answer

Introduction / Context: Cookies are small pieces of data stored on the client browser and sent with each request to the server for a given domain. PHP makes it easy to set and read cookies, which are commonly used for remembering user preferences, session identifiers, or tracking data. Interview questions about cookies usually focus on the setcookie() function and the requirement that HTTP headers must be sent before any body output. Given Data / Assumptions: Cookies are transmitted in HTTP headers called Set-Cookie from server to client and as Cookie headers from client to server. PHP scripts can set cookies only before any output is sent, because headers must precede the response body. The $_COOKIE array in PHP holds cookies that the browser has already sent with the current request. We want to know how to set a cookie from PHP to the browser. Concept / Approach: setcookie() is the primary PHP function used to instruct the server to send a Set-Cookie header. It takes parameters including the cookie name, value, expiry time as a Unix timestamp, path, domain, and security flags. When setcookie() is called, PHP adds the appropriate header to the response. The browser receives this header, stores the cookie, and then sends it back on subsequent requests to the same domain and path. Directly modifying $_COOKIE does not send headers; it only changes the local representation for the current request. Step-by-Step Solution: Step 1: At the top of your PHP script, before echoing any HTML or whitespace, call setcookie("username", "Alice", time() + 3600, "/"). This creates a cookie named username with value Alice that expires in one hour, valid for the entire site. Step 2: PHP attaches a Set-Cookie header to the HTTP response, which might look like Set-Cookie: username=Alice; expires=...; path=/. Step 3: The browser receives the response, stores the cookie locally, and on the next request to the same domain and path sends Cookie: username=Alice in the request headers. Step 4: PHP reads these headers and populates $_COOKIE["username"] for the next request, allowing the application to access the stored value. Step 5: If you need security features, you can set the secure flag to restrict the cookie to HTTPS and httponly to prevent JavaScript from accessing the cookie. Step 6: This sequence demonstrates that setcookie() is the correct and standard way to set cookies in PHP. Verification / Alternative check: You can verify cookie behaviour by writing a script that calls setcookie() and then redirects or prints a message. Using browser developer tools, inspect the response headers to see the Set-Cookie line and inspect subsequent requests to see the Cookie header sent back to the server. You will also see the cookie listed in the browser cookie storage for the domain. Trying to set a cookie after output has been sent will produce a warning about headers already being sent, confirming that setcookie() must be called before output. Why Other Options Are Wrong: Option b is wrong because assigning values to $_COOKIE only changes the server side array for the current request; it does not create or update browser cookies. Option c is incorrect because browsers do not read arbitrary text files from the server to obtain cookie data; cookies are controlled strictly through HTTP headers. Option d is wrong because there is no HTML tag called cookie; cookies are not defined in markup but in headers. Common Pitfalls: Common pitfalls include calling setcookie() after echoing content, which causes headers already sent errors, and forgetting to set appropriate flags such as secure and httponly for sensitive cookies. Another issue is neglecting to specify an expiry time, which creates a session cookie that disappears when the browser is closed, which may or may not be desired. Developers should carefully design cookie lifetimes and scopes and always use HTTPS for cookies that carry sensitive information. Final Answer: You set a cookie in PHP by calling setcookie() with at least a name and value, and optionally expiry and other parameters, before any output is sent so that PHP can send the appropriate Set-Cookie header to the browser.

Question 14

In PHP, how can you calculate the number of days between two given dates?

Accepted Answer

Introduction / Context: Calculating the difference between two dates is a common requirement in PHP applications, for example to find subscription duration, age, deadlines, or reporting periods. PHP offers multiple ways to handle dates and times, including Unix timestamps and the DateTime class. Interview questions often ask for a simple method to compute the number of days between two dates to see whether a candidate understands basic date handling. Given Data / Assumptions: Two dates are provided, either as strings or as date objects. We want the difference in whole days between them. PHP has built in functions like strtotime() and classes like DateTime and DateInterval. Time zones and partial days may need to be considered depending on the use case. Concept / Approach: One common approach is to convert both dates into Unix timestamps, which count seconds since a reference point, then subtract the timestamps and divide by the number of seconds in a day. Another approach uses DateTime objects and their diff() method, which returns a DateInterval containing the number of days. Both approaches rely on PHP normalising dates into consistent internal representations before performing arithmetic. Step-by-Step Solution: Step 1: If dates are given as strings such as 2024-01-01 and 2024-01-10, call strtotime() on each string to convert them into timestamps: $t1 = strtotime($date1) and $t2 = strtotime($date2). Step 2: Compute the absolute difference in seconds: $diffSeconds = abs($t2 - $t1). Step 3: Divide by the number of seconds in a day to get the number of days: $days = $diffSeconds / (60 * 60 * 24). Depending on requirements, you can round or floor the result. Step 4: Alternatively, create DateTime objects: $d1 = new DateTime($date1) and $d2 = new DateTime($date2). Step 5: Call $interval = $d1->diff($d2); then read $interval->days, which gives the total number of days difference as an integer. Step 6: Both methods show that converting to timestamps or using DateTime is the standard way to calculate day differences, not manually subtracting parts of the strings. Verification / Alternative check: You can verify these steps by testing with known dates. For example, the difference between 2024-01-01 and 2024-01-11 should be 10 days. Running both the timestamp method and the DateTime diff() method should produce the same result. Testing around month and year boundaries, such as from 2023-12-31 to 2024-01-01, further confirms that PHP correctly handles calendar transitions. Why Other Options Are Wrong: Option b is wrong because subtracting only the day parts of date strings ignores changes in months and years and will fail for dates across such boundaries. Option c is incorrect because there is no built in php_days_between() function; developers must use existing date and time functions. Option d is wrong because there is no global constant that magically holds day differences; date arithmetic must be done explicitly. Common Pitfalls: A common pitfall is ignoring time zones or times of day, which can lead to off by one errors if the two timestamps are at different times or across daylight saving changes. Another issue is integer division and rounding; developers should clearly decide whether to count partial days as full days or floor the result to whole days. Using DateTime and DateInterval often simplifies handling of edge cases, while the timestamp approach offers a clear and flexible method. In any case, the essential idea is to convert dates to a numeric representation, subtract, and then convert the difference into days. Final Answer: You find the number of days between two dates in PHP by converting both dates to timestamps or DateTime objects, subtracting them to get a difference in seconds, and then dividing by 60 * 60 * 24 or using the DateTime diff() result to obtain the day count.

Question 15

In PHP file uploads, how do you move an uploaded file from its temporary location to the final destination on the server?

Accepted Answer

Introduction / Context: Handling file uploads securely and correctly is a common requirement in PHP applications. When a user uploads a file through an HTML form, PHP stores the file temporarily on the server and provides information about it in the $_FILES superglobal array. Developers must then decide where to store the file permanently. The move_uploaded_file() function is specifically designed for this purpose, and interview questions often focus on its use and security implications. Given Data / Assumptions: The HTML form uses method POST and enctype multipart/form-data to upload a file. PHP receives the file and stores it in a temporary directory, making its details available in $_FILES. We need to move the file from the temporary location to a chosen destination directory on the server. We want to do this in a safe way that checks that the file was indeed uploaded via HTTP POST. Concept / Approach: When PHP handles a file upload, it creates a temporary file on the server and populates $_FILES with an entry that includes the original filename, file size, MIME type, any error code, and the temporary filename. move_uploaded_file() is a built in function that takes the temporary filename and the desired destination path and moves the file while ensuring it originated from a file upload. Using move_uploaded_file() is safer than a normal rename because it performs checks to confirm that the source is a valid uploaded file. Step-by-Step Solution: Step 1: In your PHP script, access the uploaded file information via $_FILES["input_name"], where input_name is the name attribute of the form file field. Step 2: Check for upload errors by examining $_FILES["input_name"]["error"] and proceed only if it indicates a successful upload. Step 3: Retrieve the temporary filename from $_FILES["input_name"]["tmp_name"] and build a secure destination path, for example in an uploads directory, possibly sanitising the original filename from $_FILES["input_name"]["name"]. Step 4: Call move_uploaded_file($_FILES["input_name"]["tmp_name"], $destinationPath). If the function returns true, the file has been moved successfully to its final location. Step 5: Ensure proper permissions on the destination directory and consider generating unique filenames to avoid overwriting existing files. Step 6: This confirms that move_uploaded_file() is the standard and recommended way to move uploaded files from temporary storage to their permanent home on the server. Verification / Alternative check: You can verify correct behaviour by uploading a small test file and printing debug information about $_FILES and the result of move_uploaded_file(). After the function returns true, checking the destination directory should show the new file present. Attempting to use move_uploaded_file() on a non uploaded file should fail, demonstrating that the function performs safety checks beyond a simple rename. Why Other Options Are Wrong: Option b is wrong because rename() on its own does not verify that the file came from an upload and should not be used on the client file system, which PHP cannot access directly. Option c is incorrect because JavaScript running in the browser cannot copy files into arbitrary server directories; all uploads must go through HTTP requests handled by server side code. Option d is wrong because php.ini does not specify a single destination directory for all application uploads; applications are expected to move files themselves using code. Common Pitfalls: Common pitfalls include trusting the original filename without validation, which can lead to directory traversal or overwrite vulnerabilities, and failing to verify upload success before moving files. Another issue is not validating file types or sizes, which can open security holes. Developers should always check the error code, validate type and size, generate safe filenames, and use move_uploaded_file() rather than arbitrary file operations to process uploads correctly. Final Answer: You move an uploaded file to its final location in PHP by calling move_uploaded_file() with the temporary filename from $_FILES and the target path where you want to store the file permanently.

Question 16

In PHP, what is the $_FILES superglobal array and what information does it contain for each uploaded file?

Accepted Answer

Introduction / Context: When users upload files through HTML forms, PHP provides structured information about those files in a special superglobal array called $_FILES. Understanding how $_FILES is organised and what fields it contains is essential for handling uploads correctly, including validating file types, checking sizes, and moving files to permanent locations. Interview questions about $_FILES test whether developers know how file uploads are represented in PHP. Given Data / Assumptions: The HTML form uses method POST and enctype multipart/form-data with one or more file input fields. PHP receives the uploaded files and writes them temporarily to a server directory. For each file input field, PHP populates entries in the $_FILES array. The question asks what $_FILES represents and what information it holds. Concept / Approach: $_FILES is a superglobal associative array, similar to $_GET and $_POST, but dedicated to file uploads. For each file input field name, $_FILES contains a nested associative array with keys such as name, type, tmp_name, error, and size. These elements describe the original filename as provided by the browser, the MIME type as reported by the client, the temporary location on the server where PHP stored the uploaded file, any error code associated with the upload, and the file size in bytes. For multiple file uploads, these entries may themselves be arrays indexed by file position. Step-by-Step Solution: Step 1: Suppose you have an HTML input field <input type="file" name="photo">. After the user uploads a file and submits the form, PHP fills $_FILES["photo"] with information about that file. Step 2: $_FILES["photo"]["name"] holds the original filename as reported by the browser, for example picture.jpg. Step 3: $_FILES["photo"]["type"] holds the MIME type string sent by the browser, such as image/jpeg, although this should not be fully trusted for security decisions. Step 4: $_FILES["photo"]["tmp_name"] contains the path to the temporary file on the server where PHP stored the uploaded content, which is used with move_uploaded_file() to move the file to a permanent directory. Step 5: $_FILES["photo"]["error"] contains an integer error code indicating whether the upload succeeded or what kind of error occurred, such as file too large or partial upload. Step 6: $_FILES["photo"]["size"] contains the size of the uploaded file in bytes, which can be compared against application limits. For multiple files, these keys may each be arrays instead of simple values. Verification / Alternative check: You can confirm these details by printing $_FILES with var_export() in a test script after uploading a file. The output will show the nested structure with name, type, tmp_name, error, and size under the input field name. Uploading multiple files with the same name attribute using array syntax will show deeper nested arrays, but the same keys are present for each file, demonstrating that $_FILES consistently models upload metadata. Why Other Options Are Wrong: Option b is wrong because include and require do not populate $_FILES; they load PHP code but do not relate to file uploads. Option c is incorrect because $_FILES exists only on the server side in PHP; client side JavaScript has its own FileList objects and cannot directly manipulate server side variables. Option d is wrong because $_FILES does not define configuration; it holds upload data for the current request. Common Pitfalls: Common pitfalls with $_FILES include trusting the MIME type or original name without validating the actual file content, which can introduce security risks, and forgetting to check the error code before processing a file. Another issue is mishandling multiple uploads due to the nested array structure. Developers should carefully validate file sizes, types, and error codes before moving files and should always use move_uploaded_file() with the tmp_name entry to ensure safe handling. Knowing exactly what $_FILES contains is the first step toward secure and reliable upload processing. Final Answer: $_FILES is a PHP superglobal array that holds metadata about files uploaded via HTTP POST, including the original filename, reported MIME type, temporary server filename, upload error code, and size for each file input field.

Question 17

In object-oriented PHP programming, what are constructors and destructors, and what roles do they play in the lifecycle of an object?

Accepted Answer

Introduction / Context: In object-oriented PHP programming, constructors and destructors are special methods that help manage the lifecycle of objects. Understanding them is fundamental to writing clean, maintainable code, especially when you are working with resources such as database connections, file handles, or network sockets. Interviewers frequently ask about constructors and destructors to check whether you truly understand how objects are created, initialized, and cleaned up in PHP classes. Given Data / Assumptions: We are working in PHP using classes and objects. Objects often need initial values or resources when they are created. Objects may hold resources (like open files or database connections) that must be released properly. PHP provides magic methods such as __construct() and __destruct() to handle object lifecycle events. Concept / Approach: A constructor in PHP is a special method named __construct() that is automatically called when a new instance of a class is created with the new keyword. It is used to initialize properties, inject dependencies, or open resources needed by that object. A destructor is a special method named __destruct() that is called when the object is about to be destroyed, usually at the end of the script or when there are no more references to it. Destructors are typically used to release resources, close connections, or perform final logging or cleanup work so that the application behaves predictably and does not leak resources. Step-by-Step Solution: Step 1: Recognize that a constructor (__construct) is automatically executed when you create an object with new ClassName(). Step 2: Note that constructors usually accept parameters to set initial property values or inject dependencies like configuration or services. Step 3: Understand that a destructor (__destruct) is automatically called when the object is no longer referenced or when the script finishes execution. Step 4: In the destructor, you typically close files, release database connections, flush buffers, or perform other cleanup operations. Step 5: Realize that using constructors and destructors correctly leads to more predictable, robust, and memory safe PHP applications. Verification / Alternative check: You can verify how constructors and destructors work by creating a simple class with __construct() and __destruct() methods that echo messages. When you instantiate the class, you will immediately see the constructor message, and when the script finishes, you will see the destructor message. If you unset() the object explicitly, you will also trigger the destructor earlier, confirming that it runs when the last reference disappears. Why Other Options Are Wrong: Option B is wrong because constructors and destructors are not limited to database handling; they are general lifecycle methods for any kind of object. Option C is incorrect because constructors and destructors are methods, not variables. Option D is incorrect since constructors and destructors have nothing to do with HTML tags or CSS classes; they are purely PHP language features for classes and objects. Common Pitfalls: A common mistake is performing heavy business logic or complex work inside the constructor, which can make objects hard to test and slow to create. Another pitfall is forgetting to release resources in the destructor or relying only on destructors when using long running processes, where garbage collection timing might not be obvious. Good practice is to keep constructors focused on initialization and use destructors only for necessary cleanup tasks, often combined with explicit close methods when control over timing matters. Final Answer: Constructors in PHP are special methods that automatically initialize an object when it is created, and destructors are special methods that run when the object is destroyed to perform cleanup and resource release.

Question 18

In a standard PHP installation, what is the main PHP configuration file commonly called?

Accepted Answer

Introduction / Context: Every PHP environment reads its core configuration from a main configuration file. This file controls important settings such as error reporting, file upload limits, resource limits, extension loading, and many other behaviours that affect how PHP runs. Knowing the name of this file is essential for PHP developers and administrators because it is where they tune the behaviour of PHP for applications and servers. Given Data / Assumptions: We are using PHP installed via a typical Linux, Windows, or macOS distribution. PHP requires a central configuration file that is read on startup. This file controls directives like display_errors, memory_limit, upload_max_filesize, and extension loading. The question asks specifically for the name of this configuration file. Concept / Approach: By convention and design, PHP uses a file called php.ini as its main configuration file. When PHP starts, whether it is running under a web server module such as Apache or Nginx with PHP-FPM, or as a command line binary, it looks for php.ini in specific locations. Administrators edit this file to configure how PHP behaves globally. Additional per directory overrides can sometimes be created using other mechanisms (for example .htaccess in Apache), but php.ini remains the core configuration file name recognized by the PHP engine. Step-by-Step Solution: Step 1: Recall that PHP configuration is usually stored in a file whose name ends with .ini, indicating a text based configuration format. Step 2: Recognize that the official documentation and installation guides consistently refer to the main configuration file as php.ini. Step 3: Note that there might be several php.ini files for different environments (for example one for CLI and one for Apache), but all share the same file name php.ini. Step 4: Understand that alternative filenames such as config.php or php.conf are not standard for core PHP configuration, though some frameworks or servers may use them for other purposes. Step 5: Conclude that the correct answer is php.ini, the standard global configuration file for PHP. Verification / Alternative check: You can verify this by running phpinfo() in a PHP script or php -i on the command line. The output shows the Loaded Configuration File path, and the file name displayed there is php.ini. Installation guides for common stacks such as XAMPP, WAMP, or LAMP also explicitly instruct you to edit php.ini to change PHP configuration, confirming that this is the correct and standard file name. Why Other Options Are Wrong: Option B (config.php) is wrong because, although many applications use config.php for their own settings, it is not the core PHP configuration file. Option C (php.conf) might be used as part of a web server configuration, for example in Apache include files, but it is not the primary PHP configuration file. Option D (settings.ini) is a generic sounding name and not used by default by the PHP engine for its main configuration. Common Pitfalls: A common mistake is editing the wrong php.ini file when multiple PHP installations exist on the same machine, such as separate CLI and web server configurations. Another pitfall is expecting changes in php.ini to take effect without restarting the web server or PHP-FPM service. Developers should always confirm which php.ini file is active via phpinfo() and remember to reload or restart the relevant service after editing configuration settings. Final Answer: The main PHP configuration file is called php.ini in a standard PHP installation.

Question 19

In PHP, what is a filter and what is the purpose of the PHP filter extension when handling external input?

Accepted Answer

Introduction / Context: Web applications written in PHP frequently receive data from users and external sources, including form submissions, query parameters, cookies, and HTTP headers. This data is often untrusted and can be malformed or malicious. The PHP filter extension was introduced to provide a standardized way to validate and sanitize this incoming data. Understanding what a PHP filter is and why it exists is crucial for secure and robust PHP development. Given Data / Assumptions: We are working with PHP scripts that read external input via $_GET, $_POST, $_COOKIE, $_SERVER, or other sources. Input data may contain invalid formats or potentially dangerous content. PHP provides a filter extension with functions such as filter_var and filter_input. The goal is to validate (check) and sanitize (clean) input before using it in the application. Concept / Approach: A PHP filter is a rule provided by the filter extension that describes how to validate or sanitize a specific piece of data. For example, filters can verify that a value is a valid integer, a properly formatted email address, or a safe URL. Other filters can strip tags, remove unsafe characters, or encode data. Functions like filter_input() and filter_var() apply these filters to data, making it easier to consistently enforce input validation throughout the application. Using filters reduces the risk of security vulnerabilities such as cross site scripting and SQL injection when combined with other best practices. Step-by-Step Solution: Step 1: Recognize that external data in PHP is obtained from superglobals like $_GET and $_POST and needs to be treated as untrusted. Step 2: Understand that the filter extension defines many constant based filters, for example FILTER_VALIDATE_EMAIL or FILTER_SANITIZE_STRING. Step 3: Learn that functions such as filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT) allow you to both retrieve and validate data in one call. Step 4: See that filter_var($email, FILTER_VALIDATE_EMAIL) checks whether a given string is a valid email address and returns either the cleaned value or false. Step 5: Conclude that PHP filters are built in mechanisms designed specifically for validating and sanitizing data rather than styling, database work, or image processing. Verification / Alternative check: The official PHP documentation lists the available filters and shows examples where filter_input() and filter_var() are used in real applications. When you apply a validation filter to incorrect data, it returns false or null, while correct data passes through. These behaviours can be easily tested in small scripts and confirm that filters are designed for input validation and sanitization instead of any unrelated purpose. Why Other Options Are Wrong: Option B incorrectly associates PHP filters with CSS styling, which is handled by stylesheets in the browser, not by PHP filters on the server. Option C wrongly states that a filter is a database engine, but PHP filters do not replace MySQL or any other database; they simply process input values. Option D confuses filters with image processing features; while PHP has image functions in the GD or Imagick extensions, those are unrelated to the filter extension used for input validation. Common Pitfalls: A common pitfall is relying solely on PHP filters and ignoring other security measures such as parameterized queries for databases or proper output escaping for HTML. Another mistake is using the wrong filter type, which can cause valid data to be rejected or invalid data to slip through. Developers should carefully choose appropriate filters for each input field and combine filtering with other secure coding techniques to build safe applications. Final Answer: A PHP filter is a rule provided by the filter extension that is used to validate and sanitize external data, allowing functions like filter_input and filter_var to clean and check user input before it is used.

Question 20

In a typical Apache HTTP Server installation, what is the main Apache configuration file usually called?

Accepted Answer

Introduction / Context: Apache HTTP Server is one of the most widely used web servers in the world, and PHP applications often run on top of it. To administer Apache, you must know where its main configuration lives. While Apache can include additional configuration files, there is typically a primary configuration file that defines core settings such as virtual hosts, modules, and performance directives. Knowing its usual name is a basic but important piece of server administration knowledge. Given Data / Assumptions: We are dealing with Apache HTTP Server, not other web servers like Nginx or IIS. Apache relies on configuration files to control modules, virtual hosts, ports, and global settings. Many distributions ship with a central configuration file that may include others from a directory. The question asks for the typical name of the main Apache configuration file. Concept / Approach: Historically and in most standard distributions, the main Apache configuration file is named httpd.conf. This file often resides in directories such as /etc/httpd/conf or /usr/local/apache2/conf on Unix like systems. While some distributions also use apache2.conf and include site specific files from conf.d or sites available directories, the canonical and widely recognized traditional main configuration file name is httpd.conf. Other file names mentioned in the options either belong to other servers or are not standard for Apache main configuration. Step-by-Step Solution: Step 1: Recall that Apache was originally called httpd (HTTP daemon), which explains the httpd prefix in its configuration file. Step 2: Check typical installation paths on Linux or Unix, where you will see httpd.conf in the main Apache configuration directory. Step 3: Understand that this file contains directives for loading modules, setting the document root, configuring logging, and more. Step 4: Note that while apache2.conf exists on some systems, the long standing and widely known default name is httpd.conf. Step 5: Conclude that among the options, httpd.conf is the best answer to the question. Verification / Alternative check: Consulting Apache documentation and sample configurations shows that httpd.conf is the main configuration file referenced in examples. On many production servers, running a file listing in the Apache configuration directory reveals httpd.conf as the primary file, often accompanied by additional included files. The Apache binary itself is often called httpd, reinforcing the naming convention and confirming that httpd.conf is the correct file name. Why Other Options Are Wrong: Option B (apache.ini) is incorrect because Apache does not use .ini style configuration for its main settings; that format is more often associated with PHP. Option C (server.xml) is typically used by Apache Tomcat, an application server for Java, not by Apache HTTP Server. Option D (apache.cfg) sounds plausible but is not the standard name used by Apache for its main configuration file. Common Pitfalls: A common pitfall is confusing Apache HTTP Server with other products such as Tomcat or with operating system specific wrappers that introduce additional configuration layers. Another mistake is editing included configuration files but forgetting that core directives still reside in httpd.conf. Administrators should understand the overall include structure but still know that httpd.conf is the traditional main configuration file that anchors Apache configuration. Final Answer: The main Apache HTTP Server configuration file is typically named httpd.conf.

Technology Questions