Tag: extbase

CodCifer – Saving time and Money is not just the main criteria!

With our new product CodCifer (#CodCifer.com) our main goal was not only to save time and cost. CodCifer is built with passion and love towards the developer community to help them in several ways. There were various hidden things that gets done during the development. CodCifer hence is not just about saving time and money, we can help reduce a lot of unwanted effort by the software developer at various stages.

This advanced GUI based source code generation tool not only helps you generate source code easily, but it also comes with many of the features as given below:

Standard Compliance

The source code generated using CodCifer is ensured to meet the standards set by the respective APIs. This ensures that the source code generated by one developer/agency is also easily manageable by others. There are also no Additional API Code used to achieve a specific task. The code is pure, plain and simple.

Uncompromised Quality, Security & Performance

We have tested and checked the generated source code to ensure it does not have any security loop holes. In all possible places the framework’s standards and best coding practices set by the community for quality and security and performance are followed.

Server Side Validation

New Browsers and computers are sure very powerful enough to run modern JavaScript and HTML5 based applications. But it does not mean a developer can ignore the validations at the server side. If you ignore to add server side validations, the consequences can be detrimental. Server side validations are thus a part of our build process.

Client Side Validations

Client side validations are an integral part of the web applications to ease the life of the end users. Client side validations are done in CodCifer using the HTML5 standards as well as the respective JavaScript or HTML frameworks. Bootstrap and jQuery have their own way of doing validations. These are part of the source code generated.

Plugins/Modules/Extensions

Most of the backend frameworks like Symfony, Laravel, CodeIgniter and TYPO3 ExtBase have the ability to put our custom code as either plugin or extension or a module. CodCifer helps you specify a name for such a module, and thus the code you get is not going to change the core.

Migrations between frameworks

Consider there is an application written in some old obsolete framework. The client now insists that he wants Symfony.

Let us Imagine the amount of time and effort needed to migrate.

We started coding with Symfony, and say 10-15 days have passed. Our client met a friend who said Laravel is much cooler! Now client is hesitant to use Symfony!

What if we don’t have a developer who knows Laravel? But we do have expert developers, who can learn and work on Laravel?

Well such cases happen, and are quite common. We usually protect ourself with the initial agreements made with the client. What if the other framework he mentioned was really better for his needs? The time and cost factors may not permit us to proceed even at an early stage. Client may have to stick to the previously selected framework or he may be hard pressed on his choice and thus we may lose the project.

CodCifer is quite helpful in such scenarios. It can take the DB schema from the old application. Then you can define the form inputs using GUI, and proceed to generate source code in any framework the client needs.

Re-Usable!

CodCifer architecture is built with re-usability in mind. There are several ways in which this can be achieved.

  1. Re-use a previously defined project.
    Consider we got a project, which is very much similar to the project that is completed and released about 6 months ago.
    Can we really re-use any of it’s model / controllers / table structure?
    The possibilities can vary, and in most cases the chances are quite less. We have to change an already completed project, which is made to suit a specific needs. The project may share similar database model, but the busniness logics could be different. The time and effort needed may be lot more than doing it from scratch.On the other hand, CodCifer lets you clone a project with one click! All you will need to add is the business and design logics to suit this new client’s requiremnts.
  2. Re-use frequently used tables / fields using Generic Imports
    In software development there are a set of common tables and fields, that are usually part of every project. One project may need some tables, the other project may not need the same set of tables. Such needs are usually handled using manual copy/paste procedures on either file or codes, or even by removing un-used tables / code from a dumy codebase we usually keep.CodCifer has an advanced mechanism here. We call it Generic Imports, we can define such common tables under various groups, and import into our project whenever the need arises.

Customizable to your needs

Each Corporate Agency usually has his own additional API or extra set of features, that they usually add to every software they write.

Such as an extra DB Layer, or file upload layer, Validation Layers and so on. They may even wish to add a set of codes in each controller or model or a set of additional methods for each controller, and so on.

If there is any such customization requirements, CodCifer Corporate plans are for you. We offer customizations to suit your exact needs.

Run on own server

If a corporate wants, we can provide the VM images, that helps you run CodCifer on your own intranet/internet servers.

Easy to Maintain

A standard method of coding, also ensure that the end code is also easy to maintain. This is a big game changer as it helps save huge cost of maintenance to the client at a late point of time.

One GUI for all

Today CodCifer supports 4 backend frameworks.

Symfony, Laravel, CodeIgniter and TYPO3 ExtBase were initially chosen by us. Support for Django, NodeJS is in pipeline.

On the front-end side BootStrap is used as the HTML Framework and jQuery handles the JavaScript codes. Support for Foundation, 960.gs and Skeleton are in planned for the next version release. In this second version we also planned that jQuery would be accompanied by ExtJS, AngularJS, Ember.js and ReactJS.

This frameowrk support would be increased with time. Thus a common GUI for various frameworks and which is so easy to use that even a freasher can easily generate the source code without much hassle.

CodCifer – Source Code Automator

CodCifer is our new too lthat helps developers in saving a lot of time during the initial software development life cycle.

Current Scenario

Whenever a new project comes in, the main goal for any company is to ensure it is started as soon as possible, and at the bare minimum costs.

There are companies that had their own tool to kickstart a project. Several companies usually keep their own set of codebase to start off with their new project. This is a cool way, and we were able to really surprise our clients with the speed at which we used to start our project.

We prepared dummies, and codebase and several such tools to kickstart as well as to ensure we are able to develop faster, and our concentratin was also on an easier future maintenance.

Was  such mechanism really fool-proof?

As time goes on, these codebase we regularly use should also be maintained, and upgraded as with the new technology changes.

The frameworks we use gets upgraded, there are various frameworks in use at the server-side for Back-End Programming, and too many HTML, CSS and JavaScript for the Front-end programming and Frontend rendering.

For several major companies such maintenance used to come with huge cost factor involved. On the other hand, time factor. Not everyone was able to find enough time to maintain their own codebase.

So, Start From Scratch

Whenever a client asked for a new project, and if the client insisted on using the latest version of the frameworks, one had to start from scratch. This time, Clients are again surprised about the huge time it took, and the usual default stuff that should be there, was  just missing. Validations not happening, or the Cool URL re-writing is being missed, and several other things would have been forgotten, or was just not feasible enough to start!

Even a well organized company had to start a project from scratch, and had to go through several such hurdles.

Migration issues

We had similar issues when we migrated from TYPO3 3.x to 4.x, then Migrating TYPO3 from 4.x to 6 LTS, and now we have similar issues when migrating TYPO3 from 6 LTS to 7 LTS or 8 LTS or 9 LTS, this is an altogether new dilemma.

The migration is not an easy task, the time and cost factors involved are huge, not every client would like to bear it.

Source Code Generators

The art of source code generation is not something new. There are several companies that had their ER diagram, and UML generation software products built with source code generation for various programming languages. One could even have their own template.

Even TYPO3 came with source code generators such as Extension-Builder, and Kick-Starter.

Many programming languages even come with their own source code generators to create basic code for CRUD. Most such source code generators are not easy, and re-usability is not always possible. Finally, the end code produced needs to be manually migrated to the modern frontend rendering frameworks.

The Spark

I needed to start a project faster, and ensure that I am always on par with the latest trends. The quality should always be consistent. If a client wants to upgrade, there had to be an easier way, and migration to a complete new technology should also be easier. Time is money, it is a major hurdle for everyone, no one wants to waste time unless it is inevitable.

These are what sparked me to think of CodCifer. Initially I thought to make it as a replacement for the Extension-Builder for TYPO3 alone. But I found similar issues all around, so I planned on a product that works for all.

CodCifer is not just a plain source code generator. But the way it works, and helps makes it one of the strongest around. There are several ways the services of CodCifer can be utilized.

I will try to explain CodCifer further in my upcoming blog articles and Youtube videos.

Please subscribe to our Youtube channel to keep yourself updated on Codcifer.

This is a tool meant for the developers to save time and money. On a long run, our motto is to take it towards open-source.

Migrate TYPO3 or move to Drupal or WordPress or Joomla?

Today with such huge leap in the changes to TYPO3, people are really moving over to WordPress and Drupal. There is a haphazard move to migrate to Druapl and WordPress. People are cashing in, and we at SCWEBS as a solution expert are not really happy about this extra bill. Financially this is extremely good, for an agency like ours.

We can just cash out by suggesting alternate solution, and justfy extra costs, and keep our company runing happy at the cost of my client’s money!

Is this really justified?

NO IT IS NOT!

There are more than 4 lac websites that are still running on TYPO3 version 4.5.x and TYPO3 version 4.6.x.

One of the major change was the move from PiBase to ExtBase. Developers were not ready to move, clients were not ready to move. And the real fact that whenver there is a change – no one really wants to be ready. But the one who makes the move will be the smart person.

Some of the large enterprises and NGOs are already migrating from TYPO3 4.x or TYPO3 6.x to the latest TYPO3 version. But the main debate was whether we should really stick to TYPO3?

Several companies have already moved from TYPO3 to other options like Drupal, Joomla and WordPress. Was it really a cost saving smart move? I don’t think so.

I have been working on Content Management Systems (CMS) since almost 18 years or more from now. That is as a student, I had been fond of Content Management Systems (CMS). When I saw Drupal, WordPress and Joomla I had even started writing my own CMS system during those times.

When I met TYPO3, I was totally surprised that this Content Management System (CMS) can take over everything. TYPO3 was not framed behind PiBase or ExtBase, but it came forward with a beautful idea from the king Kasper Skårhøj. His main ideas helped build this extremely flexible Enterprise class Content Management System (CMS) from day one!!!. TYPO3 surely needs time to learn, but one learnt there is no going back. You can make it work like a Blog like WordPress, as an E-Commerce system like Magento, WooCommerce, PrestaShop or anything out of those 100+ choices, TYPO3 can be a Comunity portal like Drupal’s strong features.

TYPO3 could become anything, and even today when I re-learnt Drupal and WordPress, I am not happy with the options. WordPress and Drupal surely do excel, but if you chose TYPO3 once, I do not see a point why one should move out.

But such a move will surely cost on a long run, because in-spite of learning Drupal, WordPress and other ssytems I am not happy with these systems. One can argue that this is my individual opinion, but trust me on a real long run – the cost of choosing other systems will be learnt.

Today at SCWEBS we still use TYPO3 as our main expert area, and when one needs a real blog, we still do prefer WordPress. But if it is very simple blog like feature, TYPO3 is all we prefer. For E-Commerce WooCommerce or Prestashop and we do prefer a TYPO3 based shop like tt_product on several occasions. Drupal or Joomla almost never come into picture untill and unless a customer really wants to get it done by us.

In many cases, we have built a totally custom solution using Symfony and Laravel but we are proud that till date have never moved a TYPO3 customer out. I feel that migrating to ExtBase and TYPO3 Version 9 is far easier than moving over to Drupal.

If you want to migrate your site to WordPress or Drupal, contact us, we will personally help you out. I will show why TYPO3 is still better than the rest. There are 100+ reasons and areas where TYPO3 excels.

If you are still running your website on one of the TYPO3 versions like TYPO3 version 3.8, TYPO3 version 4.5 or TYPO3 version 4.6, TYPO3 version 6.2 LTS then we suggest it is time to migrate to newer TYPO3 version.

TYPO3 is quite secure, and we can justify it. We still kept some of our site on versin 4.x to analyze how attacks happen, and to what level. Today, on one of our 4.5 site, the site goes down and comes back up within 10 minutes, all by itself. The hackers are trying twice every day to get in, and succeed to a level, but they can’t get much deeper. We are watching what all they can do. They could not do much harm as of now… but we can’t sayfor how long. We are not such big security experts like our friends in TYPO3 security team. So our advice – migrate before it is too late.

These older versions are slowly getting older, and they may soon be hacked by a smart thief. By now, agencies are all well prepared to handle TYPO3 migrations, and these days costs are quite lower too. If you are an agency with many TYPO3 sites that needs migration, we can help with several strategies to lower the costs much further.

If you have a TYPO3 migration query, do get in touch with us. We are curiously waiting.

Prevent Search Engines from flooding the Encode Cache – using an XCLASS

The RealURL encode cache could get flooded with the URLs that are used by search engines like Google, Solr etc… If we know the exact parameter they use, we can prevent the flooding using this simple function given below

1.) Add this code to the file “Realurl.php” in the “Sconfig\Xclass” folder. Here “Sconfig” – is the name of our extension. “Xclass – folder may need to be created if not present”

