requinix

Please, PLEASE do not make me answer your implied question about where you should generate a password. Because I will not be polite. AllowOverride is about whether (sub)directories can use .htaccess files. This sort of authentication is automatically remembered by your browser. You don't have to do anything to make that happen. Passwords are not encrypted. They are hashed.

That's a step in the right direction but you still have a ways to go. We aren't going to write this code for you, and people generally are not willing to guide you every single step of the way. You need to show initiative and a willingness to learn. So keep going. You're doing fine so far. You will need to learn some PHP. It also seems like you're going to be dealing with file uploads, which PHP can certainly do, but I didn't get the impression that you needed it for this. Then again, you didn't really go into any sort of detail explaining how this work or what it is all about, so I don't know.

You should probably do something about that.

It is. Try going to http://www.website.com without my changes and make sure it redirects. If so then you can disregard.

Does the python script output anything as it goes? Are you trying to return that output?

You might be able to do just that, yes. "Might" because we have no idea what your application is. As long as it isn't trying to link to itself as "http://www.website.com/page.html", and is just using server-relative paths like "/page.html", then everything should continue working. If it is using "http://" links then those have to be fixed manually. You should also support redirecting from http to https, though. All you need to do is add another condition to the redirect already there to say that it should happen if the URL was http or website.com. Which I would write differently: RewriteCond %{HTTPS} off [OR] RewriteCond %{HTTP_HOST} !www.website.com RewriteRule ^ https://www.website.com%{REQUEST_URI} [L,R=301]

Underscores.

This isn't image preloading 😕 Look at your myFunction. Look at the way you call the function, then at what happens inside the function. Pay attention to the variables.

Set it up as a submodule, or install it to the build host manually and reuse it that way, or write your common build code as extensions to Jenkins directly.

By finding the correct name according to wherever you're installing from. Those flags are for compiling PHP. You are not compiling PHP. If you were able to install everything, except ext/sockets, then apparently you were able to install everything.

Yeah. Sure. Of course it's possible. Are you able to generate an HTML page that outputs what you want? It's not that hard. If you can do that then you can generate an XML page. Give it a shot, and if you have problems with your code then post it here with a description of what's wrong and we can help you with it.

Not necessarily. Tons of websites out there are heavy on images, and many of them need those images to be available soon. You don't - we're talking about a textual book with some illustrations, not a picture book. (Even if it was a picture book, people only read one page at a time.) Meanwhile text isn't particularly strenuous on browsers. 40 pages * 500 words/page * 10 characters/word (spaces, punctuation, some HTML markup) = 200,000 characters. A fraction of a megabyte. So don't worry about it. Not yet. 40 pages could be a lot for a mobile device, so for that it would be worth considering paginating the content. Perhaps on desktop too, if you want the aesthetic of it. Unless pages are important concepts you need to account for, and you should try to avoid that if you can (pages are just so arbitrary), then you don't need to break it down beyond chapters. Worry about AMP later.

Look more closely at the array you have to work with. $arr is an array, containing a "global" that is an array, containing a bunch more arrays, some of which have "div" in them. Now look at your code, which I'm going to paste here so that people don't have to go somewhere else on the internet to find it: $split = []; $i = 0; foreach($arr as $k => $v) { if ($v == 'div') { $i++; } $split[$i][$k] = $v; } Your code looks at what's in $arr and tries to find anything that is the string "div". Your array and your code are pretty far apart.

Take a closer look at the documentation for set_error_handler() and you'll notice it says you cannot handle fatal (E_ERROR) errors. The only thing you can do in that case is react to the fatal error after the fact: use register_shutdown_function() and error_get_last() to detect whether the script is ending because of a fatal error.

Well, nice to know we both had the same answer.

$q = 'SELECT ID FROM table'; That is a SQL query. You have to run that query through your database, receive the results, and then look for each single matching image in the directory for every returned record. You can probably skip looking in the directory, though. It will only tell you if the file exists. So if you already know (or assume) the file exists then you don't need to bother looking.

Okay. Fine. So don't track history. And now that you've made a decision I call tell you that I wouldn't store a history for this either. Stop caring about that file. I guess you missed the rather significant part of my post where I tried to explain what it is. Not sure what you're talking about but I'm 99% sure "loop while error is not present" is not the answer. sigh I'm done.

