Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by gizmola

  1. In my opinion, you want to build a "responsive" site, where you have certain thresholds you use for mobile devices. Rather than start with the idea that you have a max, allow the site to grow and shrink based on the device specific (viewport) attributes like vh and vw, as well as using the flexbox properties that allow for growth and shrinkage. So for example let's say that you have a fixed height for a header, and below that you have a flexbox that should fill available vertical height and width. You might have a style like this: .app { font-size: 15px; color: #fff; height: 100vh; width: 100vw; } .header { background-image: linear-gradient(to right, #18a0BE, #622db9); height: 55px; display: flex; } .app__container { height: calc(100vh - 55px); display: flex; } .main { background-color: #edf1f3; flex: 1; } And your markup might be something like: <body class="app"> <header class="header "> </header> <div class="app__container"> <main class="main"> <div class="cards"> </div> </main> </div> </body>
  2. Flexbox and/or grid should handle everything you want. I would start with using flexbox for all of the layout pieces you have already described, so certainly you want a container div for those so that you can use display: flex. At that point it's just a matter of applying the appropriate parent/container properties or child div properties you desire. This article might help if you need a refresher: https://css-tricks.com/snippets/css/a-guide-to-flexbox/
  3. Having looked at the code further, you don't want to use the esc_html___ function, or at least not on the url. That function is changing the anchor tag markup so that it no longer will function as a url. Try this instead: <?php /* translators: %s Order date */ printf( esc_html__('Tracking number', 'woocommerce') . ':<a href="https://www.fedex.com/fedextrack/?trknbr=%2$s">%2$s</a>', esc_html($shipping_carrier), esc_html($ups_trackingno) ); ?> I don't know if your site is multilingual, but the primary purpose of esc_html__() is to do translation, but it also "escapes" any html as I mentioned. Obviously there is no reason to translate the url, but you might need translation of the text string "Tracking number" (or not).
  4. If the script doesn't parse, that could be a reason you are not seeing errors. Since most editors catch these types of problems in advance, I'm not sure why you would not fix them in advance. You can also use the command line linter with php -l sourcefile.php. Sometimes this trick can help get around the problem of a stubborn parsing error that causes a 500 error: Make a script named something like debug.php: <?php //debug.php error_reporting(E_ALL); ini_set("display_errors", 1); require("filewitherrors.php");
  5. We can't guess what your code looks like. It might help to explain what you are using one of these characters for.
  6. So it looks like you are using your own tokens for login. That is not a good idea. You should be relying on the session instead. If you expect to have a cluster of app servers, you might need to change session storage so that it uses your database, or redis/memcached instead of files, or you can use a load balancer that supports the configuration of a "sticky" session, but otherwise, you don't want to be creating and managing your own session/authentication token for anything other than the remember me feature. Sessions already, when properly configured, utilize a cookie. You also want to make liberal use of session_regenerate_id. From what you posted, this has DRY/ logic issues: if (isset($_POST['remember-me'])){ $_SESSION["loggedin"] = true; $_SESSION["username"] = $username; $_SESSION['the_usr_id'] = $user['user_id']; echo "<hr>"; echo setRememberMeToken($pdo, $user['user_id']); echo "<hr>"; header("location: dashboard.php"); } if (!isset($_POST['remember-me'])) { $_SESSION["loggedin"] = true; $_SESSION["username"] = $username; $_SESSION['the_usr_id'] = $user['user_id']; echo "<hr>"; echo "<hr>"; header("location: dashboard.php"); } Again, I don't have your code, but you have a repetition of code, and worse yet that code is actually not relevant to the variable you are checking (!isset($_POST['remember-me']). What you want to do is avoid blocks like this, which are also mutually exclusive. So again, assuming that this is part of a block where you already established successfull login previously, you can rewrite your code like this, to separate the remember-me check so that it only does what is relevant to the existence of that flag. I will also point out that if the user logs in without the remember me checkbox, you should remove the remember me token, but your code doesn't do that. Something like this would be better, and also fix your current hole. // Assumes authentication succeeded above this code $_SESSION["loggedin"] = true; $_SESSION["username"] = $username; $_SESSION['the_usr_id'] = $user['user_id']; // Not sure why you need this? if (isset($_POST['remember-me'])) { setRememberMeToken($pdo, $user['user_id']); } else if (!$_SESSION['rememberMeLogin']) { // Was not a "remember me" authentication AND remember me was unchecked. So should remove the remember me token & Delete the cookie. unsetRememberMeToken($pdo, $user['user_id']); } header("location: dashboard.php"); exit; Another thing I would suggest is not to use md5, but used sha1 instead. md5 has a smaller collision space. I would also add something to the random input to the hash (md5,sha1). So perhaps add something like username + random bytes. People can generate a large table from random byte input (a rainbow table) and look for matches. By doing so they might figure out you are just using random byte combinations of a certain size. It's not a major security hole, but one you can protect against by not just hashing random characters of the exact same size from a routine. This is similar to the idea of using a "salt".
  7. One other thing I would say about remember me, is that a good additional security feature is to set a session variable boolean like "usedRememberMe". Any time a user escalates privilege (ie. they want to change something in their profile like an email address, or create an order, or become a system moderator or superuser) you want to prompt for re-authentication and generate a new session id. You can use the "usedRememberMe" session variable as a factor in what you might do in this circumstance. For example, you might choose to require re-authentication more aggressively if they logged in via the remember me cookie. It can be helpful to keep track in the session how the user was authenticated.
  8. Starting with a basic fact: Cookies are owned by the user. Heed Mac's advice on this. A remember me cookie is a standin for a user having presented their name/password for authentication. You have implemented Mac's idea for the most part, which is standard The only time you need evaluate the remember me cookie is if you have an unauthenticated user. Rather than prompting for a login, you can use the remember me cookie to validate they are who they say they are, via the remember me cookie. So that cookie requires both username and the hash value. You need the expire date for this, because again, you can not trust the cookie. A user could just go in and set the expiration date so the cookie never expires. You can also use the cookie expiration as an added check if you want. This would further verify the user has not tampered or constructed a remember me cookie to bypass login. For all these reasons, sessions do not matter. If user is unauthenticated Do they have a remember me cookie? Check the database for the remember me value and check that the value has not expired If this criteria is matched, log the user in This should involve the exact same loading of session data as if the user had logged in with username/password. Otherwise redirect to login page
  9. 2 things that will be of value for you: PHP has include/require. It allows you to put something in a script and include it as if you had typed it in. What jumps out immediately is that you have database credentials. When you change them you don't want to have to change every script in your system. Put them in a script and require_once them instead. Here is a pretty typical PHP application directory structure you can use. Your webserver document root should be set to the /path/to/your_project/public directory. This allows you to keep some files outside of the webroot, so hackers can not attempt to execute them directly your_project/ ├─ include/ │ ├─ config.php │ ├─ utility_functions.php ├─ public/ │ ├─ css/ │ ├─ js/ │ ├─ index.php In the /your_project/include/config.php file you put your database setting variables. $DATABASE_HOST = 'localhost'; $DATABASE_USER = 'root'; $DATABASE_PASS = ''; $DATABASE_NAME = ''; mysqli_report(MYSQLI_REPORT_ERROR|MYSQLI_REPORT_STRICT); $con = mysqli_connect($DATABASE_HOST, $DATABASE_USER, $DATABASE_PASS, $DATABASE_NAME); if (mysqli_connect_errno()) { // If there is an error with the connection, stop the script and display the error.// exit('Failed to connect to MySQL: ' . mysqli_connect_error()); } When a script needs a mysqli connection to use you require_once config.php. In index.php for example: <?php // index.php require_once('../include/config.php'); // Rest of code here, can already use $con The other thing I would suggest is trying to use functions for individual tasks. If you can put code into a function, it will be possible to re-use it in multiple scripts. By changing to a typical structure like the one I describe, you also open yourself up to the possibility of using component libraries in your application, as well as autoloading via the composer dependency management tool. This does require some basic understanding of PHP's object oriented programming syntax, at least so far as being able to instantiate an object with "new className()". This is probably the best thing as a novice developer you could do at this point, other than to port your application to a basic framework like Cakephp. Seeing the road you are going down, and in recognition of your neophyte status, I would highly advise taking a look at using Cake, because it is very simple and easy to understand, and will give you the basic MVC structure a web application should have. It's easy to see for most of us, that you are already making huge mistakes, and writing spaghetti that will be buggy, insecure, impossible to maintain, and involving tremendous reinvention of the wheel. CakePHP can relieve you of a lot of that, and has a simplicity to it that is well suited for relative beginners. I tried to find you a free online course to help you learn CakePHP, and this one looked decent, and the person teaching how to use it is well spoken and knowledgable. If you do use CakePHP I think the equivalent for the public directory/webroot is a directory named /webroot. Frameworks like CakePHP have code generation tools and will typically offer a way to initialize your project via composer. This is covered, I believe in the tutorial series I posted about. Here is the main CakePHP site: https://cakephp.org/ Basically what you will do is make a new CakePHP project on your workstation. You can then "port" ie. move relevant code you want to preserve into files in your CakePHP project. CakePHP gives you structure you don't have now, like controllers/routing, models (that will match your database tables) and views (templates). Once you get these simple concepts, the framework will save you incredible amounts of time, in providing you built in classes and structure that let you concentrate on your actual logic and functionality.
  10. Another thing you have not thought through is what happens when you have 2 files with the same name. What you have is a naive strategy, that as, kicken pointed out, can open you up to a variety of exploits. This is what most people do: In your "media" table have a column for the path to the stored file Generate an internal name for the file. MD5, SHA1 etc are good places to start Provide a variety of input to the hash example: $internalName = sha1($orignalName . uniqid('something', true) . date(DATE_RFC2822) . $userid); Make this the name of the file you store + mimetype extension have a column for the original file name Run hygiene functions on this name, that does things like: remove any non-characters remove any path characters remove html remove spaces and replace with underscores or dashes Exploiters will try things like names that included multiple extensions, and can in some cases fool your webserver into running code examples: foo.jpg.php, foo.bar.cgi.jpeg remove any periods other than the one at the end of the file name (.ext) and either replace those with underscore or dash, or remove. have a column for the mime type of the media Run function(s) on the file that determine if the mime type of the file matches what you will allow Check that the extension of the filename matches the mimetype When it comes time to display a link to the document, you will use your internal hash id to find the document. Depending on what you are doing with the media you can use html markup like the alt attribute to display the "original" name, and/or for download purposes, you can specify that in the content-disposition header like so: Content-Disposition: attachment; filename="filename.jpg" So your download script might have something like this in it: <?php $fileId = $_GET['fid']; // Db code looks up file in media table, returns $media row header('Content-type: ' . $media['mimetype']); header('Content-Disposition: attachment; filename="'. $media['original_name'] . '"'); // open file and return data
  11. Please use the <> for adding code snippets in the future. I edited your original post. Remove the echo. You are already calling multiple functions, which take parameters. Parameters can not include php blocks or statements. As it is, the printf function is returning output. If you look at the php manual for printf you should be able to see why it is being used here. It takes parameters and injects them into the string using the parameters being passed to it. <?php /* translators: %s Order date */ printf( esc_html__('Tracking number : <a href=\\"https://www.fedex.com/fedextrack/?trknbr=%2$s\\">%2$s</a>"','woocommerce'), esc_html($shipping_carrier), esc_html($ups_trackingno) ); ?> I reformatted the block so you can more easily see the functions and parameters being passed.
  12. Websafe colors is an artifact of the days when memory constrained graphic cards only had support for single byte ( 256 colors) per pixel. Those days are long gone, and you should not be concerned with the 216 websafe colors unless you are going for some sort of retro color palette.
  13. For a chrome extension I'm pretty sure you have to assign permissions in your manifest file, if you want a specific host to have access. Then use chrome.cookies api. See: https://developer.chrome.com/docs/extensions/reference/cookies/ I'm not sure what you are trying to do with cookies in your extension, but an alternative that isn't chrome specific would be to use local storage. Again you need to specify in the manifest: https://developer.chrome.com/docs/extensions/reference/storage/
  14. Maxxd and ginerjm pretty much nailed it. The warning was introduced in PHP version 7.2. Is it possible you can get an updated version of the template you are using? You might need to make a lot of these types of patches. I'd probably make this variation on ginerjm's fix: $subcategories = empty($subcategories) ? array() : $subcategories;
  15. The web is a complicated and confusing interdependent set of technologies, and is often underestimated. Most people get confused as to how specific things actually work. There are better tools now, like the chrome web tools for example, which are great aids to figuring out how a web application actually works. Javascript with its frameworks and SPA's continues to add to the complexity and role of client side code running in the browser, but I do believe that if you really understand the fundamentals, like where code actually runs, and the overall architecture of the various processes involved, you have a better chance of avoiding confusion. HTTP is very important to understand. Using the dev tools Network tab is a great way to explore this. A lot of times people just assume that something described in abstract, like cookies for example, are obvious, but if you don't understand where cookie data lives, and in what circumstances the server has access to cookie data, and what restrictions might exist for that data, it can just seem like magic, which leads to confusion. A good understanding of HTTP helps demystify things. When you look at HTTP it then helps to understand that HTTP is built on top of TCP protocol. So you can continue to delve into the intricacies of how things work, and gain a deeper understanding as you see fit.
  16. There is no reason to be writing obsolete/insecure php mysql code in 2022. Literally every veteran member of this forum will offer you the same advice: The mysqli_ interface to mysql is annoying to use. Learn/use PDO instead! There is a fast easy to read guide to using PDO that will teach you everything you need to know, as well as offer best practices. Whether it be mysqli_ or PDO, all variables should be prepared/bound, as Barand advised. It's just cleaner/easier to use PDO to write your code. Now every single person like yourself that is learning, when they receive this suggestion, has the same reaction which is "thanks, I will have to learn PDO ... sometime in the future (aka never) because they will have to learn PDO and rewrite some of their existing code. I understand that this is a natural reaction to a learning curve and the unknown. With that said, aside from understanding how to set up a PDO connection, you really will thank us all later, if you make the change now.
  17. You already have some useful answers, but I'll throw in my 2 cents which includes a bit of history. When the world wide web was first evolving, all HTML pages were static. The HTTP protocol, which enables the WWW, describes how a client (browser) can use a URL to reach a server, and request a resource (html document). I would hope that at this point you are familiar with the HTTP methods available -- GET, POST, PUT, PATCH & DELETE. So a browser made a get request via HTTP, and the first servers would resolve the location of a static html document and return that to the client. Again, somewhat obviously, an html document can specify a number of pieces, which again in the early days were images, as Javascript and css had not been invented/formalized yet. The job of the browser is to parse and assemble the html document and display it to the user, and handle hyperlinks. Eventually, people wanted to provide a more interactive experience. A simple example, would be a page that showed all the latest news stories of the day. Either someone had to manually update the index page, and add static html pages for all the stories, or a program running on the server could be enlisted to create html on the fly. Sophisticated software existed for a long time to do all of this, and in many ways the WWW was a huge step backwards. Client/Server and terminal applications had existed for years prior to the first browser and web server, and people were used to using online services like Compuserve and AOL, which had their own client/server protocol and content rendering client software. The WWW was an attempt to democratize this and provide standards that anyone could use. HTTP itself came from scientific organizations who wanted a way to easily share research papers. Much of what we know as the Internet also came from this process, where people would publish standards in the form of "Request for comment" ie RFC's. A few groups that had been involved in the creation of the first web servers got a working group together and published RFC 3875 which describes the "common gateway interface" (CGI) which standardized the way a web server could invoke a program, accepting input from the web server in the form of environment variables with specific names and purposes, and then return the results (in the form of html) to the web server, which would then return that "computed" html to the user. This was the birth of "server side" web programming, and the basic structure of that continues to this day. Web Server accepts an HTTP request with a URL If Web server detects that the URL requires a "CGI program" be run, it passes variables (user input and standardized CGI web server variables) to the program through the Operating system environment Local server program runs, returns a "response type" data structure + the actual data to the web server Web server returns html (or any other valid resource type) to the client I mention this, because the URL might have been an image, which could be generated on the fly by a server side program as in the case of a computed graph image So this brings us to the various popular server side languages. In the early days of the web, people would often write their CGI programs in C, as the primary server operating system of choice by most people involved in running servers in the early days of the WWW was Unix. As C is terse, and requires compilation, early web developers started looking for ways to simplify coding. CGI allowed any "program" to be used, which meant that early developers could use something as simple as a bash script which chained together various unix commands. The Perl scripting language was extremely popular at the time, due to its interpreted nature, advanced data structures and many available libraries. For example it had a relational database client interface (DBI/DBD) that allowed a developer to write simple code to make SQL calls to a relational database. Commercial databases like Sybase SQL server and Oracle were popular at the time, and the open source MySQL database was seeing a lot of adoption, as the commercial databases were expensive and hard to obtain. Perl, like other interpreted languages, is evaluated when the script is run (at runtime). Most developers found this highly preferable to developing in a compiled language like c or c++, which required a compilation/build process anytime you changed so much as a single line of code. It was in this time, when PHP first appeared, and it was intended to be a language/toolkit specifically aimed at making the development of serverside web scripting simpler. So one of its features as the ability to intermix HTML and php scripting blocks in an html script. This is somewhat in the spirit of a competing standard at the time, called "Server Side Includes" which had a similar objective of taking something that was mostly pure HTML and augmenting it with some markup that the server would act upon when the page was requested. With that said, PHP like Perl, is interpreted, and thus required a runtime process to parse the PHP code and execute it at runtime. Java also has a runtime, although the main difference in the case of Java is that the Runtime engine (the JVM) was designed to be a persistent server process/daemon. In the case of Perl & PHP, a web server running a Perl or PHP script needed to invoke the perl or php runtime program, which would then load the script code and run it. This script code could of course also load/include perl or PHP libraries, and do all sorts of things while running, but unlike java, it was not intended to have any persistence. This is very different from java where you can create objects and have them persist in the JVM (or in the case of Java EE, a Java application server). PHP programs are run when requested, and when the PHP script is done running, all the variables and objects that might have been created are disposed of when the script ends and has returned the response data to the web server. As PHP became popular, people wanting more performance and less overhead began to look for ways to reduce the overhead of starting up the PHP process each time. By this time, the open source Apache web server had become hugely popular, and apache was designed to be a collection of modules, with a specification for anyone who wanted to add a new feature to the server via development of a custom module. Developers within the PHP project community created an apache module (mod_php) which essentially made PHP a part of the Apache Web server. This meant that instead of the web server having to fork a child program and pass all the variables through the environment, a PHP script could receive that data and access web server variables directly from Apache's shared memory structures. The problem with this idea is complicated and has to do with how Apache services requests. I wrote about this issue on my blog if you want to read more about the underlying issues. Around this same time servers had appeared to challenge Apache, most notably the NGINX web server. NGINX has a fundamentally different architecture to Apache, and had no support for mod_php or something similar. NGINX was designed to be a highly performant proxy server, so it supports a variety of ways to proxy a request to a server process for handling. NGINX implements "Fastcgi" which was developed as an alternative to CGI. Essentially, fastcgi sought to get around the same problems that apache modules were designed to get around -- the overhead of having to create and destroy an os program for every request to a server side script. NGINX and other servers that support fastcgi (which even includes apache now, via an optional fastcgi module) assumes that there is a persistent operating system process that supports the fastcgi protocol. This was ideal for languages with a persistent runtime application server process like java. In order to make this work for php, a persistent php application server was developed within the PHP project, that supports fastcgi. This php application server is called php-fpm. Internally php-fpm maintains a number of persistent php processes which can be used to run a php script. A proxy web server like Nginx can be configured to send requests for php script to php-fpm via fastcgi protocol, and return the results to the client. I hope this somewhat long and verbose history of web servers helps answer your question and give you some background to clarify how PHP works. At the end of the day, a PHP script is a PHP script. There aren't a lot of different types of PHP files -- there is only .php. Frameworks have introduced template languages, and PHP can parse files of various flavors, but in all cases the end result is the execution of PHP code. Unlike Java, there was never an effort to define specific file formats to do different things as in the case of Java servlets/vs JSP vs JSTL. PHP was designed with the intention of being a language that would work with and be integrated with a web server via CGI. It has many design features focused on that, and is not generally considered a generic scripting language like perl or Ruby or Java, Nodejs or more recently, Python. Any one of those languages (including PHP) could be used to create a "socket server" that can run on a server and handle HTTP requests. There are other types of protocol servers (Websockets in particular) that have become popular as the web has evolved. The performance of PHP interpretation has been improved in recent years, and there are also projects that add some valuable features like "event driven non-blocking IO" which are beneficial if you are developing a server process in PHP, but that is not the typical reason people use PHP. For the most part they are using it to create server-side web applications.
  18. You need to provide some code for people to look at.
  19. Web pages are just a combination of html, css, static resources like images, video and sound, and javascript. Curl is not some magic scraper tool -- it is just a client library like many client libraries that can simulate the same conversation with a webserver (HTTP protocol) as a browser does. There are numerous PHP client libraries that can also do what curl does. Guzzle, Httpful and Httplug are a few of the most used ones. Depending on what you want to do with code from the pages you are trying to scrape, you might be better off using one of those rather than the wrapper around Curl. Your results depend greatly on what pages you are trying to scrape and the relative complexity of those pages, as well as what you want to try and do with the scraped results.
  20. And your account was made in 2005, and you made 4 posts in 2007. The forum member table was cracked in 2015.
  21. If you look at the actual code, it's pretty simple. This is the api call from google: $json = file_get_contents("https://www.googleapis.com/youtube/v3/videos?part=statistics&id=" . $videoID . "&key=xxxxxxxxxxxxxxxxxxxxxxxx"); Apparently, if the id = parameter includes a comma delimited list of videos, this api will still work (up to 50 videos). [[youtube_view_count id="UKuYgIBnqEA,xxxxxxxxx,xxxxxxxx"]] There is an entirely different analytics api you could use, which allows for statistics by "dimension" where your dimensions can be a channel, playlist, video or analytics "group". You maintain the groups through the youtube studio, and you can have up to 500 videos in a group. That would be easier to use and maintain long term. See https://support.google.com/youtube/answer/3529123?hl=en for more details on groups. Obviously you could get the statistics for the whole channel or add the videos to one or more playlists. This page lists some sample queries that could be used to get stats for a channel or a group: https://developers.google.com/youtube/analytics/sample-requests It looks to me like that is the way you want to go, but I don't have the time to look into it much further other than to suggest a look at: https://developers.google.com/youtube/analytics
  22. I'll add to Barand's suggestions: This is a great resource of best practices https://phptherightway.com/ Projects should utilize composer for dependency management and library autoloading: https://getcomposer.org/ If you like video courses, this guy has a channel of free youtube videos that are as good or better than a lot of online courses you might pay for: https://www.youtube.com/c/ProgramWithGio In terms of coding standards, this document is a community standard adopted in whole or part by most frameworks and components: https://www.php-fig.org/psr/psr-12/ Most professional web development also involves the use of a framework. The 2 most popular and active frameworks are: https://symfony.com/ https://laravel.com/
  23. This is the php function you are trying to use http_build_query. So as Barand stated, clearly you should not be json encoding the array. Instead: $data = array('currency' => 'USD', 'sort' => 'rank', 'order' => 'ascending', 'offset' => 0, 'limit' => 2,'meta' => false); I can't say for sure if that is going to work with your API, but at least you'll get past your error. Take a look at the php manual for a function whenever you have issues with one.
  24. You'll use the $_GET superglobal to get the url parameter. if (empty($_GET['id']) || (int)$_GET['id'] < 1) { exit; } $id = (int)$_GET['id']; // Add your code to make the mysql connection. Since this is a common thing, you would be better to have that code in a script you // require_once in any script that needs the mysql connection $stmt = $mysqli->prepare("SELECT * FROM users WHERE id = ?"); $stmt->bind_param('i', $id); $stmt->execute(); $result = $stmt->store_result(); $getRowAssoc = mysqli_fetch_assoc($result); if ($getRowAssoc) { // Display the user data }
  25. My educated guess is that requinix is right. I also think the code snippets reflect that the order object should be available in plugin2 via $this->object. So I would suggest you try adding this code to plugin2 $this->placeholders['{order_service_time}'] = get_post_meta( $this->object->get_id(), '_wfs_service_time', true);
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.