My problem is quite strange. I'm developing CakePHP application. At the beginning I was doing all stuff on my local server with Windows... and works pretty good. But now I had to do upload to company's server. Now the app doesn't work due to CamelCase convention. My filenames looks like this: PostCategoriesController. On local Windows server there's no problem. But after upload when I type web address in my browser I see PostcategoriesController could not be found. I know Windows and Linux are case-sensitive in different ways. However in Cookbook we can read that developers should use CamelCase convention, so what I'm doing wrong?
As figured in the comments, you were using postcategories instead of something like post_categories in the URL, and so CakePHP cannot properly inflect this to PostCategories as there is no separator for the the words, and so you'll end up with Postcategories, which only works only Windows systems as its filesystems are case-insensitive (except for NFS on some server version if I remember correctly).
See also Cookbook > CakePHP conventions > URL Considerations for Controller Names
As can be seen in the docs it's also possible to use uppercase chars to indicate multiple words, ie postCastegories or PostCategories would work in a URL too.
Related
For years our database driven websites have had URLs that look like:
https://www.example.com/product?id=30
But nowadays, and especially for SEO purposes, we want our URLs to be "nice" and look like:
https://www.example.com/30/myproduct
We use Zope 2.13.x running on Debian and using Apache 2.4 as the front-end webserver. I know that not too many people use Zope, but utilizing Apache's mod_rewrite we should be able to proxy the rewrite and have nice URLs that still pass the database arguments necessary in order to properly serve the pages to the end users.
There used to be a Zope Cookbook where I wrote a bunch of really detailed tutorials on Zope functionality but that no longer seems to exist and I wanted to share this with the SE community.
The awesome thing is that this is not specific to Zope, but will/should work with any rewrite of a parameter based URL into a nice URL and it's super easy once it's all working.
For complete transparency, I am going to answer my own question so that it's documented for everyone.
Using the rewrite engine in Apache, decide how you want your URLs to look to the end user in their web browser.
For example, if you are calling to a database and have a url that looks like
https://www.example.com/products?id=30&product_name=myproduct
but you want that URL to look like
https://www.example.com/products/30/myproduct
you would use a rewrite rule as follows:
RewriteRule ^/products/(.*)/(.*) /products?id=$1&product_name=$2 [L,P,NE,QSA]
To explain that further:
^/products/(.*)/(.*) is saying that anytime domain.com/products is accessed, look for two variables in the next directory names, i.e. /(.*)/(.*)
If you only wanted one variable you would do ^/products/(.*)
Likewise if you wanted three variables you would do ^/products/(.*)/(.*)/(.*)
From there we need to tell Apache how to interpret that URL in order to rewrite and still allow Zope (or whatever db you may be using) to pass the correct URL parameters. That part is:
/products?id=$1&product_name=$2
Apache will now take the first (.*) and treat that as $1. It will take the second (.*) and treat that as $2 and so on.
The part in the brackets is extremely important
L = This makes Apache stop processing the rewrite ruleset if the rule matches. This is important because you don't want Apache to get confused and start trying other rewrites.
P = Proxy the request. This makes sure that the browser does not display a different URL than https://www.example.com/products/30/myproduct (i.e. we do not want the end user seeing the rewritten URL as https://www.example.com/products?id=30&product_name=myproduct
NE = No Escaping any URL characters. You need this to ensure that the URL rewrite does not try and escape the special characters like $ = & as these are important to URL parameters
QSA = This allows multiple variables (or URL parameters) to exist
Please Note: It is very important to consider how you want your URLs to look (the nice URLs) because that is what you want to submit to the search engines. If you change your URL structure, those nice URLs will no longer work and your search engine rankings may decrease.
Whenever i create a contact form in my Joomla! 3.3.6, some script appears in the the page's HTML code that contains many words Joomla in it. I'd like to change those Joomla words and replace them with another words (i.e. Foo) for some security issue. I'd like to know whether or not i'm able to do so and how.
That script is:
<script>(function(){var strings={"JLIB_FORM_FIELD_INVALID":"\u0641\u06cc\u0644\u062f \u0646\u0627\u0645\u0639\u062a\u0628\u0631: "};if(typeof Joomla=='undefined'){Joomla={};Joomla.JText=strings;}
else{Joomla.JText.load(strings);}})();</script>
I have no idea whether a plugin or an extension creates it or not.
Thank you
Regards
This script seems to be translating some text required for the form to use in its javascript, eg validation messages. It does this using a javascript version of JText, which is part of core Joomla. There is some info on how that works here. Weirdly, there seems to be little information in the official Joomla documentation about it.
The main JText function it is calling appears here: media/system/js/core.js
I'm sure it would be possible to write a plug-in to remove this script before the page is rendered and then to translate any untranslated text with your own scripts. However, I'm not sure I see any security benefit in doing this so it seems a waste of time.
Ultimately, someone sniffing a site for what it is built in is far more likely to see if core files exist by going direct to places like media/system/js/core.js, rather than to scan the code for the word "Joomla" - which would trigger a lot of false-positives (any site which just mentions Joomla) and negatives (any page which doesn't have a form on it). It also does not reveal the version of Joomla, which is the info a hacker would more likely be after.
I think you have to search for the script (i.e via Notepad++) in the whole directory. It must be a plugin for the contact form that has some inline script in it.
also do you use any special third party plugin or so? that might be the source of it.
PS: also i had some similar experience, i don't know exactly how i got rid of those words, but like you, i wanted to do that to hide the fact that i'm using joomla for security.
Its actually Joomla who add this, from the file: Joomlainstall/libraries/joomla/document/html/renderer/head.php
And load it globaly from:
Joomlainstall/libraries/cms/html/formbehavior.php
The developer ad that code by using the function, JText, for an example:
JText::_( 'COM_CONTACT_EMAIL_FORM' )
In my case it was the plugin ContactUs Form who add the javascript. If JText is not used, it is not loaded. If I disabled the plugin, the javascript was then not loaded. If you have that plugin enabled, my be try an other contact form?
For security reson it is bad programming by the developer off Joomla, for sure.
I've created an application on XAMPP packet on Windows 8. It works great.
Now, when I've uploaded it on a server (Linux) there are some problems.
Let's say, "ClientStatus".
Controller name: "ClientStatuses".
File name: "ClientStatusesController.php".
Plural: "ClientStatuses".
Singular: "ClientStatus".
But on the Linux server, it says that I must have "ClientstatusesController.php". Why is that? What I need to change in configuration so the conventions would be the same on XAMPP and Linux server? Is it something in .htaccess?
Any info will be great. Thank you. :)
It's CakePHP 2.3.1.
The conventions always was "plural" for controllers, therefore there is only one correct name:
ClientstatusesController
see http://book.cakephp.org/2.0/en/getting-started/cakephp-conventions.html
or try http://inflector.cakephp.org/clientstatus
It appears that "*nix" are case-sensitive with folder names. It has to be ClientstatusesController.php.
Well, here I want to tell you one more thing I've solved when I've uploaded a project on the server.
For transforming JavaScript array to JSON I've used JSON.stringify() and server's json_decode() always returned "null" when converting back.
I think it's because of 3 BOM characters. This solved the problem.
$table = json_decode(stripslashes($_REQUEST['table']), true);
I would like to have an upload control on an intranet website, which needs to support multiple file upload. Drag and drop is not required, I just want to select a lot of files (in hundreds, possibly) for processing on the server. After the uploads are complete the user will be redirected to another page where he'll be able to process the results.
I'd also like to support other browsers, but IE is the most important as most of the customers use it as per their IT policy and it cannot be changed. Their computers are restricted enough and Silverlight might be the way as it's official Microsoft plugin, compared with Flash.
I would like to have a form with a “Browse” button which allows the user to pick files, then the file names are added to a list and “Upload” button that starts the upload to a server side code that saves the file somewhere and redirects the user to the next page.
I think that I should use Silverlight for IE7/8/9 and HTML5 for Firefox, Safari, Chrome and Opera (and IE10, eventually). That would mean coding two separate (html5+silverlight) front-ends and one common back-end on the server.
I know that Telerik has something exactly like this and works, but it's too expensive as I need only one control of their library.
Is there something open-source that works this way? Or is there a better and simpler way to support IE and HTML5 file-compliant browsers?
Silverlight will work in all the browsers, so that's the way to go (right now). After IE 10 comes out, then HTML-5 might be a better choice.
flash is the solution, as flash 7 was shipped by default in windows xp.
but in the end something's got to give, it professionals will have to say no to corporations that have operating systems older than 10 years.
Look at this jquery plugin http://blueimp.github.com/jQuery-File-Upload/
I know this post is a bit older, but have you looked at pulpload or even uploadify? Both provide HTML5 and Flash versions.
Pulpload is somewhat more versatile, it seems, but I have implemented uploadify a few times, and the docs are ... good enough (I think version 3 of uploadify is much better, but I don't have experience implementing it, yet).
We generally use two different hosting services. On one, everything works ticketyboo, as it does on my local dev servers. On the other server, however, I am having this problem:
I can't access the users controller like this:
http://www.example.com/users/login
But I can like this:
http://www.example.com/Users/login
** note the capitalised 'Users' **
If I displace the application to a sub-folder everything works fine (both upper- and lowercase).
The hosting company have looked at it and can't see a problem at their end and they assure me that users is not a reserved word.
You might say this isn't a problem, just use the version that works. Unfortunately it leads to problems downstream where Cake core starts generating urls itself.
Anybody else seen this problem or know the solution?
[This only occurs on the users controller - all others work as expected]
Without seeing all your code / diving in too deeply, I'm not sure what the cause of this problem is. Do you have some special stuff going on in the routes.php file? If you have a specific route defined for users, that could be it.
However, you could make a quick fix -- in UsersController (or AppController if you want to ensure this behavior doesn't pop up elsewhere) just add a line to the beforeFilter() method to capitalize / decapitalize (whichever is more appropriate) the controller parameter.
[edit] - sorry, didn't finish that first paragraph. It still could be the routes file, even though it works on one server and not the other, because it's possible that the working server uses a case-insensitive apache module that normalizes all urls. This is why it's so nice to have your staging and dev setups being EXACTLY the same as production.
While the hosting support denied that the word 'user' or 'users' or 'Users' was in any way reserved, it seems that it was:
"We have removed the users/ redirect"
Problem solved.