CODE START
########################

<?php

namespace Scwebs\Sconfig\Xclass;

class Realurl extends \tx_realurl {
public function encodeSpURL(&$params) {
parent::encodeSpURL($params);
}

protected function encodeSpURL_encodeCache($urlData, $internalExtras, $setEncodedURL = ”) {
// \TYPO3\CMS\Core\Utility\GeneralUtility::devLog(‘Inside the hook now!’, ‘realurl’, 1, array($urlData));
if( isset($_GET[‘gclid’]) ){
$this->devLog(‘gclid detected. Not doing anything!’);
return ”;
}
parent::encodeSpURL_encodeCache($urlData, $internalExtras, $setEncodedURL);
}
}

########################
CODE END

2. Our Xclass needs to be registered, this can be done in the “Sconfig/ext_localconf.php” using the code below:

$GLOBALS[‘TYPO3_CONF_VARS’][‘SYS’][‘Objects’][‘tx_realurl’] = array(
‘className’ => Scwebs\\Sconfig\\Xclass\\Realurl’
);

The default controller for extension not found.

Some time we get the error like
“The default controller for extension “extname” and plugin “Calendar” can not be determined.
Please check for TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin() in your ext_localconf.php”.

Even we have all the correct configurations in ext_localconf.php and ext_tables.php

This is what we have in ext_localconf.php
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
‘Vendor.’ . $_EXTKEY,
‘Calendar’,
array(
‘Calendar’ => ‘list, show’,
),
array(
‘Calendar’ => ”,

)
);
?>

This is what we have in ext_tables.php
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerPlugin(
$_EXTKEY,
‘Calendar For Dates’,
‘Calendar’
);

All the configurations are perfect but still we get the error, why?

Yes there is the reason for it. Suppose we have more than one extension, or more that one plug in in the same extension.
Other extensions or plugins might have had flexforms, and we have added that plugin and configured the flexform.
Now for the same tt_content element we have selected the plugin “Calendar”, and when we select this plugin we dont see any flexform values of
previous plugins.
But in Databse the table tt_content still stores the flexform values of old plug in and this leades to error.

Solution :
1) Go to databse and delete the flexform values for the perticular tt_content element.
or
2) Delete the old content element and add the new tt_content element.