I created an admin section for a website of mine using PHPMaker - as I usually do. The website is made from scratch, no wordpress or anything else involved.
In some apparently "innocent" tables, if I try to edit them, I get a 403 error. It never happened, and I used PHP maker for at least 15 websites of mine, so I am puzzled.
It happens only on 2 tables out of 15, and as said, they are fairly innocent. Nothing fancy compared to the other ones.
This is what I've tried:
there was no .htaccess file in the admin directory, so I also tried to insert an empty one
clearing the cache
visiting the page in private mode
all file/directory permissions are ok
regenerating the project and uploading it again, to a different directory
What else can/should I check?
There is a .htaccess file on the root directory of the server to handle some "pretty url", but it should not matter since the admin section is under a specific directory. Or should it matter?
Thank you
At least, I found the problem: every time I was trying to insert an iframe or a script, somewhere somehow somebody (...) was parsing it and it was blocking it for - I guess - security issues, so I let the user to insert the script without the <script> tags, added later in PHP simply with:
print "<script>$readFromDB</script>";
In each insert action, PHPMaker will parse the word
<script
and converted to
<s<x>cript
You have either get the inserted rowid and update the value again OR each time you have to remove the '< x >' to view the value correctly.
Take a look at my answer here: PHPMaker issue
Related
I am suffering a serious problems. The problem is that when i enter billing information, select shipping method and press continue button then it goes to cart page. But Cart is not empty. It should go to payment method step. I am used magento 1.8.1.0 version. When i click on continue buttom my ajax is running . I get the following error in console
"NetworkError: 500 Internal Server Error - http://www.themeatboutique.com.au/shop/checkout/onepage/saveShippingMethod/"
All things are working fine before 4-5 days.
Finally I found about the problem. The problem is that $this is not working in setTemplate file. Not Sure why it is not working
So Can anyone please tell me the solution
In my experience, the most common cause of 500 Internal Server Error on a Magento page that was previously working is a minor typographical mistake that affects syntax enough to make the .php impossible to compile into op-code, therefore, impossible to render, therefore, impossible to serve to the browser.
On the checkout page, such an issue in any of the code that is collated into the standard onepage "pseudo-view" you're using could produce that result at that step. It sounds like all rendered well up to the step following shipping, so your syntax error is most likely in one or the other of those files that creates the view for those two steps, and is most likely in the one following the shipping method.
Look for the usual suspects, a single-quote / double-quote mismatch, a stray line of code missing a semi-colon, a nested array with mismatched parentheses, etc.
If it is none of these, check your /var/system.log and /var/exception.log files for clues.
It is almost always frustratingly simple when you find it.
Happy hunting!
I have MX Google Maps installed on an ExpressionEngine website.
When editing a field ( any field ) I'm greeted by this error:
A PHP Error was encountered
Severity: Warning
Message:
opendir(/opt/www/old_site/themes/third_party/mx_google_map/maps-icons/):
failed to open dir: No such file or directory
Filename: mx_google_map/ft.mx_google_map.php
Line Number: 212
MX google maps tries to use the theme folder path specified in an old site.
I've used the correct theme folder path in my general configuration and global template preferences, but MX google maps seems to stick to the old path.
Do I have to change it somewhere else, what am I doing wrong ?
I think I've had this problem before, and I'm pretty sure Max Lazar saves the path in the database for some reason. Do a search for www/old_site/ on your DB and see if you get any results.
Cheers,
Rob
Looking at the add-on source code, it appears to be checking a setting path_markers_icons, and if that is blank, defaulting to the EE theme path.
You should be able to find the path_markers_icons setting under the global fieldtype settings (under Add-ons > Fieldtypes). I suggest you make the setting blank so that it uses the built in EE theme path and doesn't trip you up in future.
Also, going by your line number it looks like you're not running the latest version (or at least the version that I just downloaded), so I suggest you upgrade.
Shot in the dark here: did you have a look in the exp_site table and in the site_system_preferences field? To echo Rob's thoughts, I vaguely remember having problems with that one on an MSM site, albeit not with that add-on. It's base 64 encoded so use this to decode.
http://www.opinionatedgeek.com/dotnet/tools/base64decode/
If your "old" theme_folder_path value in there, change it and base 64encode it to see if it changes something. Although, specifying theme_folder_path and theme_folder_url in config.php should override whatever is in the DB.
I have duplicated a page in Dreamweaver on the server it has the same content as another page the only difference is the filename.
The original file is working fine but the duplicate is giving a 500 error.
What would cause this and how can I solve it?
I'm thinking it may be the way that the FTP within Dreamweaver is interacting with the server?
Example:
Working page - http://www.fibrefab.com/quotation.php
Duplicate page - http://www.fibrefab.com/quotation-Copy.php
Turns out that the duplicate page had no permissions set as default!
Problem solved...
Xpage (listPostits.xsp) has a "View" container control, where one of the column is set "show values in this column as links".
Now, here comes "Strange behaviour".
When i work with this application on my own (developer) PC (Win XP, Chrome or IE), the Domino generate the link, which can't be really processed:
/servername/db/postit/postit.nsf/listPostits.xsp/onePostit.xsp?documentId=many_numbers&action=editDocument
Namely, the Bold-marked portion shouldn't be there ! This portion is the name of the XPage, where the View control is in.
When i work with the application from other PC (Mac, Firefox) then i get the correct link (the same as above but without the XPage name inbetween):
/servername/db/postit/postit.nsf/onePostit.xsp?documentId=many_numbers&action=editDocument
update: let us leave for the moment the differencies in generated links between two machines. The first question is - why the extra portion is inserted into automatically generated link?
After playing around i think i might have found the reason for this strange behaviour. Namely, the "Substitution" Rules on the server side. One of them is to substitute "*/postit/all" with "/db/postit/postit.nsf/listPostits.xsp"
If i switch it off, then the Links are generated properly. Still, it's pretty strange to me that these settings influence the way Domino generates the links. I thought it works on the fly with them and those settings have nothing to do with the way how Links are generated inside the application.
So, the help now is needed regarding Web Site Rule Topic, but for that, i guess, i have to create another topic. But in case somebody has some good Info on this, please share it with me. I'm a bit confused at the moment :)
Final Update: Spent some more hours of testing and the results confirmed the initial idea.
If i open the page with the standart URL, i.e.
http://servername/db/postit/postit.nsf/listPostits.xsp then everything is fine, links are generated properly. When i however open the same page with short URL http://servername/postit/all , then server adds the substitute URL (db/postit/postit.nsf/listPostits.xsp) to every single link he generates automatically to be used as the link to open/edit the underlying document.
Is it bug or feature ? Don't know.
As a workaround (because i want to keep simple URL's for the application) i have to manually generate links.
I suspect this could be something faulty with Excel (although I keep an open mind), but I wondered if anyone knew how I could get around this apparent bug:
I wish to create Excel spreadsheets which link to pages in a local wiki (running MW 1.14.0, full details below) where those pages don't yet all exist.
The idea is that over time we will fill in details of the pages, but we would like to create the links now (because copies of the Excel files will get sent out to various internal users and it will not be feasible to go track them down and add links later once the pages are created)
The problem is that when I create such a hyperlink in Excel and then go to follow the hyperlink, I get a message back indicating that the page does not exist. The full text of the message is:
"Unable to open http://. The Internet site reports that the item you requested could not be found. (HTTP/1.0 404)"
This happens on our site or in fact if you link to a non-existant page on wikipedia (e.g. http://en.wikipedia/wiki/Swed53rf). Whereas if you put such a link into a browser you get the correct response (which is to be taken to a page indicating that there is no such page but that you can create it by following the usual link)
Is there some setting on Apache that I might need to configure / override to make sure it returns a valid server response to Excel?
Creating links to existing pages works fine. I appreciate that in theory we could go around creating all the pages that are required, but some of the people involved in the project (creating the initial Excel files) do not / cannot use our wiki and it would be better if this just worked as it would appear it should rather than having to try to add steps to work around it in this way.
I also wondered if it were anything to do with the short URL reformatting. Our wiki, like wikipedia has short URLs, eg:
http://server/w/index.php?title=User:Joe_Blogs/Sandbox
can be reached from
http://server/wiki/User:Joe_Blogs/Sandbox
but including hyperlinks to the full name versions of the pages does not resolve the issue.
The version of Excel being used is Excel 2003 (SP3)
I have discovered that this also happens with Word 2003 (I imagine they are using the same code). However the desired behaviour occurs with Lotus Notes (a miracle, as it's rubbish in so many other ways! )
I have not done any significant development on Apache, but I could consider some form of custom page that re-directs to the non-existent wiki page if Mediawiki changes were deemed to complex/tricky. (although I'm not particularly sure where I'd start with this idea, I'm guessing some sort of URL parameter to accept the destination pagename might be a possible approach)
Any helpful suggestions gratefully received!!
[FYI: I have posted a question on MWUsers forum (www.mwusers.com) too after Googling this to no avail! I'll update the forum response there if I get an answer here or vice versa]
Many thanks,
Neil
Running on Ubuntu Server 8.10
Product Version:
MediaWiki 1.14.0
PHP 5.2.4-2ubuntu5.6 (apache2handler)
MySQL 5.0.51a-3ubuntu5.4
Installed extensions:
CategoryTree (Version r44056)
Renameuser
CategoryTree (Version r44056)
ImageMap (Version r35980)
ParserFunctions (Version 1.1.1)
StringFunctions (Version 2.0.2)
Not sure how to get Excel to let you go to a page which turns out to be a 404, but as a temporary workaround, you can hack out MediaWiki's 404 reporting on missing pages...
In MediaWiki 1.14 or 1.15 releases this will be in Article::view() in includes/Article.php:
if( $return404 ) {
$wgRequest->response()->header( "HTTP/1.x 404 Not Found" );
}
Note that the latest dev code is a little different, but you can find it where it sends the same header in the same file. :)
Wikipedia returns a 404 with a redirect which gets you to the page you want; my guess would be that Excel's rendering engine is not following the redirect.
You could try capturing the conversation in Wireshark, both with a browser and with Excel. That might show you what's happening differently.
Surely once you roll out the new pages, the links would start working, though?