Problems with php.ini - apache

My problem is related to the php.ini file I think, but it might be something else.
Let's say we have a site architecture where inside the root directory there is another directory named img and a file named index.php. Inside the directory img there is a file named image.jpg.
So in index.php, to refer to an image, I would use /img/image.jpg.
My question is, what should I change in php.ini to be able to write img/image.jpg instead of /img/image.jpg.
Thanks

Relative paths get resolved by the web browser, not by PHP. There is no way to override this behavior on the web server.

Nothing PHP can do. You could essentially do that with Apache rewrites but it makes much more sense to just use absolute paths. You should not try to mix absolute and relative paths because it will only cause problems for you in the future. What's wrong with adding the '/' to the front of the path?
Not only that, but it will confuse the hell out of people trying to debug your code that all of your relative paths are becoming absolute paths in Apache.

My question is, what should I change in php.ini to be able to write img/image.jpg instead of /img/image.jpg.
This is answering your question but not the answer you would like to hear. It quite simple, let's first list the ini settings:
auto_prepend_file (probably in conjunction with include_path)
And that's all. How it works:
Prepend a php script with the ini directive. inside that file, you start output buffering with your own callback function:
function callback($buffer)
{
// slash that image that you want to write without slash
return (str_replace("img/image.jpg", "/img/image.jpg", $buffer));
}
ob_start("callback");
You are now able to write img/image.jpg instead of /img/image.jpg because your output filter function does re-write it for you.
But take care that you're not trying to fix the wrong end with this. General rule of hypertext references apply, see Uniform Resource Identifier (URI): Generic Syntax
, Hypertext Transfer Protocol -- HTTP/1.1
and Hypertext Markup Language - 2.0
.

Related

Simple question about File class in kotlin

