I've been experimenting with Kohana 3 for the past few weeks, and up to now I was quite impressed. I just upload my project to the live server, and I realized I needed one of the lastest version of PHP (5.3) and that I'm stuck with 5.1.6, with this said server.
Now, this may not be the cause of the problem, but every PHP variable found in the views aren't parsed correctly. For example, if I output a link
echo Html::anchor('form/registration', 'I Accept,<br />Enter', array('class' => 'left'));
I'll have :
<a href="" class="">
So I guess I'm missing some functionalities of PHP which they added in the lastest version. Any ideas?
I resolved the issue. The problem was related to the version of PHP, I did upload the app on another server running PHP 5.3.X, and everything was okay, confirming my doubts.
I did track the bug to a certain function which used PHP's htmlspecialchars (HTML::chars) - anyway, I simply used Kohana 2.3 equivalent function and everything is now fine. Well, I had to deal with some other issue, related to PHP 5.1.6 (why, in the name of the holy mother of god, any hosting solution would still be using this backward version?), but at least I didn't had to rewrite the app under another framework of under an older version of Kohana.
Related
I have a Liferay 6.1 instance with a custom classic theme, but trying to upgrade it to 7.0 is being so painful that I decided to take Liferay 7's classic theme (downloaded from here).
To bring it into Eclipse - Liferay IDE I created a new module (theme) project and imported files, but trying to deploy it was sending errors (for example, no init.ftl, stuff like that, unexpected given I am using the repo source).
When I arrived to this error, solved it and tried to deploy, it again said there's no init.ftl... Then I searched for it into the war and it actually wasn't there! No idea about what but... I noticed a portal_pop_up.ftl that doesn't exist in my source code!!! What is going on? I'm pretty confused.
Thanks!
Ok, the problem was with code downloaded from Github.
If you want to use classic-theme, just create an "empty" theme in the IDE and then overwrite it's files with the ones from auto"deployed" classic-theme in the L7 instance, in /opt/liferay/osgi/wabs.
I started migrating my applications to PHP7 last year already using the PHP7 release candidate (7.0.0RC5) available at the time. I successfully made all required changes and the apps are all running fine on that version (PHP 7.0.0RC5).
Recently I started testing the code with the latest and greatest PHP-7 version (7.0.11) and everywhere in the code where 'require_once()' is used (not only my code but also in 3rd party libraries) the code breaks with " 'fileA.php'...failed to open stream: No such file or directory in...'fileB.php>' ".
I double-checked and compared all the php.ini settings between the two versions and I am certain there are no differences.
Question: Has anything changed between 7.0.0RC5 and now that causes the behavior of require_once to be different? Even just a pointer would be highly appreciated.
I have upgraded Kentico site from Kentico 8.2 to Kentico 9.0, everything was looking pretty and working smoothly. But when I tried to export my own site, I got Exception with following statement.
“Conversion failed when converting from a character string to unique identifier”.
From your current description it is impossible to tell what might have broken. The exception you are getting is very common and you can find many examples of reason why it happens here in SO.
However, what might be related to your question in Kentico is whether the upgrade you performed was successful. Try checking CMS_SettingsKey table for following KeyNames
CMSDBVersion
CMSDataVersion
Are they both set to 9.0? If not, the upgrade was not entirely successful. If yes, then there is some other issue within the data in your database for which we would need much more information.
Some of the class form definitions haven't been upgraded properly. Try the upgrade again and make sure you perform all the Steps after upgrade, especially "Running the website - First request".
So, I realise there are a lot of threads with this topic already but I have went through every single one of them (Majority of them are the exact same) and nothing seems to work.
**As a note, I am using a trial version of Dreamweaver cc 2015, and I am using WAMPSever.
So, I have a testing server working. The problem I am having is creating a MySQL connection from Dreamweaver to phpmyadmin. The error that persists is the:
HTTP ERROR CODE 404 File not found. Here are some possible reasons for the problem:
1) There is no testing server running on the server machine.
2) The testing server specified for this site does not map to the. Verify that the URL in the prefix maps to the root of the site.
I have moved the MMHTTPDB.php and mysql.php into the right folder. I have also selected the server model to be PHPMYSQL.
This is my site:
This is the testing server:
I am fairly new to using Dreamweaver but I have not been more frustrated with anything in my entire life.
Any help would be much appreciated.
I was in a similar situation a week ago and spent sleepless nights trying to find a solution. Like you, I have never been frustrated as I was by this. Finally, I had to downgrade my XAMPP version because I learnt that if you're using the deprecated server behaviors in Dreamweaver, they won't work with the latest version of XAMPP.
I downloaded an older version and I am okay now.
Is there an issue with IIS or ASP Classic where Request.ServerVariables("QUERY_STRING") returns blank if no default file name is given in the URL? On my local developer machine, I can do
http://localhost/xslt/?opcs/abc
which returns "opcs/abc". However, on our ancient web server, it returns nothing. I have to explicitly give it the default file name in the URL. Like so
http://localhost/xslt/default.asp?opcs/abc
While nothing too major, it is a little bit of a annoyance. One way I can maybe think of remidying the problem is have Javascript read the URL and return everything after the ?.
Unfortunately, I do not know what version of IIS or ASP we are using.
Thank you.
That sounds like a bug, I never experienced that when I used to do a lot of ASP. Make sure you are patched up to the latest version.
If you're running IIS 4.0, this may very well be the case. So you're really stuck with this ancient piece of software (and probably hardware) ? :)