Don't worry about the IBD file. MySQL knows how to manage itself, you don't need to go second guessing it because of what you think you saw in Notepad. The question you think you're asking is whether to use an UPDATE or a DELETE+INSERT, but the question you're actually asking is how you should manage uploaded files that can be replaced. The answer to that is... well, it depends. There are two basic options: 1. Forget the previously uploaded file. You don't care about it. Take the new file and stick it wherever you want, update the database, and delete the old file. Gotta delete. Because if you forget about the old file then there's not much of a point to keeping the file itself around too. 2. Keep track of the previous file. You'd probably want a table that holds all the information for past and future uploads, and that's where you track them. For using those files, instead of storing the file information in whatever place, you reference the file in your upload information table. New image, new information row, and you update whatever place was affected. This lets you keep a history of everything, which probably isn't important for stuff like user avatars but is frighteningly important for stuff like monetary transactions. "Okay, I've decided that I want to do <whichever option>. But what about my literal question? Should I update or delete and insert?" Time to learn about an important concept in computing that disappointingly few programmers ever end up learning: atomicity. That's the noun version of "atomic", which means (in this case) that whatever operation you need to do can't be interrupted or broken in half or appear to anyone else as being anything less than one single action. Atomicity is important for stuff like files and databases because you basically never want to look at a file or data in the middle of some important operation. Imagine your site is popular. Really popular. Facebook or Twitter popular. Constant traffic to your servers. Now imagine a user uploads a new image. When the code is ready, it needs to go off into the database to make whatever changes it needs to make so the user has the new image. Say you go with DELETE and INSERT. Your code runs one query that DELETEs whatever, then another query that INSERTs. Sounds fine. Except remember how your site is always busy? It's quite possible someone was looking at your site at the moment in between those two queries. Since the DELETE has happened but not yet the INSERT, your code isn't going to find whatever data it needed to find and the user is going to get a bad experience. If that user was a CEO for a huge company that wanted to buy you out for lots of money, they might not do that now. A DELETE and INSERT is not atomic because there was that point in between the two queries. It was not "one single action". Instead you go with UPDATE. The database does whatever it does, but the clever people who wrote the software for it already knew about stuff like atomicity. And they made their system guarantee that UPDATEs are atomic. One single action. If you do an UPDATE when that rich CEO looks at your site, the database has guaranteed to you that either (a) the CEO will see the old data because the update hasn't happened yet, or (b) they'll see the new data because the update has happened. There is no moment in between old and new for stuff to be broken.

Look. Here's the deal: I don't know your business or application. Not like you. All I can do is offer general advice and what-ifs, and there's no way for you to explain everything to a degree where I'd be comfortable going beyond that. So what you need to do is take what I'm saying under consideration, think about how your business works, think about how your application is written, and decide for yourself. Will it make sense to people to go to your general online store to buy subscriptions? Will it be a hassle to support a subscription product? You need to figure out the answers to those kinds of questions, then act accordingly.

So far my vote would be for keeping subscriptions separate from everything else, but on the pages for products that the subscription covers (podcasts?) you can advertise the subscription model. Or during the checkout process, try to upsell them into the subscription funnel instead.

We will not write the code for you. Try to understand what I wrote in my reply and amend your code. If you have more problems when you are done then we can help you fix it.

Yes. You can certainly tell people about the subscriptions, anywhere you want, but unless you're prepared to make changes to your store and product models, it's easier to keep it all separate. Yes. It isn't impossible to add subscriptions to the store, but are you sure people will be looking at your online store for a subscription? If you advertise the store as a place to buy goods then they might not think it's the same place to buy access to the website. If it features prominently as a purchase place, maybe they would. You could also not offer the subscription as a "product" but as something they opt into. You can keep the details of the subscription as a sort of hidden product that they cannot add to their cart - only your PHP code can do it, which it would when the user goes through your subscription page thing. Treating the subscription as a product means you have to add a concept of conflicting products to your store. That might be useful for other things, I don't know, but if not then you're creating a lot more complexity for only one thing.

fopen() gives you a "resource" for you to read from and write to the file. "a" means to open the file in append mode, putting you at the end of the file and only allowing you to write. If you want to read and write then use "a+" mode and fseek to the beginning. You can read each line with fgets to look for repetition. You need to use a variable to remember whether you have found the repetition. Start the variable as false, then if you find the repetition set it to true. After the loop, if you did not find the repetition then you can fwrite() the new line (which PHP will put at the end of the file). Remember to fclose at the end.

No, but I don't think you should include subscriptions in the store. A subscription is access to the site or whatever. The online store is for products. They are not the same thing.

Unless the error message is wrong, it thinks somewhere in your table is the string "`test`.`download`.`ADDRESS`".