I'm trying to read from a file in kotlin using the File class. It's just a simple txt file with a list of names with each name occupying an independent row. This is my project structure:
and here's my function for pulling out a name depending on the day of the year:
private fun getNameOfTheDay(): String {
val cal = Calendar.getInstance()
val day = cal[Calendar.DATE]
return File("data${File.separator}names.txt")
.bufferedReader()
.lineSequence()
.elementAt(day - 1)
}
I keep on getting a FileNotFound exception so I would assume that my file path is somehow wrong... What am I doing wrong here? Sorry for the dumb question, I'm still learning. By the way the function shown above is called from the MainActivity. Thanks in Advance!
Filenames can be absolute or relative. Absolute filenames start from the top level (e.g. the root directory on Unix-like filesystems, which Macs have; or a drive letter on Windows), and so specify the filename unambiguously. Relative filenames don't, and so give a file in (or in relation to) the current working directory.
In this case, data/names.txt is a relative filename. It assumes that the current directory has a subdirectory called data, and refers to a file in that.
However, the file is actually in the directory app/src/main/java/com/example/mynameis/data/ within your project — so this would only work if the current directory was /<pathToYourProject>/app/src/main/java/com/example/mynameis/, which is highly unlikely! So that probably explains the failure.
I don't know about Android projects, but in normal JVM projects the standard practice is to put data files in a src/main/resources/ directory. Gradle (or Maven) knows to copy them into the classpath when building the project. You would then load it from the classpath, e.g. with:
javaClass.getResource("data/names.txt").readText()
See e.g. this question for more details and variations.
The advantage of loading from the classpath instead of a file path is that you don't need to know exactly where the file is; it could be loose on the filesystem, or bundled into a jar or other archive (even compressed), with ways to select between different versions depending on the run profile — all completely transparent to your code.
As I said, I don't know Android, and can't find any direct answers on StackOverflow. (This question seems to suggest using a android.resource:// URI, but I don't know if that would apply here.) Maybe these external sites can give you some hints.
You should try "data\names.txt". Oftentimes slashes don't work for file paths.

Escaping `/**` in asciidoc

My goal
I am trying to submit a fix to the Filebeat documentation, written in asciidoc.
Source
Currently it is not possible to recursively fetch all files in all subdirectories of a directory. However,
the /** pattern can be used to fetch all files from a predefined level of subdirectories. For example,
/var/log/**/*.log and /var/log/**/**/*.log fetch all .log files from the subdirectories and sub-subdirectories of /var/log, respectively. Note that neither fetch log files from the /var/log folder itself.
Result
From asciidoclive.com:
My problem
The /** becomes / in the output, and the words after it are unintentionally marked in bold.
My question
How do I properly escape /** in asciidoc?
This is tricky, ’cause escaping is de facto broken in Asciidoctor. :(
I know about two possible workarounds:
use passthrough: +++\**+++,
or define attribute for asterisk, e.g. :star: * and write \{star}{star}.
Yes, it sucks and it’s not easily fixable in Asciidoctor. The best option would be to implement new AsciiDoc parser based on proper grammar etc, Asciidoctor is unfortunately in very bad shape in sense of code-quality. :( (If anyone would be willing to sponsor such project, pls contact me.)

What's the point of using absolute urls in Pelican?

About RELATIVE_URLS, the Pelican docs say:
…there are currently two supported methods for URL formation: relative and absolute. Relative URLs are useful when testing locally, and absolute URLs are reliable and most useful when publishing.
(http://pelican.readthedocs.org/en/3.4.0/settings.html#url-settings)
But I'm confused why absolute URLs would be better or not. In general, when I write HTML by hand I prefer to use relative URLs because I can change the domain of the website and not worry about it later.
Can somebody explain the thinking behind this setting in more detail?
I don't use the RELATIVE_URLS setting because it's document-relative. I don't want URLs containing ../.. in them, which is often what happens when that setting is used.
Moreover, relative URLs can cause issues in Atom/RSS feeds, since all links in feeds must be absolute as per the respective feed standard specifications.
Contrary to what's implied in the original question, not using the RELATIVE_URLS setting will not cause any 404s if you later decide to change the domain. There's a difference between specifying absolute URLs in your source document (which is what you seem to be talking about) and having absolute URLs generated for you at build time (which is what Pelican does).
When it comes time to link to your own content, you can either use root-relative links, or you can use the intra-site link syntax that Pelican provides.

Possible to read files with wildcard in the path name?

For example, /path/to/*/file can you use SQL to read a file using a wildcard to fill in the absolute path? This is for a situation where I there is one component in the path which changes unpredictably.
I think the answer is no. But if you can look up the valid options by querying the file structure you could then loop around the results. However I would suggest that any system that employed this approach would be wide open to hackers.

Naming convention for assets (images, css, js)?

I am still struggling to find a good naming convention for assets like images, js and css files used in my web projects.
So, my current would be:
CSS: style-{name}.css
examples: style-main.css, style-no_flash.css, style-print.css etc.
JS:
script-{name}.js
examples: script-main.js, script-nav.js etc.
Images: {imageType}-{name}.{imageExtension}
{imageType} is any of these
icon (e. g. question mark icon for help content)
img (e. g. a header image inserted via <img /> element)
button (e. g. a graphical submit button)
bg (image is used as a background image in css)
sprite (image is used as a background image in css and contains multiple "versions")
Example-names would be: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, bg-gradient.gif etc.
So, what do you think and what is your naming convention?
I've noticed a lot of frontend developers are moving away from css and js in favor of styles and scripts because there is generally other stuff in there, such as .less, .styl, and .sass as well as, for some, .coffee. Fact is, using specific technology selections in your choice of folder organization is a bad idea even if everyone does it. I'll continue to use the standard I see from these highly respected developers:
src/html
src/images
src/styles
src/styles/fonts
src/scripts
And their destination build equivalents, which are sometimes prefixed with dest depending on what they are building:
./
images
styles
styles/fonts
scripts
This allows those that want to put all files together (rather than breaking out a src directory) to keep that and keeps things clearly associated for those that do break out.
I actually go a bit futher and add
scripts/before
scripts/after
Which get smooshed into two main-before.min.js and main-after.min.js scripts, one for the header (with essential elements of normalize and modernizr that have to run early, for example) and after for last thing in the body since that javascript can wait. These are not intended for reading, much like Google's main page.
If there are scripts and style sheets that make sense to minify and leave linked alone because of a particular cache management approach that is taken care of in the build rules.
These days, if you are not using a build process of some kind, like gulp or grunt, you likely are not reaching most of the mobile-centric performance goals you should probably be considering.
I place CSS files in a folder css, Javascript in js, images in images, ... Add subfolders as you see fit. No need for any naming convention on the level of individual files.
/Assets/
/Css
/Images
/Javascript (or Script)
/Minified
/Source
Is the best structure I've seen and the one I prefer. With folders you don't really need to prefix your CSS etc. with descriptive names.
For large sites where css might define a lot of background images, a file naming convention for those assets comes in really handy for making changes later on.
For example:
[component].[function-description].[filetype]
footer.bkg-image.png
footer.copyright-gradient.png
We have also discussed adding in the element type, but im not sure how helpful that is and could possibly be misleading for future required changes:
[component].[element]-[function-description].[filetype]
footer.div-bkg-image.png
footer.p-copyright-gradient.png
You can name it like this:
/assets/css/ - For CSS files
/assets/font/ - For Font files. (Mostly you can just go to google fonts to search for usable fonts.)
/assets/images/ - For Images files.
/assets/scripts/ or /assets/js/ - For JavaScript files.
/assets/media/ - For video and misc. files.
You can also replace "assets" with "resource" or "files" folder name and keep the name of it's subfolders. Well having an order folder structure like this isn't very important the only important is you just have to arrange your files by it's format. like creating a folder "/css/" for CSS files or "/images/" for Image files.
First, I divide into folders: css, js, img.
Within css and js, I prefix files with the project name because your site may include js and css files which are components, this makes it clear where files are specific for your site, or relating to plugins.
css/mysite.main.css css/mysite.main.js
Other files might be like
js/jquery-1.6.1.js
js/jquery.validate.js
Finally images are divided by their use.
img/btn/submit.png a button
img/lgo/mysite-logo.png a logo
img/bkg/header.gif a background
img/dcl/top-left-widget.jpg a decal element
img/con/portait-of-something.jpg a content image
It's important to keep images organized since there can be over 100 and can easily get totally mixed together and confusingly-named.
I tend to avoid anything generic, such as what smdrager suggested. "mysite.main.css" doesn't mean anything at all.
What is "mysite"?? This one I'm working on? If so then obvious really, but it already has me thinking what it might be and if it is this obvious!
What is "Main"? The word "Main" has no definition outside the coders knowledge of what is within that css file.
While ok in certain scenarios, avoid names like "top" or "left" too: "top-nav.css" or "top-main-logo.png".
You might end up wanting to use the same thing elsewhere, and putting an image in a footer or within the main page content called "top-banner.png" is very confusing!
I don't see any issue with having a good number of stylesheets to allow for a decent naming convention to portray what css is within the given file.
How many depends entirely on the size of the site and what it's function(s) are, and how many different blocks are on the site.
I don't think you need to state "CSS" or "STYLE" in the css filenames at all, as the fact it's in "css" or "styles" folder and has an extension of .css and mainly as these files are only ever called in the <head> area, I know pretty clearly what they are.
That said, I do this with library, JS and config (etc) files. eg libSomeLibrary.php, or JSSomeScript.php. As PHP and JS files are included or used in various areas within other files, and having info of what the file's main purpose is within the name is useful.
eg: Seeing the filename require('libContactFormValidation.php'); is useful. I know it's a library file (lib) and from the name what it does.
For image folders, I usually have images/content-images/ and images/style-images/. I don't think there needs to be any further separation, but again it depends on the project.
Then each image will be named accordingly to what it is, and again I don't think there's any need for defining the file is an image within the file name. Sizes can be useful, especially for when images have different sizes.
site-logo-150x150.png
site-logo-35x35.png
shop-checkout-button-40x40.png
shop-remove-item-20x20.png
etc
A good rule to follow is: if a new developer came to the files, would they sit scratching their head for hours, or would they likely understand what things do and only need a little time researching (which is unavoidable)?
As anything like this, however, one of the most important rules to follow is simply constancy!
Make sure you follow the same logic and patterns thoughout all your naming conventions!
From simple css file names, to PHP library files to database table and column names.
This is an old question, but still valid.
My current recommendation is to go with something in this lines:
assets (or assets-web or assets-www); this one is intended for static content used by the client (browser)
data; some xml files and other stuff
fonts
images
media
styles
scripts
lib (or 3rd-party); this one is intended for code you don't make or modify, the libraries as you get them
lib-modded (or 3rd-party-modified); this one is intended for code you weren't expected to modify, but had to, like applying a workaround/fix in the meantime the library provider releases it
inc (or assets-server or assets-local); this one is intended for content used server side, not to be used by the client, like libraries in languages like PHP or server scripts, like bash files
fonts
lib
lib-modded
I marked in bold the usual ones, the others are not usual content.
The reason for the main division, is in the future you can decide to server the web assets from a CDN or restrict client access to server assets, for security reasons.
Inside the lib directories i use to be descriptive about the libraries, for example
lib
jquery.com
jQuery
vX.Y.Z
github
[path]
[library/project name]
vX.Y.Z (version)
so you can replace the library with a new one, without breaking the code, also allowing future code maintainers, including yourself, to find the library and update it or get support.
Also, feel free to organize the content inside according to its usage, so images/logos and images/icons are expected directories in some projects.
As a side note, the assets name is meaningful, not only meaning we have resources in there, but meaning the resources in there must be of value for the project and not dead weight.
The BBC have tons of standards relating web development.
Their standard is fairly simple for CSS files:
http://www.bbc.co.uk/guidelines/futuremedia/technical/css.shtml
You might be able to find something useful on their main site:
http://www.bbc.co.uk/guidelines/futuremedia/